commit de68bab4fa96014cfaa6fcbcdb9750e32969fb86 upstream. How it's supposed to work: -------------------------- USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices support. USB 3.0 devices certified by the USB-IF are required to support it if they are plugged into a USB 2.0 only port, or a USB 2.0 cable is used. USB 2.0 Link PM requires both a USB device and a host controller that supports USB 2.0 hardware-enabled LPM. USB 2.0 Link PM is designed to be enabled once by software, and the host hardware handles transitions to the L1 state automatically. The premise of USB 2.0 Link PM is to be able to put the device into a lower power link state when the bus is idle or the device NAKs USB IN transfers for a specified amount of time. ...but hardware is broken: -------------------------- It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by setting the LPM bit in their USB 2.0 BOS descriptor), but they don't actually implement it correctly. This manifests as the USB device refusing to respond to transfers when it is plugged into a USB 2.0 only port under the Haswell-ULT/Lynx Point LP xHCI host. These devices pass the xHCI driver's simple test to enable USB 2.0 Link PM, wait for the port to enter L1, and then bring it back into L0. They only start to break when L1 entry is interleaved with transfers. Some devices then fail to respond to the next control transfer (usually a Set Configuration). This results in devices never enumerating. Other mass storage devices (such as a later model Western Digital My Passport USB 3.0 hard drive) respond fine to going into L1 between control transfers. They ACK the entry, come out of L1 when the host needs to send a control transfer, and respond properly to those control transfers. However, when the first READ10 SCSI command is sent, the device NAKs the data phase while it's reading from the spinning disk. Eventually, the host requests to put the link into L1, and the device ACKs that request. Then it never responds to the data phase of the READ10 command. This results in not being able to read from the drive. Some mass storage devices (like the Corsair Survivor USB 3.0 flash drive) are well behaved. They ACK the entry into L1 during control transfers, and when SCSI commands start coming in, they NAK the requests to go into L1, because they need to be at full power. Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I suspect that means the device isn't certified. What do we do about it? ----------------------- There's really no good way for the kernel to test these devices. Therefore, the kernel needs to disable USB 2.0 Link PM by default, and distros will have to enable it by writing 1 to the sysfs file /sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link PM test, since it's not sufficient to detect these buggy devices, and don't automatically enable LPM after the device is addressed. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some host controllers(such as xHCI) can support building packet from discontinuous buffers, so introduce one flag and helper for this kind of host controllers, then the feature can help some applications(such as usbnet) by supporting arbitrary length of sg buffers. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bInterval must be within the range 1 - 16 when running at High/Super speed, and within the range 1 - 255 when running at Full/Low speed. In order to catch drivers passing a too large bInterval on Super/High speed scenarios (thus overflowing urb->interval), let's clamp() the argument to the allowed ranges. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB spec stats that short packet can only appear at the end of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't build a full packet from discontinuous buffers, we introduce the limit in usb_submit_urb() to avoid such kind of bad sg buffers coming from driver. The limit might be a bit strict: - platform has iommu to do sg list mapping - some host controllers may support to build full packet from discontinuous buffers. But considered that most of HCs don't support that, and driver need work well or keep consistent on different HCs and ARCHs, we have to introduce the limit. Currently, only usbtest is reported to pass such sg buffers to HC, and other users(mass storage, usbfs) don't have the problem. We don't check it on USB wireless device, because: - wireless devices can't be attached to common USB bus(EHCI/UHCI/OHCI/...) - the max packet size of endpoint may be odd, and often can't devide 4KB which is a typical usage in usb mass storage application Reported-by: Konstantin Filatov <kfilatov@parallels.com> Reported-by: Denis V. Lunev <den@openvz.org> Cc: Felipe Balbi <balbi@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB_MAXCHILDREN symbol is used in include/uapi/linux/usb/ch11.h, a user-mode header, even though it is defined in include/linux/usb.h, which is kernel-only. This causes compile-time errors when user programs try to #include linux/usb/ch11.h. This patch fixes the problem by moving the definition of USB_MAXCHILDREN into ch11.h. It also gets rid of unneeded parentheses. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep) and BESL (best effort service latency)via sysfs. This also adds a new usb2_lpm_parameters structure with those variables to struct usb_device. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
usb 2.0 devices with link power managment (LPM) can describe their idle link timeouts either in BESL or HIRD format, so far xHCI has only supported HIRD but later xHCI errata add BESL support as well BESL timeouts need to inform exit latency changes with an evaluate context command the same way USB 3.0 link PM code does. The same xhci_change_max_exit_latency() function is used as with USB3 but code is pulled out from #ifdef CONFIG_PM as USB2.0 BESL LPM funcionality does not depend on CONFIG_PM. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The current EHCI code sleeps a flat 110ms in the resume path if there was a USB 1.1 device connected to its companion controller during suspend, waiting for the device to reappear and reset so that it can be handed back to the companion. This is necessary if the device uses persist, so that the companion controller can actually see it during its own resume path. However, if the device doesn't use persist, this is entirely unnecessary. We might just as well ignore it and have the normal device detection/reset/handoff code handle it asynchronously when it eventually shows up. As USB 1.1 devices are almost exclusively HIDs these days (for which persist has no value), this can allow distros to shave another tenth of a second off their resume time. In order to enable this optimization, the patch also adds a new usb_for_each_dev() iterator that is exported by the USB core and wraps bus_for_each_dev() with the logic to differentiate between struct usb_device and struct usb_interface on the usb_bus_type bus. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>