linux-toradex.git/drivers/usb/core, branch v2.6.27.21 Linux kernel for Apalis and Colibri modules USB: usbfs: keep async URBs until the device file is closed 2009-03-23T22:00:12+00:00 Alan Stern stern@rowland.harvard.edu 2009-03-09T17:44:02+00:00 2de0d862426bc8fc36b9a65622ec00f92e6c6acf commit 6ff10464096540e14d7575a72c50d0316d003714 upstream. The usbfs driver manages a list of completed asynchronous URBs. But it is too eager to free the entries on this list: destroy_async() gets called whenever an interface is unbound or a device is removed, and it deallocates the outstanding struct async entries for all URBs on that interface or device. This is wrong; the user program should be able to reap an URB any time after it has completed, regardless of whether or not the interface is still bound or the device is still present. This patch (as1222) moves the code for deallocating the completed list entries from destroy_async() to usbdev_release(). The outstanding entries won't be freed until the user program has closed the device file, thereby eliminating any possibility that the remaining URBs might still be reaped. This fixes a bug in which a program can hang in the USBDEVFS_REAPURB ioctl when the device is unplugged. Reported-and-tested-by: Martin Poupe <martin.poupe@upek.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 6ff10464096540e14d7575a72c50d0316d003714 upstream.

The usbfs driver manages a list of completed asynchronous URBs.  But
it is too eager to free the entries on this list: destroy_async() gets
called whenever an interface is unbound or a device is removed, and it
deallocates the outstanding struct async entries for all URBs on that
interface or device.  This is wrong; the user program should be able
to reap an URB any time after it has completed, regardless of whether
or not the interface is still bound or the device is still present.

This patch (as1222) moves the code for deallocating the completed list
entries from destroy_async() to usbdev_release().  The outstanding
entries won't be freed until the user program has closed the device
file, thereby eliminating any possibility that the remaining URBs
might still be reaped.

This fixes a bug in which a program can hang in the USBDEVFS_REAPURB
ioctl when the device is unplugged.

Reported-and-tested-by: Martin Poupe <martin.poupe@upek.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: usb_get_string should check the descriptor type 2009-03-17T00:52:47+00:00 Alan Stern stern@rowland.harvard.edu 2009-02-20T21:33:08+00:00 030b079bbda2a3b1c37198b62bd955f2da0b9172 commit 67f5a4ba9741fcef3f4db3509ad03565d9e33af2 upstream. This patch (as1218) fixes a problem with a radio-control joystick used in the "walkera 4#3" helicopter. This device responds to the initial Get-String-Descriptor request for string 0 (which is really the list of supported languages) by sending its config descriptor! The usb_get_string() routine needs to check whether it got the right type of descriptor. Oddly enough, this sort of check is already present in usb_get_descriptor(). The patch changes the error code from -EPROTO to -ENODATA, because -EPROTO shows up in so many other contexts to indicate a hardware failure rather than a firmware error. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Guillermo Jarabo <williamjap@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 67f5a4ba9741fcef3f4db3509ad03565d9e33af2 upstream.

This patch (as1218) fixes a problem with a radio-control joystick used
in the "walkera 4#3" helicopter.  This device responds to the initial
Get-String-Descriptor request for string 0 (which is really the list
of supported languages) by sending its config descriptor!  The
usb_get_string() routine needs to check whether it got the right
type of descriptor.

Oddly enough, this sort of check is already present in
usb_get_descriptor().  The patch changes the error code from -EPROTO
to -ENODATA, because -EPROTO shows up in so many other contexts to
indicate a hardware failure rather than a firmware error.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Guillermo Jarabo <williamjap@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix char-device disconnect handling 2009-02-02T16:28:11+00:00 Alan Stern stern@rowland.harvard.edu 2009-01-13T16:33:42+00:00 bb74fdbb0c7138a397b58141791eae4b2e7e4cfe commit 501950d846218ed80a776d2aae5aed9c8b92e778 upstream. This patch (as1198) fixes a conceptual bug: Somewhere along the line we managed to confuse USB class devices with USB char devices. As a result, the code to send a disconnect signal to userspace would not be built if both CONFIG_USB_DEVICE_CLASS and CONFIG_USB_DEVICEFS were disabled. The usb_fs_classdev_common_remove() routine has been renamed to usbdev_remove() and it is now called whenever any USB device is removed, not just when a class device is unregistered. The notifier registration and unregistration calls are no longer conditionally compiled. And since the common removal code will always be called as part of the char device interface, there's no need to call it again as part of the usbfs interface; thus the invocation of usb_fs_classdev_common_remove() has been taken out of usbfs_remove_device(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Alon Bar-Lev <alon.barlev@gmail.com> Tested-by: Alon Bar-Lev <alon.barlev@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 501950d846218ed80a776d2aae5aed9c8b92e778 upstream.

This patch (as1198) fixes a conceptual bug: Somewhere along the line
we managed to confuse USB class devices with USB char devices.  As a
result, the code to send a disconnect signal to userspace would not be
built if both CONFIG_USB_DEVICE_CLASS and CONFIG_USB_DEVICEFS were
disabled.

The usb_fs_classdev_common_remove() routine has been renamed to
usbdev_remove() and it is now called whenever any USB device is
removed, not just when a class device is unregistered.  The notifier
registration and unregistration calls are no longer conditionally
compiled.  And since the common removal code will always be called as
part of the char device interface, there's no need to call it again as
part of the usbfs interface; thus the invocation of
usb_fs_classdev_common_remove() has been taken out of
usbfs_remove_device().

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Alon Bar-Lev <alon.barlev@gmail.com>
Tested-by: Alon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: don't register endpoints for interfaces that are going away 2008-11-20T22:54:53+00:00 Alan Stern stern@rowland.harvard.edu 2008-10-29T19:16:58+00:00 5a4c6fe7a2fe3a81921832af856621b8f8231814 commit 352d026338378b1f13f044e33c1047da6e470056 upstream. This patch (as1155) fixes a bug in usbcore. When interfaces are deleted, either because the device was disconnected or because of a configuration change, the extra attribute files and child endpoint devices may get left behind. This is because the core removes them before calling device_del(). But during device_del(), after the driver is unbound the core will reinstall altsetting 0 and recreate those extra attributes and children. The patch prevents this by adding a flag to record when the interface is in the midst of being unregistered. When the flag is set, the attribute files and child devices will not be created. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 352d026338378b1f13f044e33c1047da6e470056 upstream.

This patch (as1155) fixes a bug in usbcore.  When interfaces are
deleted, either because the device was disconnected or because of a
configuration change, the extra attribute files and child endpoint
devices may get left behind.  This is because the core removes them
before calling device_del().  But during device_del(), after the
driver is unbound the core will reinstall altsetting 0 and recreate
those extra attributes and children.

The patch prevents this by adding a flag to record when the interface
is in the midst of being unregistered.  When the flag is set, the
attribute files and child devices will not be created.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix crash when URBs are unlinked after the device is gone 2008-11-07T03:05:38+00:00 Alan Stern stern@rowland.harvard.edu 2008-10-30T19:10:11+00:00 ce372e05a1442405eed3e386205ad401307cea61 commit cde217a556ec552d28ac9e136c5a94684a69ae94 upstream This patch (as1151) protects usbcore against drivers that try to unlink an URB after the URB's device or bus have been removed. The core does not currently check for this, and certain drivers can cause a crash if they are running while an HCD is unloaded. Certainly it would be best to fix the guilty drivers. But a little defensive programming doesn't hurt, especially since it appears that quite a few drivers need to be fixed. The patch prevents the problem by grabbing a reference to the device while an unlink is in progress and using a new spinlock to synchronize unlinks with device removal. (There's no need to acquire a reference to the bus as well, since the device structure itself keeps a reference to the bus.) In addition, the kerneldoc is updated to indicate that URBs should not be unlinked after the disconnect method returns. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit cde217a556ec552d28ac9e136c5a94684a69ae94 upstream

This patch (as1151) protects usbcore against drivers that try to
unlink an URB after the URB's device or bus have been removed.  The
core does not currently check for this, and certain drivers can cause
a crash if they are running while an HCD is unloaded.

Certainly it would be best to fix the guilty drivers.  But a little
defensive programming doesn't hurt, especially since it appears that
quite a few drivers need to be fixed.

The patch prevents the problem by grabbing a reference to the device
while an unlink is in progress and using a new spinlock to synchronize
unlinks with device removal.  (There's no need to acquire a reference
to the bus as well, since the device structure itself keeps a
reference to the bus.)  In addition, the kerneldoc is updated to
indicate that URBs should not be unlinked after the disconnect method
returns.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: don't rebind drivers after failed resume or reset 2008-10-25T21:32:38+00:00 Alan Stern stern@rowland.harvard.edu 2008-10-23T17:35:07+00:00 1769c339cde4c1da819ee97513e9340413cef3c5 commit 6c6409459a18a825ce12ecb003d5686af61f7a2f upstream This patch (as1152) may help prevent some problems associated with the new policy of unbinding drivers that don't support suspend/resume or pre_reset/post_reset. If for any reason the resume or reset fails, and the device is logically disconnected, there's no point in trying to rebind the driver. So the patch checks for success before carrying out the unbind/rebind. There was a report from one user that this fixed a problem he was experiencing, but the details never became fully clear. In any case, adding these tests can't hurt. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 6c6409459a18a825ce12ecb003d5686af61f7a2f upstream

This patch (as1152) may help prevent some problems associated with the
new policy of unbinding drivers that don't support suspend/resume or
pre_reset/post_reset.  If for any reason the resume or reset fails, and
the device is logically disconnected, there's no point in trying to
rebind the driver.  So the patch checks for success before carrying
out the unbind/rebind.

There was a report from one user that this fixed a problem he was
experiencing, but the details never became fully clear.  In any case,
adding these tests can't hurt.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: log a warning if ehci-hcd is not loaded first 2008-10-22T21:21:22+00:00 Alan Stern stern@rowland.harvard.edu 2008-10-17T23:10:07+00:00 c78487b1d935d938014ddbec7b3d5816c1580fce commit 9beeee6584b9aa4f9192055512411484a2a624df upstream This patch (as1139) adds a warning to the system log whenever ehci-hcd is loaded after ohci-hcd or uhci-hcd. Nowadays most distributions are pretty good about not doing this; maybe the warning will help convince anyone still doing it wrong. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 9beeee6584b9aa4f9192055512411484a2a624df upstream

This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd.  Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: revert recovery from transient errors 2008-09-23T20:58:10+00:00 Alan Stern stern@rowland.harvard.edu 2008-09-22T18:43:08+00:00 5257d97a219e17abf8188f136e1189da3b3af33c This patch (as1135) essentially reverts the major parts of two earlier patches to usbcore, because they ended up causing a regression. Trying to recover from transient communication errors can lead to other problems, because operations that failed during the error period are not always retried. The simplest example is the initial Set-Config request sent after device enumeration; if it gets lost then it will not be retried and the device will remain unconfigured. This patch restores the old behavior in which any port disconnect or port disable causes the entire device structure to be removed, fixing a reported regression. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch (as1135) essentially reverts the major parts of two earlier
patches to usbcore, because they ended up causing a regression.

Trying to recover from transient communication errors can lead to
other problems, because operations that failed during the error period
are not always retried.  The simplest example is the initial
Set-Config request sent after device enumeration; if it gets lost then
it will not be retried and the device will remain unconfigured.

This patch restores the old behavior in which any port disconnect or
port disable causes the entire device structure to be removed, fixing a
reported regression.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix hcd interrupt disabling 2008-09-23T20:58:06+00:00 Geoff Levand geoffrey.levand@am.sony.com 2008-08-22T21:13:00+00:00 83a798207361cc26385187b2e71efa2b5d75de7f Commit de85422b94ddb23c021126815ea49414047c13dc, 'USB: fix interrupt disabling for HCDs with shared interrupt handlers' changed usb_add_hcd() to strip IRQF_DISABLED from irqflags prior to calling request_irq() with the justification that such a removal was necessary for shared interrupts to work properly. Unfortunately, the change in that commit unconditionally removes the IRQF_DISABLED flag, causing problems on platforms that don't use a shared interrupt but require IRQF_DISABLED. This change adds a check for IRQF_SHARED prior to removing the IRQF_DISABLED flag. Fixes the PS3 system startup hang reported with recent Fedora and OpenSUSE kernels. Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig), as local_irq_enable_in_hardirq() is defined as a null statement for that config. CC: stable <stable@kernel.org> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Stefan Becker <Stefan.Becker@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Commit de85422b94ddb23c021126815ea49414047c13dc, 'USB: fix interrupt
disabling for HCDs with shared interrupt handlers' changed usb_add_hcd()
to strip IRQF_DISABLED from irqflags prior to calling request_irq()
with the justification that such a removal was necessary for shared
interrupts to work properly.  Unfortunately, the change in that commit
unconditionally removes the IRQF_DISABLED flag, causing problems on
platforms that don't use a shared interrupt but require IRQF_DISABLED.
This change adds a check for IRQF_SHARED prior to removing the
IRQF_DISABLED flag.

Fixes the PS3 system startup hang reported with recent Fedora and
OpenSUSE kernels.

Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig),
as local_irq_enable_in_hardirq() is defined as a null statement for
that config.

CC: stable <stable@kernel.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Stefan Becker <Stefan.Becker@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: automatically enable RHSC interrupts 2008-08-21T17:26:38+00:00 Alan Stern stern@rowland.harvard.edu 2008-08-20T21:22:05+00:00 b5fb454f69642f9d933b327b185a2ba06dd0945c This patch (as1069c) changes the way OHCI root-hub status-change interrupts are enabled. Currently a special HCD method, hub_irq_enable(), is called when the hub driver is finished using a root hub. This approach turns out to be subject to races, resulting in unnecessary polling. The patch does away with the method entirely. Instead, the driver automatically enables the RHSC interrupt when no more status changes are present. This scheme is safe with controllers using level-triggered semantics for their interrupt flags. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch (as1069c) changes the way OHCI root-hub status-change
interrupts are enabled.  Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub.  This approach turns out to be subject to races, resulting
in unnecessary polling.

The patch does away with the method entirely.  Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present.  This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>