lwn.git/drivers/usb/core, branch v2.6.32.59

USB: add quirk for another camera

2012-01-12T19:40:08+00:00

commit 35284b3d2f68a8a3703745e629999469f78386b5 upstream. The Guillemot Webcam Hercules Dualpix Exchange camera has been reported with a second ID. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: quirks: adding more quirky webcams to avoid squeaky audio

2011-11-26T17:10:38+00:00

commit 0d145d7d4a241c321c832a810bb6edad18e2217b upstream. The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e446bf616a0885167d5f0d397bdacfdfc and 5b253d88cc6c65a23cefc457a5a4ef139913c5fc Signed-off-by: sordna Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman

USB: add quirk for Logitech C600 web cam

2011-11-26T17:10:37+00:00

commit 60c71ca972a2dd3fd9d0165b405361c8ad48349b upstream. We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue. Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman

USB: add RESET_RESUME for webcams shown to be quirky

2011-11-07T20:32:21+00:00

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 Signed-off-by: Greg Kroah-Hartman

USB: pid_ns: ensure pid is not freed during kill_pid_info_as_uid

2011-11-07T20:32:20+00:00

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 Signed-off-by: Serge Hallyn Signed-off-by: Greg Kroah-Hartman

USB: don't let the hub driver prevent system sleep

2011-07-13T03:29:25+00:00

commit cbb330045e5df8f665ac60227ff898421fc8fb92 upstream. This patch (as1465) continues implementation of the policy that errors during suspend or hibernation should not prevent the system from going to sleep. In this case, failure to turn on the Suspend feature for a hub port shouldn't be reported as an error. There are situations where this does actually occur (such as when the device plugged into that port was disconnected in the recent past), and it turns out to be harmless. There's no reason for it to prevent a system sleep. Also, don't allow the hub driver to fail a system suspend if the downstream ports aren't all suspended. This is also harmless (and should never happen, given the change mentioned above); printing a warning message in the kernel log is all we really need to do. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: don't let errors prevent system sleep

2011-07-13T03:29:25+00:00

commit 0af212ba8f123c2eba151af7726c34a50b127962 upstream. This patch (as1464) implements the recommended policy that most errors during suspend or hibernation should not prevent the system from going to sleep. In particular, failure to suspend a USB driver or a USB device should not prevent the sleep from succeeding: Failure to suspend a device won't matter, because the device will automatically go into suspend mode when the USB bus stops carrying packets. (This might be less true for USB-3.0 devices, but let's not worry about them now.) Failure of a driver to suspend might lead to trouble later on when the system wakes up, but it isn't sufficient reason to prevent the system from going to sleep. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: core: Tolerate protocol stall during hub and port status read

2011-06-23T22:24:07+00:00

commit 3824c1ddaf744be44b170a335332b9d6afe79254 upstream. Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: teach "devices" file about Wireless and SuperSpeed USB

2011-05-09T22:55:10+00:00

commit 834e2312e7a384877a876b0d34dffc3046c96bcb upstream. USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by: Alan Stern CC: David Vrabel CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman [Julien Blache: The original commit also added the correct speed for USB_SPEED_WIRELESS, I removed it as it's not supported in 2.6.32.] Signed-off-by: Greg Kroah-Hartman

USB: don't enable remote wakeup by default

2011-05-09T22:55:10+00:00

commit 7aba8d014341341590ecb64050b7a026642a62eb upstream. This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman