1. 29 10月, 2005 1 次提交
  2. 18 10月, 2005 1 次提交
    • C
      [PATCH] USB: fix bug in handling of highspeed usb HID devices · 13b58ee5
      Christian Krause 提交于
      During the development of an USB device I found a bug in the handling of
      Highspeed HID devices in the kernel.
      
      What happened?
      
      Highspeed HID devices are correctly recognized and enumerated by the
      kernel. But even if usbhid kernel module is loaded, no HID reports are
      received by the kernel.
      
      The output of the hardware USB analyzer told me that the host doesn't
      even poll for interrupt IN transfers (even the "interrupt in" USB
      transfer are polled by the host).
      
      After some debugging in hid-core.c I've found the reason.
      
      In case of a highspeed device, the endpoint interval is re-calculated in
      driver/usb/input/hid-core.c:
      
      line 1669:
                   /* handle potential highspeed HID correctly */
                   interval = endpoint->bInterval;
                   if (dev->speed == USB_SPEED_HIGH)
                         interval = 1 << (interval - 1);
      
      Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6).
      This new calculated value of "interval" is used as input for
      usb_fill_int_urb:
      
      line 1685:
      
                  usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0,
                         hid_irq_in, hid, interval);
      
      Unfortunately the same calculation as above is done a second time in
      usb_fill_int_urb in the file include/linux/usb.h:
      
      line 933:
              if (dev->speed == USB_SPEED_HIGH)
                      urb->interval = 1 << (interval - 1);
              else
                      urb->interval = interval;
      
      This means, that if the endpoint descriptor (of a high speed device)
      specifies e.g. bInterval = 7, the urb->interval gets the value:
      
      hid-core.c: interval = 1 << (7-1) = 0x40 = 64
      urb->interval = 1 << (interval -1) = 1 << (63) = integer overflow
      
      Because of this the value of urb->interval is sometimes negative and is
      rejected in core/urb.c:
      line 353:
                      /* too small? */
                      if (urb->interval <= 0)
                              return -EINVAL;
      
      The conclusion is, that the recalculaton of the interval (which is
      necessary for highspeed) should not be made twice, because this is
      simply wrong. ;-)
      
      Re-calculation in usb_fill_int_urb makes more sense, because it is the
      most general approach. So it would make sense to remove it from
      hid-core.c.
      
      Because in hid-core.c the interval variable is only used for calling
      usb_fill_int_urb, it is no problem to remove the highspeed
      re-calculation in this file.
      Signed-off-by: NChristian Krause <chkr@plauener.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      13b58ee5
  3. 13 9月, 2005 1 次提交
  4. 09 9月, 2005 2 次提交
    • A
      [PATCH] USB: URB_ASYNC_UNLINK flag removed from the kernel · b375a049
      Alan Stern 提交于
      29 July 2005, Cambridge, MA:
      
      This afternoon Alan Stern submitted a patch to remove the URB_ASYNC_UNLINK
      flag from the Linux kernel.  Mr. Stern explained, "This flag is a relic
      from an earlier, less-well-designed system.  For over a year it hasn't
      been used for anything other than printing warning messages."
      
      An anonymous spokesman for the Linux kernel development community
      commented, "This is exactly the sort of thing we see happening all the
      time.  As the kernel evolves, support for old techniques and old code can
      be jettisoned and replaced by newer, better approaches.  Proprietary
      operating systems do not have the freedom or flexibility to change so
      quickly."
      
      Mr. Stern, a staff member at Harvard University's Rowland Institute who
      works on Linux only as a hobby, noted that the patch (labelled as548) did
      not update two files, keyspan.c and option.c, in the USB drivers' "serial"
      subdirectory.  "Those files need more extensive changes," he remarked.
      "They examine the status field of several URBs at times when they're not
      supposed to.  That will need to be fixed before the URB_ASYNC_UNLINK flag
      is removed."
      
      Greg Kroah-Hartman, the kernel maintainer responsible for overseeing all
      of Linux's USB drivers, did not respond to our inquiries or return our
      calls.  His only comment was "Applied, thanks."
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b375a049
    • A
      [PATCH] USB: Prevent hid-core claiming Apple Bluetooth device on new G4 powerbooks · 22af8878
      Andrew de Quincey 提交于
      To recap: My new G4 powerbook has a bluetooth device that boots up in
      what apppears to be a compatability mode - it looks exactly like an HID
      keyboard/mouse device.
      
      A special command sequence is sent to switch it into full bluetooth
      mode. When this occurs the original HID device vanishes, and a new
      (bluetooth HID) USB device appears on the bus with a different product
      ID.
      
      The original thread is here:
      http://sourceforge.net/mailarchive/message.php?msg_id=12532263
      
      The attached patch adds the device to the hid-core quirks so that
      hid-core ignores it.
      Signed-off-by: NAndrew de Quincey <adq_dvb@lidskialf.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      22af8878
  5. 05 9月, 2005 5 次提交
  6. 13 7月, 2005 1 次提交
  7. 11 7月, 2005 2 次提交
  8. 23 6月, 2005 1 次提交
  9. 06 6月, 2005 1 次提交
  10. 03 6月, 2005 3 次提交
  11. 29 5月, 2005 4 次提交
  12. 19 4月, 2005 2 次提交
    • J
      [PATCH] USB: kfree cleanup for drivers/usb/* - no need to check for NULL · 1bc3c9e1
      Jesper Juhl 提交于
      Get rid of a bunch of redundant NULL pointer checks in drivers/usb/*,
      there's no need to check a pointer for NULL before calling kfree() on it.
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      
      Index: gregkh-2.6/drivers/usb/class/audio.c
      ===================================================================
      1bc3c9e1
    • D
      [PATCH] usb suspend updates (interface suspend) · 27d72e85
      David Brownell 提交于
      This is the first of a few installments of PM API updates to match the
      recent switch to "pm_message_t".  This installment primarily affects
      USB device drivers (for USB interfaces), and it changes the handful of
      drivers which currently implement suspend methods:
      
          - <linux/usb.h> and usbcore, signature change
      
          - Some drivers only changed the signature, net effect this just
            shuts up "sparse -Wbitwise":
      	* hid-core
      	* stir4200
      
          - Two network drivers did that, and also grew slightly more
            featureful suspend code ... they now properly shut down
            their activities.  (As should stir4200...)
      	* pegasus
      	* usbnet
      
      Note that the Wake-On-Lan (WOL) support in pegasus doesn't yet work; looks
      to me like it's missing a request to turn it on, vs just configuring it.
      The ASIX code in usbnet also has WOL hooks that are ready to use; untested.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      Index: gregkh-2.6/drivers/net/irda/stir4200.c
      ===================================================================
      27d72e85
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4