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

usb: xhci: Fix for Enabling USB ROLE SWITCH QUIRK on INTEL_SUNRISEPOINT_LP_XHCI

2019-03-10T06:10:15+00:00

commit 8fde481ef3674ae5ad0dbfef4df18ff507c5675a upstream. This fix enables USB role feature on intel commercial nuc platform which is based on Kabylake chipset. Signed-off-by: Balaji Manoharan Reviewed-by: Hans de Goede Reviewed-by: Heikki Krogerus Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

xhci: tegra: Prevent error pointer dereference

2019-03-10T06:10:15+00:00

commit 0326ccb5feac6eac35ba6254260e2774277cd976 upstream. During initialization, the host and super-speed power domains will contain an ERR_PTR() encoded error code rather than being NULL. To avoid a crash, use a !IS_ERR_OR_NULL() condition during cleanup. Signed-off-by: Thierry Reding Fixes: 6494a9ad86de ("usb: xhci: tegra: Add genpd support") Cc: stable Reviewed-by: Jon Hunter Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: EHCI: ehci-mv: add MODULE_DEVICE_TABLE

2019-01-31T07:15:35+00:00

commit 70d0ba4cf79a0e73485b22d955991c6f27257376 upstream. This fixes autoloading the module by the OF compatible string. Fixes: 813e18b18a87 ("USB: EHCI: ehci-mv: add DT support") Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel Signed-off-by: Greg Kroah-Hartman

usb: r8a66597: Fix a possible concurrency use-after-free bug in r8a66597_endpoint_disable()

2019-01-09T16:45:53+00:00

commit c85400f886e3d41e69966470879f635a2b50084c upstream. The function r8a66597_endpoint_disable() and r8a66597_urb_enqueue() may be concurrently executed. The two functions both access a possible shared variable "hep->hcpriv". This shared variable is freed by r8a66597_endpoint_disable() via the call path: r8a66597_endpoint_disable kfree(hep->hcpriv) (line 1995 in Linux-4.19) This variable is read by r8a66597_urb_enqueue() via the call path: r8a66597_urb_enqueue spin_lock_irqsave(&r8a66597->lock) init_pipe_info enable_r8a66597_pipe pipe = hep->hcpriv (line 802 in Linux-4.19) The read operation is protected by a spinlock, but the free operation is not protected by this spinlock, thus a concurrency use-after-free bug may occur. To fix this bug, the spin-lock and spin-unlock function calls in r8a66597_endpoint_disable() are moved to protect the free operation. Signed-off-by: Jia-Ju Bai Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: xhci: fix 'broken_suspend' placement in struct xchi_hcd

2018-12-17T15:01:02+00:00

As commented in the struct's definition there shouldn't be anything underneath its 'priv[0]' member as it would break some macros. The patch converts the broken_suspend into a bit-field and relocates it next to to the rest of bit-fields. Fixes: a7d57abcc8a5 ("xhci: workaround CSS timeout on AMD SNPS 3.0 xHC") Reported-by: Oliver Neukum Signed-off-by: Nicolas Saenz Julienne Acked-by: Mathias Nyman Cc: stable Signed-off-by: Greg Kroah-Hartman

xhci: Don't prevent USB2 bus suspend in state check intended for USB3 only

2018-12-14T12:02:55+00:00

The code to prevent a bus suspend if a USB3 port was still in link training also reacted to USB2 port polling state. This caused bus suspend to busyloop in some cases. USB2 polling state is different from USB3, and should not prevent bus suspend. Limit the USB3 link training state check to USB3 root hub ports only. The origial commit went to stable so this need to be applied there as well Fixes: 2f31a67f01a8 ("usb: xhci: Prevent bus suspend if a port connect change or polling state is detected") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Prevent U1/U2 link pm states if exit latency is too long

2018-12-06T12:00:10+00:00

Don't allow USB3 U1 or U2 if the latency to wake up from the U-state reaches the service interval for a periodic endpoint. This is according to xhci 1.1 specification section 4.23.5.2 extra note: "Software shall ensure that a device is prevented from entering a U-state where its worst case exit latency approaches the ESIT." Allowing too long exit latencies for periodic endpoint confuses xHC internal scheduling, and new devices may fail to enumerate with a "Not enough bandwidth for new device state" error from the host. Cc: Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: workaround CSS timeout on AMD SNPS 3.0 xHC

2018-12-06T12:00:10+00:00

Occasionally AMD SNPS 3.0 xHC does not respond to CSS when set, also it does not flag anything on SRE and HCE to point the internal xHC errors on USBSTS register. This stalls the entire system wide suspend and there is no point in stalling just because of xHC CSS is not responding. To work around this problem, if the xHC does not flag anything on SRE and HCE, we can skip the CSS timeout and allow the system to continue the suspend. Once the system resume happens we can internally reset the controller using XHCI_RESET_ON_RESUME quirk Signed-off-by: Shyam Sundar S K Signed-off-by: Sandeep Singh cc: Nehal Shah Cc: Tested-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: check usb_get_extra_descriptor for proper size

2018-12-05T20:20:14+00:00

When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng Reported-by: Mathias Payer Co-developed-by: Linus Torvalds Signed-off-by: Hui Peng Signed-off-by: Mathias Payer Signed-off-by: Linus Torvalds Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: xhci: Prevent bus suspend if a port connect change or polling state is detected

2018-11-15T17:17:40+00:00

USB3 roothub might autosuspend before a plugged USB3 device is detected, causing USB3 device enumeration failure. USB3 devices don't show up as connected and enabled until USB3 link trainig completes. On a fast booting platform with a slow USB3 link training the link might reach the connected enabled state just as the bus is suspending. If this device is discovered first time by the xhci_bus_suspend() routine it will be put to U3 suspended state like the other ports which failed to suspend earlier. The hub thread will notice the connect change and resume the bus, moving the port back to U0 This U0 -> U3 -> U0 transition right after being connected seems to be too much for some devices, causing them to first go to SS.Inactive state, and finally end up stuck in a polling state with reset asserted Fix this by failing the bus suspend if a port has a connect change or is in a polling state in xhci_bus_suspend(). Don't do any port changes until all ports are checked, buffer all port changes and only write them in the end if suspend can proceed Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman