1. 28 Oct, 2002 7 commits
  2. 25 Oct, 2002 1 commit
    • David Brownell's avatar
      [PATCH] rm "automagic resubmit" for usb interrupt transfers · e9c72b55
      David Brownell authored
      Here's that promised patch to remove the problematic "automagic
      resubmit" mode from the API for interrupt transfers.  It covers
      the core (including main HCDs) and a few essential drivers.
      
      All urbs now obey a simple rule:  submit them once, then wait for
      some completion callback.  Or unlink the urb if you're impatient,
      canceling the i/o request (which may have been partially completed).
      Bulk and interrupt transfers now behave the same at the API level,
      except that only interrupt transfers have bandwidth failure modes.
      
      
      Previously, interrupt transfers were different from bulk transfers
      in several ways that made limited sense.  The only thing that's
      supposed to be special is achieving service latency guarantees by
      using the reserved periodic bandwidth.
      
      But there were a lot of other restrictions, plus HCD-dependent
      behaviors/bugs.  Doing something like sending a 97 byte message
      to a device portably was a thing of pain, since the low-level
      "one packet per interval" rule was pushed up to drivers instead
      of being handled inside HCDs like it is for bulk, and sending a
      final "short" packet meant an urb unlink/relink.  (Fixing this
      required UHCI to use a queue of TDs, like EHCI and OHCI; fixed
      by 2.5.44, and a small change in this patch.  I'm not sure the
      unlink/relink issues have ever been really addressed.)  Neither
      1-msec transfer intervals nor USB 2.0 "high bandwidth" mode can
      reliably be serviced without a multi-buffered queue of interrupt
      transfers.  (Comes almost for free with TD queueing; as of 2.5.44
      all HCDs should do this.)
      
      And then there's "automagic resubmission", which made HCDs
      keep urbs during their complete() callbacks in a rather curious
      state ... half-owned by HCD, half-owned by device driver, not
      exactly linked but maybe not unlinked either.  Bug-prone, and
      hard to test.
      
      
      So that's all gone now!  This particular patch
      
        - updates the main hcds to use normal urb-completion logic
          for interrupt transfers, nothing special. (*)
      
        - makes usbcore (hub and root hub drivers) expect that, and
          removes an old kernel 2.3 "urb state confusion" workaround.
          (urb->dev is no longer nulled to distinguish unlinked urbs,
          since there's no longer a "half-in/half-out" state.)  also
          the relevent kerneldoc is updated.
      
        - enables the 'usbtest' support for interrupt transfers, in
          both queued and non-queued modes.  (but I haven't made time
          to test this ... the hcds "should" be fine since they use the
          same code now for bulk and interrupt, and bulk checked out.)
      
        - teaches hid-core, usbkbd, and usbmouse how to resubmit
          interrupt transfers explicitly. usb keyboards/mice work,
          but some less-common HID devices won't.
      
        - updated usb/net drivers (catc, kaweth, pegasus, rtl8150)
      
      But it doesn't update all device drivers that use interrupt
      transfers.  The failure mode for un-converted drivers will
      be that interrupts after the first one get lost, and the
      fix for those drivers will be simple (see what the drivers
      here do).
      
      
      (*) It doesn't touch non-{E,O,U}HCI HCDs, like the SL-811HS,
           since those changes will require hardware as well as
           some quality time with 'usbtest'.
      e9c72b55
  3. 24 Oct, 2002 1 commit
  4. 23 Oct, 2002 2 commits
    • David Brownell's avatar
      [PATCH] ehci enumerating full speed devices · be75e771
      David Brownell authored
      The EHCI driver was never adjusting the full speed maximum packet size up
      (when enumerating through a transaction translating hub).  This broke the
      enumeration of some devices (maxpacket != 8) pretty early.
      
      This patch updates EHCI to fix the bug, and does minor cleanup to usbcore
      logic that figures out ep0 maxpacket.  I left the partial read in for all
      speeds, even though only full speed needs it.
      be75e771
    • Arnaud Quette's avatar
      [PATCH] drivers/usb/input/hiddev.c: fix hiddev_connect issue when · 1200021c
      Arnaud Quette authored
      The following one line patch (against 2.5.44) fixes an index problem when
      connecting a new hiddev
      device, when kernel isn't compiled with CONFIG_USB_DYNAMIC_MINORS. Previous
      attempt to open
      hiddev device terminated with an ENODEV error. Note that this fix works with
      either dynamic minors
      flag enabled or not.
      1200021c
  5. 22 Oct, 2002 1 commit
  6. 21 Oct, 2002 8 commits
    • John Tyner's avatar
      [PATCH] drivers/usb/media/vicam.c: simplify vicam_read · fddc87bb
      John Tyner authored
      > The following patch removes the old framebuf_size and framebuf_read_start
      > values from the cam structure and simplifes the read function. It also
      > moves the needs dummy read check into the read_frame function. cp and dd
      > should both still work.
      
      This is in addition to the previous patch. It should allow any programs
      that read entire frames to receive a new frame with each successive read.
      Programs that read less than the entire frame will read until they reach
      the end of the frame. They will then read 0 bytes (signifying EOF). The
      next read will start the next frame.
      fddc87bb
    • John Tyner's avatar
      [PATCH] drivers/usb/media/vicam.c: simplify vicam_read · 001e41c0
      John Tyner authored
      The following patch removes the old framebuf_size and framebuf_read_start
      values from the cam structure and simplifes the read function. It also
      moves the needs dummy read check into the read_frame function. cp and dd
      should both still work.
      001e41c0
    • Stuart MacDonald's avatar
      [PATCH] More wh patches · a0992864
      Stuart MacDonald authored
      Inlined are a few more patches to 2.5.43 that fix problems that
      were discovered during QA.
      
      1-firm4.07 :: I've moved to the bottom since it's huge
      
      Updates the firmware to 4.07. Fixes a bug introduced in 4.05 where
      RTS is high after boot. Also fixes a bug where the whiteheat would
      allow data reception after boot when no ports were open.
      
      2-fix-dtr-rts
      
      I didn't know this, but the firmware open command also handles
      raising the signals for me. This code is superflous.
      
      3-fix-read-urb
      
      Read polling was started right away in whiteheat_open(). Coupled
      with the firmware bug fixed above where data could be received
      by a port that wasn't open, this caused the whiteheat_read_callback
      to fire before open() was finished, and in some cases this caused
      harm to the tty layer. I didn't track down the exact mechanism
      because either moving the read polling to the last operation of open()
      or using the fixed firmware caused the crash to stop happening. I
      have stack traces if you'd like to have a look; it looks like something
      scribbles on the stack, but I couldn't figure out what eactly, as the
      scribbled data didn't match anything in the whiteheat driver or the
      test applications.
      
      4-fix-ixoff
      
      RELEVANT_IFLAG masks off the software flow control bits, so that
      a change that is restricted to the soft flow bits will be ignored. This
      is the email I sent earlier; I've decided to just not use the macro for
      now, but I'd still like to know if the macro should be fixed,.
      
      ..Stu
      a0992864
    • Oliver Neukum's avatar
      cc98907e
    • David Brownell's avatar
      [PATCH] usb: problem clearing halts · 236d8160
      David Brownell authored
      This is a slightly cleaned up version of that earlier patch:
      
      - Makes both copies of the clear_halt() logic know that
         usb_pipein() returns boolean (zero/not) not integer (0/1).
         This resolves a problem folk have had with usb-storage.
         (I looked at kernel uses of usb_pipein and it really was
         only the clear_halt logic that cares.)
      
      - Removes some code from the "standard" version; no point
         in Linux expecting devices to do something neither Microsoft
         nor Apple will test for.
      236d8160
    • David Brownell's avatar
      [PATCH] usbnet, preliminary zaurus support · 2c6bb9c0
      David Brownell authored
      This is Pavel's patch, with some cleanups and re-sorting of
      the various SA-1100 cases.  According to Pavel this works
      as well as his earlier version ... which is to say, maybe
      not yet, he saw a uhci "very bad" error (on 2.5.43).
      
      I'm sending it along since it's clearly the right way to
      support the Zaurus, and it can't be that far off given the
      code I've seen.
      2c6bb9c0
    • David Brownell's avatar
      [PATCH] ohci-hcd, longer bios handshake timeout · d8bf5435
      David Brownell authored
      This should resolve the problems Nicolas Mailhot reported,
      where an old BIOS seemed reluctant to release the controller
      and the dbg() message delayed things enough to work.  At
      worst, it'll eliminate dbg() messages as a factor.
      d8bf5435
    • Greg Kroah-Hartman's avatar
      [PATCH] USB: added support for Clie NX60 device. · 05a3b5ee
      Greg Kroah-Hartman authored
      Thanks to Hiroyuki ARAKI <hiro@zob.ne.jp> for the information.
      05a3b5ee
  7. 18 Oct, 2002 20 commits
    • Linus Torvalds's avatar
      Linux v2.5.44 · ecf2c214
      Linus Torvalds authored
      ecf2c214
    • Patrick Mochel's avatar
      [PATCH] device removal · a49c4f6a
      Patrick Mochel authored
      The problem was that when the refcount hit 0, it was unconditionally
      assuming that it had been added, which is wrong.  The patch below
      corrects that, and fixes the Oops when loading the floppy driver.
      a49c4f6a
    • Linus Torvalds's avatar
      Merge bk://linuxusb.bkbits.net/pnp-2.5 · 441a964b
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      441a964b
    • Linus Torvalds's avatar
      Merge home.transmeta.com:/home/torvalds/v2.5/x86-64 · 76dd2761
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      76dd2761
    • Andi Kleen's avatar
      [PATCH] add linux/ioctl32.h header for 2.5.43 · 1a19232d
      Andi Kleen authored
      Several ports (x86-64,ppc64,sparc64) which do 32bit ioctl emulation
      have functions for drivers to let them define their own translation
      handlers. So far it was a bit complicated to use because there
      was no standard include file that declares the prototypes for this
      stuff. Then drivers and other subsystems can start to declare their own
      ioctl translation handlers.
      
      This patch add include/linux/ioctl32.h to fix this.
      
      The actual implementation is in arch specific code. It has been coordinated
      with DaveM and Anton.
      
      This patch is needed for the x86-64 merge I sent in separate mail.
      
      There is currently no preprocessor symbol that the drivers can test
      to see if they should use this. So far they have to check arch symbols.
      This will be fixed later when all 64bit ports that need it add the dynamic
      ioctl registration API too (that's ia64,s390x,mips64)
      1a19232d
    • Andi Kleen's avatar
      [PATCH] x86-64 updates for 2.5.43 · 3428c8d1
      Andi Kleen authored
      This fixes a few files that got lost with the last merge and merges
      with 2.5.43/i386.  Only changes architecture specific files.
      
      It depends on one other patch (for linux/ioctl32.h) which I'm sending
      separately.
      
      Changes:
      - Include missing files (pageattr.c) and Makefile changes
      - Update IA32 subsystem. Various small fixes and a big merge
        with sparc64.
      - Change HZ to 1000
      - Merge some of the 2.5.43/i386 profiling changes. No full oprofile yet.
      - Fix many warnings
      - Update defconfig
      - Various other smaller cleanups and bugfixes.
      3428c8d1
    • Alexander Viro's avatar
      [PATCH] stram switched to private queue · 1e215a63
      Alexander Viro authored
              * switched to private queues
              * set ->queue
      1e215a63
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/davem/BK/sparc-2.5 · 50fbecd2
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      50fbecd2
    • Alexander Viro's avatar
      [PATCH] nbd converted to private queue · 646fdb02
      Alexander Viro authored
              * switched to private queues
              * set ->queue and ->private_data
              * switched to use of ->bd_disk/->rq_disk
              * merged private blocksize, etc. arrays into nbd_dev[]
              * cleaned up
      646fdb02
    • Alexander Viro's avatar
      [PATCH] jsfd converted to use of private queue · 45552206
      Alexander Viro authored
              * switched to private queues
              * set ->queue and ->private_data
      	* switched to use of ->rq_disk
      45552206
    • Alexander Viro's avatar
      [PATCH] compile fixes · dceb2f49
      Alexander Viro authored
      	sbpcd.c: removes bogus duplicate definition of sbpcd_lock, use of
      CURRENT (we are using private queue) and call of invalidate_buffers() in
      ->media_changed() (caller does it itself).  That went in a changeset from
      davej - looks like a merge problem...
      	sr.c: braino in ifdefed printk - s/disk/cd->disk/.  Thanks to jejb
      for spotting that one...
      dceb2f49
    • Linus Torvalds's avatar
      Merge bk://linux-bt.bkbits.net/bt-2.5 · b1084bc3
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      b1084bc3
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/davem/BK/net-2.5 · f8735053
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      f8735053
    • David S. Miller's avatar
      Merge nuts.ninka.net:/home/davem/src/BK/sparcwork-2.5 · 07a6661a
      David S. Miller authored
      into nuts.ninka.net:/home/davem/src/BK/sparc-2.5
      07a6661a
    • David S. Miller's avatar
      50652320
    • Linus Torvalds's avatar
      Merge · ddd11110
      Linus Torvalds authored
      ddd11110
    • Dipankar Sarma's avatar
      [PATCH] RCU helper patchset 2/2 · a0b6c9c1
      Dipankar Sarma authored
      This adds a set of list macros that make handling of list protected
      by RCU simpler. The interfaces added are -
      
      list_add_rcu
      list_add_tail_rcu
      	- Adds an element by taking care of memory barrier (wmb()).
      
      list_del_rcu
      	- Deletes an element but doesn't re-initialize the pointers in
      	  the element for supporting RCU based traversal.
      
      list_for_each_rcu
      __list_for_each_rcu
      	- Traversal of RCU protected list - takes care of memory barriers
      	  transparently.
      a0b6c9c1
    • Dipankar Sarma's avatar
      [PATCH] RCU helper patchset 1/2 · 0ec69870
      Dipankar Sarma authored
      This first RCU helper patch adds a read_barrier_depends() primitive
      to all archs which is NOP for archs that doesn't require an rmb()
      for data dependent reads when writes are ordered using a wmb().
      In reality, only alpha requires an rmb(), the rest are NOPs.
      It is likely to be necessary in most situations that would use RCU.
      Please apply.
      
       Description :
      
      Sometime ago, during a discussion on lock-free lookups, it was
      agreed that an additional memory barrier interface,
      read_barrier_depends() that is lighter than an rmb(),
      is necessary to make sure that data-dependent reads are not
      re-ordered over this barrier. For many processors, data-dependency
      enforces order, so this interface is a NOP, but for those that don't
      (like alpha), it can be a rmb().
      
      For example, the following code would force ordering (the initial
      value of "a" is zero, "b" is one, and "p" is "&a"):
      
          CPU 0                           CPU 1
      
          b = 2;
          memory_barrier();
          p = &b;                         q = p;
                                          read_barrier_depends();
                                          d = *q;
      
      because the read of "*q" depends on the read of "p" and these
      two reads should be separated by a read_barrier_depends().  However,
      the following code, with the same initial values for "a" and "b":
      
          CPU 0                           CPU 1
      
          a = 2;
          memory_barrier();
          b = 3;                          y = b;
                                          read_barrier_depends();
                                          x = a;
      
      does not enforce ordering, since there is no data dependency between
      the read of "a" and the read of "b".  Therefore, on some CPUs, such
      as Alpha, "y" could be set to 3 and "x" to 0.  rmb()
      needs to be used here, not read_barrier_depends().
      
      The original discussion can be found at -
      http://marc.theaimsgroup.com/?t=100259422200002&r=1&w=2
      
      Explanation of the need for read_barrier_depends()
      can be found at http://lse.sf.net/locking/wmbdd.html
      0ec69870
    • David S. Miller's avatar
      0694164e
    • Frank Davis's avatar
      [PATCH] drivers/block/xd.c compile · c192e519
      Frank Davis authored
      This fixes a 'used but not declared' compile error
      c192e519