linux/drivers/usb, branch v2.6.14

[PATCH] USB: fix bug in handling of highspeed usb HID devices

2005-10-17T21:45:49Z

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: Christian Krause Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] isp116x-hcd: fix handling of short transfers

2005-10-17T21:45:49Z

Increased use of scatter-gather by usb-storage driver after 2.6.13 has exposed a buggy codepath in isp116x-hcd, which was probably never visited before: bug happened only for those urbs, for which URB_SHORT_NOT_OK was set AND short transfer occurred. The fix attached was tested in 2 ways: (a) it fixed failing initialization of a flash drive with an embedded hub; (b) the fix was tested with 'usbtest' against a modified g_zero driver (on top of net2280), which generated short bulk IN transfers of various lengths including multiples and non-multiples of max_packet_length. Signed-off-by: Olav Kongas Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] usbserial: Regression in USB generic serial driver

2005-10-15T01:13:31Z

Kernel version 2.6.13 introduced a regression in the generic USB serial converter driver (usbserial.o, drivers/usb/serial/generic.c). The bug manifests, as far as I can tell, whenever you attempt to write to the device -- the write will never complete (write() returns 0, or blocks). Signed-off-by: Randall Nortman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

Use the new "kill_proc_info_as_uid()" for USB disconnect too

2005-10-10T23:31:30Z

All the same issues - we can't just save the pointer to the thread, we must save the pid/uid/euid combination. Signed-off-by: Linus Torvalds

[PATCH] Fix signal sending in usbdevio on async URB completion

2005-10-10T23:16:33Z

If a process issues an URB from userspace and (starts to) terminate before the URB comes back, we run into the issue described above. This is because the urb saves a pointer to "current" when it is posted to the device, but there's no guarantee that this pointer is still valid afterwards. In fact, there are three separate issues: 1) the pointer to "current" can become invalid, since the task could be completely gone when the URB completion comes back from the device. 2) Even if the saved task pointer is still pointing to a valid task_struct, task_struct->sighand could have gone meanwhile. 3) Even if the process is perfectly fine, permissions may have changed, and we can no longer send it a signal. So what we do instead, is to save the PID and uid's of the process, and introduce a new kill_proc_info_as_uid() function. Signed-off-by: Harald Welte [ Fixed up types and added symbol exports ] Signed-off-by: Linus Torvalds

[PATCH] usb/core/hcd-pci.c: don't free_irq() on suspend

2005-09-30T16:23:30Z

the free_irq() in USB suspend breaks resume on some setups where USB (ohci/ehci) shares the interrupt with an other device. Signed-off-by: Daniel Ritz Signed-off-by: Linus Torvalds

Merge master.kernel.org:/home/rmk/linux-2.6-arm

2005-09-30T15:39:56Z

[PATCH] proc_mkdir() should be used to create procfs directories

2005-09-29T15:46:26Z

A bunch of create_proc_dir_entry() calls creating directories had crept in since the last sweep; converted to proc_mkdir(). Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[ARM] Don't include mach-types.h unnecessarily

2005-09-29T10:15:51Z

It's pointless to include mach-types.h if you're not going to use anything from it. These references were removed as a result of: grep -lr 'asm/mach-types\.h' . | xargs grep -L 'machine_is_\|MACH_TYPE_\|MACHINE_START\|machine_type' Signed-off-by: Russell King

[ARM] Don't include asm/arch/hardware.h directly

2005-09-29T10:12:52Z

Since asm/hardware.h's only reason for existing is to include asm/arch/hardware.h, it's completely pointless to include both. Signed-off-by: Russell King