linux/drivers/usb/core, branch v3.12.10

usb: core: get config and string descriptors for unauthorized devices

2014-02-06T19:22:21Z

commit 83e83ecb79a8225e79bc8e54e9aff3e0e27658a2 upstream. There is no need to skip querying the config and string descriptors for unauthorized WUSB devices when usb_new_device is called. It is allowed by WUSB spec. The only action that needs to be delayed until authorization time is the set config. This change allows user mode tools to see the config and string descriptors earlier in enumeration which is needed for some WUSB devices to function properly on Android systems. It also reduces the amount of divergent code paths needed for WUSB devices. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman

USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED

2014-02-06T19:22:15Z

commit 543d7784b07ffd16cc82a9cb4e1e0323fd0040f1 upstream. There is a race in the hub driver between hub_disconnect() and recursively_mark_NOTATTACHED(). This race can be triggered if the driver is unbound from a device at the same time as the bus's root hub is removed. When the race occurs, it can cause an oops: BUG: unable to handle kernel NULL pointer dereference at 0000015c IP: [] recursively_mark_NOTATTACHED+0x20/0x60 Call Trace: [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] recursively_mark_NOTATTACHED+0x34/0x60 [] usb_set_device_state+0x92/0x120 [] usb_disconnect+0x2b/0x1a0 [] usb_remove_hcd+0xb0/0x160 [] ? _raw_spin_unlock_irqrestore+0x26/0x50 [] ehci_mid_remove+0x1c/0x30 [] ehci_mid_stop_host+0x16/0x30 [] penwell_otg_work+0xd28/0x3520 [] ? __schedule+0x39b/0x7f0 [] ? sub_preempt_count+0x3d/0x50 [] process_one_work+0x11d/0x3d0 [] ? mutex_unlock+0xd/0x10 [] ? manage_workers.isra.24+0x1b5/0x270 [] worker_thread+0xf9/0x320 [] ? _raw_spin_unlock_irqrestore+0x26/0x50 [] ? rescuer_thread+0x2b0/0x2b0 [] kthread+0x94/0xa0 [] ret_from_kernel_thread+0x1b/0x28 [] ? kthread_create_on_node+0xc0/0xc0 One problem is that recursively_mark_NOTATTACHED() uses the intfdata value and hub->hdev->maxchild while hub_disconnect() is clearing them. Another problem is that it uses hub->ports[i] while the port device is being released. To fix this race, we need to hold the device_state_lock while hub_disconnect() changes the values. (Note that usb_disconnect() and hub_port_connect_change() already acquire this lock at similar critical times during a USB device's life cycle.) We also need to remove the port devices after maxchild has been set to 0, instead of before. Signed-off-by: Alan Stern Reported-by: "Du, Changbin" Tested-by: "Du, Changbin" Signed-off-by: Greg Kroah-Hartman

usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED

2013-12-20T15:48:54Z

commit 2d51f3cd11f414c56a87dc018196b85fd50b04a4 upstream. This patch adds a check for USB_STATE_NOTATTACHED to the hub_port_warm_reset_required() workaround for ports that end up in Compliance Mode in hub_events() when trying to decide which reset function to use. Trying to call usb_reset_device() with a NOTATTACHED device will just fail and leave the port broken. Signed-off-by: Julius Werner Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: hub: Clear Port Reset Change during init/resume

2013-11-29T19:28:10Z

commit e92aee330837e4911553761490a8fb843f2053a6 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by: Julius Werner Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: Disable USB 2.0 Link PM before device reset.

2013-11-29T19:28:10Z

commit dcc01c0864823f91c3bf3ffca6613e2351702b87 upstream. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xhci: Enable LPM support only for hardwired or BESL devices

2013-11-29T19:28:10Z

commit 890dae88672175f1d39f6105444d9bdc71c89258 upstream. Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] 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: Mathias Nyman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

usb: Don't enable USB 2.0 Link PM by default.

2013-11-29T19:28:09Z

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

usbcore: set lpm_capable field for LPM capable root hubs

2013-11-20T20:37:37Z

commit 9df89d85b407690afa46ddfbccc80bec6869971d upstream. This patch sets the lpm_capable field for root hubs with LPM capabilities. Signed-off-by: Xenia Ragiadakou Reported-by: Martin MOKREJS Suggested-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: quirks: add touchscreen that is dazzeled by remote wakeup

2013-10-16T17:21:07Z

The device descriptors are messed up after remote wakeup Signed-off-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: quirks.c: add one device that cannot deal with suspension

2013-10-14T18:17:31Z

The device is not responsive when resumed, unless it is reset. Signed-off-by: Oliver Neukum CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman