kernel/git/stable/linux.git/drivers/usb/host, branch linux-4.10.y

usb: host: xhci: print correct command ring address

2017-05-20T12:30:55+00:00

commit 6fc091fb0459ade939a795bfdcaf645385b951d4 upstream. Print correct command ring address using 'val_64'. Signed-off-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: bInterval quirk for TI TUSB73x0

2017-05-20T12:30:55+00:00

commit 69307ccb9ad7ccb653e332de68effdeaaab6907d upstream. As per [1] issue #4, "The periodic EP scheduler always tries to schedule the EPs that have large intervals (interval equal to or greater than 128 microframes) into different microframes. So it maintains an internal counter and increments for each large interval EP added. When the counter is greater than 128, the scheduler rejects the new EP. So when the hub re-enumerated 128 times, it triggers this condition." This results in Bandwidth error when devices with periodic endpoints (ISO/INT) having bInterval > 7 are plugged and unplugged several times on a TUSB73x0 XHCI host. Workaround this issue by limiting the bInterval to 7 (i.e. interval to 6) for High-speed or faster periodic endpoints. [1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths

2017-05-14T12:08:25+00:00

commit 68bd6fc3cfa98ef253e17307ccafd8ef907b5556 upstream. Returning from for_each_available_child_of_node() loop requires cleaning up node refcount. Error paths lacked it so for example in case of deferred probe, the refcount of phy node was left increased. Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs") Signed-off-by: Krzysztof Kozlowski Acked-by: Alan Stern Reviewed-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman

usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths

2017-05-14T12:08:25+00:00

commit 3f6026b1dcb3c8ee71198c485a72ac674c6890dd upstream. Returning from for_each_available_child_of_node() loop requires cleaning up node refcount. Error paths lacked it so for example in case of deferred probe, the refcount of phy node was left increased. Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs") Signed-off-by: Krzysztof Kozlowski Acked-by: Alan Stern Reviewed-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: enable BROKEN_PED quirk if platform requested

2017-04-12T10:42:10+00:00

[ Upstream commit 21939f003ad09355d9c975735750bb22aa37d8de ] In case 'quirk-broken-port-ped' property is passed in via device property, we should enable the corresponding BROKEN_PED quirk flag for XHCI core. [rogerq@ti.com] Updated code from platform data to device property and added DT binding. Signed-off-by: Felipe Balbi Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: xhci: add quirk flag for broken PED bits

2017-04-12T10:42:10+00:00

[ Upstream commit 41135de1e7fd14c6fcb9158404ba5c8fb97bf259 ] Some devices from Texas Instruments [1] suffer from a silicon bug where Port Enabled/Disabled bit should not be used to silence an erroneous device. The bug is so that if port is disabled with PED bit, an IRQ for device removal (or attachment) will never fire. Just for the sake of completeness, the actual problem lies with SNPS USB IP and this affects all known versions up to 3.00a. A separate patch will be added to dwc3 to enabled this quirk flag if version is <= 3.00a. [1] - AM572x Silicon Errata http://www.ti.com/lit/er/sprz429j/sprz429j.pdf Section i896— USB xHCI Port Disable Feature Does Not Work Signed-off-by: Felipe Balbi Signed-off-by: Roger Quadros Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: Set URB actual length for stopped control transfers

2017-04-08T07:35:08+00:00

commit 0ab2881a406b9fd46224a3e8253bbc0141b4f844 upstream. A control transfer that stopped at the status stage incorrectly warned about a "unexpected TRB Type 4", and did not set the transferred actual_length for the URB. The URB actual_length for control transfers should contain the bytes transferred in the data stage. Bytes of a partially sent setup stage and missing bytes from status stage should be left out. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

2017-03-18T11:18:41+00:00

commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 upstream. Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot pluggable xhci controllers using the xhci-plat driver, such as the driver used for Type-C ports on rk3399. Similar to hot-pluggable PCI controllers, the driver for this chip removes the xhci controller from the system when the Type-C cable is disconnected. The solution for PCI devices works just as well for non-PCI devices and avoids the problem. Signed-off-by: Guenter Roeck Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-dbg: HCIVERSION should be a binary number

2017-03-18T11:18:41+00:00

commit f95e60a7dbecd2de816bb3ad517b3d4fbc20b507 upstream. According to xHCI spec, HCIVERSION containing a BCD encoding of the xHCI specification revision number, 0100h corresponds to xHCI version 1.0. Change "100" as "0x100". Cc: Lu Baolu Fixes: 04abb6de2825 ("xhci: Read and parse new xhci 1.1 capability register") Signed-off-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: ohci-at91: Do not drop unhandled USB suspend control requests

2017-03-18T11:18:41+00:00

commit 85550f9148a852ed363a386577ad31b97b95dfb8 upstream. In patch 2e2aa1bc7eff90ecm, USB suspend and wakeup control requests are passed to SFR_OHCIICR register. If a processor does not have such a register, this hub control request will be dropped. If no such a SFR register is available, all USB suspend control requests will now be processed using ohci_hub_control() (like before patch 2e2aa1bc7eff90ecm.) Tested on an Atmel AT91SAM9G20 with an on-board TI TUSB2046B hub chip If the last USB device is unplugged from the USB hub, the hub goes into sleep and will not wakeup when an USB devices is inserted. Fixes: 2e2aa1bc7eff90ec ("usb: ohci-at91: Forcibly suspend ports while USB suspend") Signed-off-by: Jelle Martijn Kok Tested-by: Wenyou Yang Cc: Wenyou Yang Cc: Alan Stern Acked-by: Nicolas Ferre Reviewed-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman