linux-toradex.git/drivers/usb/core, branch v2.6.35.8

USB: fix bug in initialization of interface minor numbers

2010-10-29T04:51:06+00:00

commit 0026e00523a85b90a92a93ddf6660939ecef3e54 upstream.

Recent changes in the usbhid layer exposed a bug in usbcore.  If
CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned
a minor number of 0.  However interfaces that aren't registered as USB
class devices also have their minor number set to 0, during
initialization.  As a result usb_find_interface() may return the
wrong interface, leading to a crash.

This patch (as1418) fixes the problem by initializing every
interface's minor number to -1.  It also cleans up the
usb_register_dev() function, which besides being somewhat awkwardly
written, does not unwind completely on all its error paths.

Signed-off-by: Alan Stern 
Tested-by: Philip J. Turmel 
Tested-by: Gabriel Craciunescu 
Tested-by: Alex Riesen 
Tested-by: Matthias Bayer 
CC: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

usb: allow drivers to use allocated bandwidth until unbound

2010-09-20T20:36:20+00:00

commit 0791971ba8fbc44e4f476079f856335ed45e6324 upstream.

When using the remove sysfs file, the device configuration is set to -1
(unconfigured). This eventually unbind drivers with the bandwidth_mutex
held. Some drivers may call functions that hold said mutex, like
usb_reset_device. This is the case for rtl8187, for example. This will
lead to the same process holding the mutex twice, which deadlocks.

Besides, according to Alan Stern:
"The deadlock problem probably could be handled somehow, but there's a
separate issue: Until the usb_disable_device call finishes unbinding
the drivers, the drivers are free to continue using their allocated
bandwidth.  We musn't change the bandwidth allocations until after the
unbinding is done.  So this patch is indeed necessary."

Unbinding the driver before holding the bandwidth_mutex solves the
problem. If any operation after that fails, drivers are not bound again.
But that would be a problem anyway that the user may solve resetting the
device configuration to one that works, just like he would need to do in
most other failure cases.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Cc: Alan Stern 
Cc: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

USB: fix thread-unsafe anchor utiliy routines

2010-08-13T20:31:01+00:00

commit b3e670443b7fb8a2d29831b62b44a039c283e351 upstream.

This patch fixes a race condition in two utility routines
related to the removal/unlinking of urbs from an anchor.

If two threads are concurrently accessing the same anchor,
both could end up with the same urb - thinking they are
the exclusive owner.

Alan Stern pointed out a related issue in
usb_unlink_anchored_urbs:

"The URB isn't removed from the anchor until it completes
 (as a by-product of completion, in fact), which might not
 be for quite some time after the unlink call returns.
 In the meantime, the subroutine will keep trying to unlink
 it, over and over again."

Cc: Oliver Neukum 
Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

USB delay init quirk for logitech Harmony 700-series devices

2010-08-13T20:30:58+00:00

commit 93362a875fc69881ae69299efaf19a55a1f57db0 upstream.

The Logitech Harmony 700 series needs an extra delay during
initialization.  This patch adds a USB quirk which enables such a delay
and adds the device to the quirks list.

Signed-off-by: Phil Dibowitz 
Signed-off-by: Greg Kroah-Hartman

USB: add quirk for Broadcom BT dongle

2010-07-26T19:00:58+00:00

This device needs to be reset when resuming

Signed-off-by: Oliver Neukum 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: adds Artisman USB dongle to list of quirky devices

2010-07-26T19:00:58+00:00

When an attempt is made to read the interface strings of the Artisman
Watchdog USB dongle (idVendor:idProduct 04b4:0526) an error is written
to the dmesg log (uhci_result_common: failed with status 440000) and the
dongle resets itself, resulting in a disconnect/reconnect loop.

Adding the dongle to the list of devices in quirks.c, with the same
quirk Alan Stern's previous patch for the Saitek Cyborg Gold 3D
joystick, stops the device from resetting and allows it to be used with
no problems.

Signed-off-by: Paul Mortier 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: Fix USB3.0 Port Speed Downgrade after port reset

2010-07-26T19:00:58+00:00

Without this fix, a USB 3.0 port is downgraded to full speed after a port
reset of a configured device.  The USB 3.0 terminations will be disabled
permanently, and USB 3.0 devices will always enumerate as full speed
devices, until the host controller is unplugged (if it is an ExpressCard)
or the computer is rebooted.

Fajun Chen traced this traced the speed downgrade issue to the port reset
and the interpretation of port status in USB hub driver code.  The hub
code was not testing for the port being a SuperSpeed port, and it fell
through to the else case of Full Speed.

The following patch adds SuperSpeed mapping from the port status, and
fixes the speed downgrade issue.

Reported-by: Fajun Chen 
Signed-off-by: Sarah Sharp 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: obey the sysfs power/wakeup setting

2010-06-30T15:16:06+00:00

This patch (as1403) is a partial reversion of an earlier change
(commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e "USB: fix remote
wakeup settings during system sleep").  After hearing from a user, I
realized that remote wakeup should be enabled during system sleep
whenever userspace allows it, and not only if a driver requests it
too.

Indeed, there could be a device with no driver, that does nothing but
generate a wakeup request when the user presses a button.  Such a
device should be allowed to do its job.

The problem fixed by the earlier patch -- device generating a wakeup
request for no reason, causing system suspend to abort -- was also
addressed by a later patch ("USB: don't enable remote wakeup by
default", accepted but not yet merged into mainline).  The device
won't be able to generate the bogus wakeup requests because it will be
disabled for remote wakeup by default.  Hence this reversion will not
re-introduce any old problems.

Signed-off-by: Alan Stern 
Cc: stable  [.34]
Signed-off-by: Greg Kroah-Hartman

USB: fix oops in usb_sg_init()

2010-06-30T15:16:06+00:00

This patch (as1401) fixes a bug in usb_sg_init() that can cause an
invalid pointer dereference.  An inner loop reuses some local variables
in an unsafe manner, so new variables are introduced.

Signed-off-by: Alan Stern 
Tested-by: Ajay Kumar Gupta 
Signed-off-by: Greg Kroah-Hartman

USB: unbind all interfaces before rebinding them

2010-06-04T20:16:20+00:00

This patch (as1387) fixes a bug introduced during the changeover to
the runtime PM framework.  When a driver doesn't support resume or
reset-resume, and consequently its interfaces need to be unbound and
rebound, we have to unbind all the interfaces before trying to rebind
any of them.  Otherwise the driver's probe method for one interface
could try to claim a different interface and fail, because that other
interface hasn't been unbound yet.

This fixes Bugzilla #15788.  The symptom is that some USB sound cards
don't work after hibernation.

Signed-off-by: Alan Stern 
Tested-by: François Valenduc 
Cc: stable  [.34]
Signed-off-by: Greg Kroah-Hartman