kernel/linux.git/drivers/usb/core, branch linux-2.6.35.y

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

2011-08-01T20:54:58+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 Signed-off-by: Andi Kleen

USB: don't let errors prevent system sleep

2011-08-01T20:54:58+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 Signed-off-by: Andi Kleen

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

2011-08-01T20:54:55+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 Signed-off-by: Andi Kleen

OHCI: work around for nVidia shutdown problem

2011-08-01T20:54:53+00:00

[ upstream commit 5f528de0ef9b3e092e276d95930830b847b33dc4 ] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b upstream. This patch (as1417) fixes a problem affecting some (or all) nVidia chipsets. When the computer is shut down, the OHCI controllers continue to power the USB buses and evidently they drive a Reset signal out all their ports. This prevents attached devices from going to low power. Mouse LEDs stay on, for example, which is disconcerting for users and a drain on laptop batteries. The fix involves leaving each OHCI controller in the OPERATIONAL state during system shutdown rather than putting it in the RESET state. Although this nominally means the controller is running, in fact it's not doing very much since all the schedules are all disabled. However there is ongoing DMA to the Host Controller Communications Area, so the patch also disables the bus-master capability of all PCI USB controllers after the shutdown routine runs. The fix is applied only to nVidia-based PCI OHCI controllers, so it shouldn't cause problems on systems using other hardware. As an added safety measure, in case the kernel encounters one of these running controllers during boot, the patch changes quirk_usb_handoff_ohci() (which runs early on during PCI discovery) to reset the controller before anything bad can happen. Reported-by: Pali Rohár Signed-off-by: Alan Stern Signed-off-by: Andi Kleen CC: David Brownell Tested-by: Pali Rohár Signed-off-by: Greg Kroah-Hartman

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

2011-08-01T20:54:44+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 Signed-off-by: Andi Kleen 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: Fix unplug of device with active streams

2011-04-28T15:21:15+00:00

upstream commit: b214f191d95ba4b5a35aebd69cd129cf7e3b1884 If I unplug a device while the UAS driver is loaded, I get an oops in usb_free_streams(). This is because usb_unbind_interface() calls usb_disable_interface() which calls usb_disable_endpoint() which sets ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint() which returns a NULL pointer and passes an array of NULL pointers to usb_free_streams(). I think the correct fix for this is to check for the NULL pointer in usb_free_streams() rather than making the driver check for this situation. My original patch for this checked for dev->state == USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is conditional, so not all drivers would want this check. Note from Sarah Sharp: This patch does avoid a potential dereference, but the real fix (which will be implemented later) is to set the .soft_unbind flag in the usb_driver structure for the UAS driver, and all drivers that allocate streams. The driver should free any streams when it is unbound from the interface. This avoids leaking stream rings in the xHCI driver when usb_disable_interface() is called. This should be queued for stable trees back to 2.6.35. Signed-off-by: Matthew Wilcox Signed-off-by: Sarah Sharp Signed-off-by: Andi Kleen Cc: stable@kernel.org

USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices

2011-04-28T15:21:08+00:00

commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

USB: Add quirk for Samsung Android phone modem

2011-03-31T18:58:11+00:00

commit 72a012ce0a02c6c616676a24b40ff81d1aaeafda upstream. My Galaxy Spica needs this quirk when in modem mode, otherwise it causes endless USB bus resets and is unusable in this mode. Unfortunately Samsung decided to reuse ID of its old CDMA phone SGH-I500 for the modem part. That's why in addition to this patch the visor driver must be prevented from binding to SPH-I500 ID, so ACM driver can do that. Signed-off-by: Maciej Szmigiero Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

USB: add quirks entry for Keytouch QWERTY Panel

2011-03-31T18:58:10+00:00

commit 3c18e30f87ac5466bddbb05cf955605efd7db025 upstream. This patch (as1448) adds a quirks entry for the Keytouch QWERTY Panel firmware, used in the IEC 60945 keyboard. This device crashes during enumeration when the computer asks for its configuration string descriptor. Signed-off-by: Alan Stern Tested-by: kholis Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

usb: Realloc xHCI structures after a hub is verified.

2011-03-31T18:57:57+00:00

commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen