linux-stable.git/drivers/usb/core, branch v3.0.9 Linux kernel stable tree USB: Update last_busy time after autosuspend fails 2011-11-11T17:36:57+00:00 Alan Stern stern@rowland.harvard.edu 2011-11-03T23:52:46+00:00 5432c16a57990f12d41f57ed99ba194c368c30d0 commit b2c0a863e14676fa5760c6d828fd373288e2f64a upstream. Originally, the runtime PM core would send an idle notification whenever a suspend attempt failed. The idle callback routine could then schedule a delayed suspend for some time later. However this behavior was changed by commit f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle notification after failing suspend). No notifications were sent, and there was no clear mechanism to retry failed suspends. This caused problems for the usbhid driver, because it fails autosuspend attempts as long as a key is being held down. A companion patch changes the PM core's behavior, but we also need to change the USB core. In particular, this patch (as1493) updates the device's last_busy time when an autosuspend fails, so that the PM core will retry the autosuspend in the future when the delay time expires again. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Henrik Rydberg <rydberg@euromail.se> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b2c0a863e14676fa5760c6d828fd373288e2f64a upstream.

Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed.  The idle callback routine could
then schedule a delayed suspend for some time later.

However this behavior was changed by commit
f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle
notification after failing suspend).  No notifications were sent, and
there was no clear mechanism to retry failed suspends.

This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down.  A companion
patch changes the PM core's behavior, but we also need to change the
USB core.  In particular, this patch (as1493) updates the device's
last_busy time when an autosuspend fails, so that the PM core will
retry the autosuspend in the future when the delay time expires
again.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Avoid NULL pointer deref in usb_hcd_alloc_bandwidth. 2011-11-11T17:36:37+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2011-08-09T23:31:54+00:00 f6fad686650aaf264b2acee848825e2183a944e3 commit 8a9af4fdf6d5eeb3200a088354d266a87e8260b0 upstream. usb_ifnum_to_if() can return NULL if the USB device does not have a configuration installed (usb_device->actconfig == NULL), or if we can't find the interface number in the installed configuration. Return an error instead of crashing. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8a9af4fdf6d5eeb3200a088354d266a87e8260b0 upstream.

usb_ifnum_to_if() can return NULL if the USB device does not have a
configuration installed (usb_device->actconfig == NULL), or if we can't
find the interface number in the installed configuration.  Return an
error instead of crashing.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add quirk for Logitech C300 web cam 2011-11-11T17:35:38+00:00 Jon Levell linuxusb@coralbark.net 2011-09-29T19:42:52+00:00 30dd5b9fd9ccc9cf661a72d54ef67511cdadbec1 commit 5b253d88cc6c65a23cefc457a5a4ef139913c5fc upstream. My webcam is a Logitech C300 and I get "chipmunk"ed squeaky sound. The following trivial patch fixes it. Signed-off-by: Jon Levell <linuxusb@coralbark.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 5b253d88cc6c65a23cefc457a5a4ef139913c5fc upstream.

My webcam is a Logitech C300 and I get "chipmunk"ed squeaky sound.
The following trivial patch fixes it.

Signed-off-by: Jon Levell <linuxusb@coralbark.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: add RESET_RESUME for webcams shown to be quirky 2011-11-11T17:35:37+00:00 Oliver Neukum oneukum@suse.de 2011-09-13T06:42:21+00:00 a8de96f08123ea80b04264e9faecfa34118ce4d8 commit 2394d67e446bf616a0885167d5f0d397bdacfdfc upstream. The new runtime PM code has shown that many webcams suffer from a race condition that may crash them upon resume. Runtime PM is especially prone to show the problem because it retains power to the cameras at all times. However system suspension may also crash the devices and retain power to the devices. The only way to solve this problem without races is in usbcore with the RESET_RESUME quirk. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 2394d67e446bf616a0885167d5f0d397bdacfdfc upstream.

The new runtime PM code has shown that many webcams suffer
from a race condition that may crash them upon resume.
Runtime PM is especially prone to show the problem because
it retains power to the cameras at all times. However
system suspension may also crash the devices and retain
power to the devices.
The only way to solve this problem without races is in
usbcore with the RESET_RESUME quirk.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: pid_ns: ensure pid is not freed during kill_pid_info_as_uid 2011-11-11T17:35:37+00:00 Serge Hallyn serge.hallyn@canonical.com 2011-09-26T15:18:29+00:00 62a5ac8b5fa6381fca135325166fb71b5e413be6 commit aec01c5895051849ed842dc5b8794017a7751f28 upstream. Alan Stern points out that after spin_unlock(&ps->lock) there is no guarantee that ps->pid won't be freed. Since kill_pid_info_as_uid() is called after the spin_unlock(), the pid passed to it must be pinned. Reported-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit aec01c5895051849ed842dc5b8794017a7751f28 upstream.

Alan Stern points out that after spin_unlock(&ps->lock) there is no
guarantee that ps->pid won't be freed.  Since kill_pid_info_as_uid() is
called after the spin_unlock(), the pid passed to it must be pinned.

Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb/core/devio.c: Check for printer class specific request 2011-11-11T17:35:36+00:00 Matthias Dellweg 2500@gmx.de 2011-09-25T12:26:25+00:00 1faec480bbcf3917205feef90ae1e1b38edceaf6 commit 393cbb5151ecda9f9e14e3082d048dd27a1ff9f6 upstream. In the usb printer class specific request get_device_id the value of wIndex is (interface << 8 | altsetting) instead of just interface. This enables the detection of some printers with libusb. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Matthias Dellweg <2500@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 393cbb5151ecda9f9e14e3082d048dd27a1ff9f6 upstream.

In the usb printer class specific request get_device_id the value of
wIndex is (interface << 8 | altsetting) instead of just interface.
This enables the detection of some printers with libusb.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthias Dellweg <2500@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: for usb_autopm_get_interface_async -EINPROGRESS is not an error 2011-11-11T17:35:13+00:00 Jim Wylder jwylder1@motorola.com 2011-09-07T02:07:20+00:00 e46389fa0026dd3bbaebf92a525dad3e80b7bce2 commit c5a48592d874ddef8c7880311581eccf0eb30c3b upstream. A return value of -EINPROGRESS from pm_runtime_get indicates that the device is already resuming due to a previous call. Internally, usb_autopm_get_interface_async doesn't treat this as an error and increments the usage count, but passes the error status along to the caller. The logical assumption of the caller is that any negative return value reflects the device not resuming and the pm_usage_cnt not being incremented. Since the usage count is being incremented and the device is resuming, return success (0) instead. Signed-off-by: James Wylder <james.wylder@motorola.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit c5a48592d874ddef8c7880311581eccf0eb30c3b upstream.

A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call.  Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller.  The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented.  Since the usage count
is being incremented and the device is resuming, return success (0)
instead.

Signed-off-by: James Wylder <james.wylder@motorola.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb/config: use proper endian access for wMaxPacketSize 2011-08-17T17:55:51+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2011-07-29T09:05:45+00:00 024d78c79eb4ee5395ed8f13233b5b15e3445db3 commit 7de7c7d2cb49900e0b967be871bf695c7d6135c9 upstream. wMaxPacketSize is __le16 and should be accessed as such. Also fix the wBytesPerInterval assignment while here. v2: also fix the wBytesPerInterval assigment, noticed by Matt Evans This patch should be backported to the 3.0 kernel. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 7de7c7d2cb49900e0b967be871bf695c7d6135c9 upstream.

wMaxPacketSize is __le16 and should be accessed as such. Also fix the
wBytesPerInterval assignment while here.

v2: also fix the wBytesPerInterval assigment, noticed by Matt Evans

This patch should be backported to the 3.0 kernel.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: additional regression fix for device removal 2011-07-07T20:29:33+00:00 Alan Stern stern@rowland.harvard.edu 2011-07-06T21:03:45+00:00 ca5c485f55d326d9a23e4badd05890148aa53f74 Commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc (USB: fix regression occurring during device removal) didn't go far enough. It failed to take into account that when a driver claims multiple interfaces, it may release them all at the same time. As a result, some interfaces can get released before they are unregistered, and we deadlock trying to acquire the bandwidth_mutex that we already own. This patch (asl478) handles this case by setting the "unregistering" flag on all the interfaces before removing any of them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Tested-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc (USB: fix regression
occurring during device removal) didn't go far enough.  It failed to
take into account that when a driver claims multiple interfaces, it may
release them all at the same time.  As a result, some interfaces can
get released before they are unregistered, and we deadlock trying to
acquire the bandwidth_mutex that we already own.

This patch (asl478) handles this case by setting the "unregistering"
flag on all the interfaces before removing any of them.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Tested-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix regression occurring during device removal 2011-07-01T21:20:39+00:00 Alan Stern stern@rowland.harvard.edu 2011-07-01T20:43:02+00:00 e534c5b831c8b8e9f5edee5c8a37753c808b80dc This patch (as1476) fixes a regression introduced by fccf4e86200b8f5edd9a65da26f150e32ba79808 (USB: Free bandwidth when usb_disable_device is called). usb_disconnect() grabs the bandwidth_mutex before calling usb_disable_device(), which calls down indirectly to usb_set_interface(), which tries to acquire the bandwidth_mutex. The fix causes usb_set_interface() to return early when it is called for an interface that has already been unregistered, which is what happens in usb_disable_device(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch (as1476) fixes a regression introduced by
fccf4e86200b8f5edd9a65da26f150e32ba79808 (USB: Free bandwidth when
usb_disable_device is called).  usb_disconnect() grabs the
bandwidth_mutex before calling usb_disable_device(), which calls down
indirectly to usb_set_interface(), which tries to acquire the
bandwidth_mutex.

The fix causes usb_set_interface() to return early when it is called
for an interface that has already been unregistered, which is what
happens in usb_disable_device().

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>