linux/drivers/usb/host, branch v3.17

USB: EHCI: unlink QHs even after the controller has stopped

2014-09-19T21:59:17Z

Old code in ehci-hcd tries to expedite disabling endpoints after the controller has stopped, by destroying the endpoint's associated QH without first unlinking the QH. This was necessary back when the driver wasn't so careful about keeping track of the controller's state. But now we are careful about it, and the driver knows that when the controller isn't running, no unlinking delay is needed. Furthermore, skipping the unlink step will trigger a BUG() in qh_destroy() when the preceding QH is released, because the link pointer will be non-NULL. Removing the lines that skip the unlinking step and go directly to QH_STATE_IDLE fixes the problem. Signed-off-by: Alan Stern Reported-by: Joe Lawrence Tested-by: Joe Lawrence CC: Signed-off-by: Greg Kroah-Hartman

xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices

2014-09-11T21:23:52Z

Resuming from hibernate (S4) will restart and re-initialize xHC. The device contexts are freed and will be re-allocated later during device reset. Usb core will disable link pm in device resume before device reset, which will try to change the max exit latency, accessing the device contexts before they are re-allocated. There is no need to zero (disable) the max exit latency when disabling hw lpm for a freshly re-initialized xHC. So check that device context exists before doing anything. The max exit latency will be set again after device reset when usb core enables the link pm. Reported-by: Imre Deak Tested-by: Imre Deak Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix OOPS in xhci error handling code

2014-09-11T21:23:52Z

The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent() is out of memory. This is a result of two things: 1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if it's not NULL, but doesn't set it to NULL after the free. 2. xhci_mem_cleanup() is called twice on resume, once for normal restart and once from xhci_mem_init() if dma_alloc_coherent() fails, resulting in a free of xhci->lpm_command that has already been freed. The fix is to set xhci->lpm_command to NULL after freeing it. Signed-off-by: Al Cooper Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Fix null pointer dereference if xhci initialization fails

2014-09-11T21:23:52Z

If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by: Manuel Reimer Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: host: xhci: fix compliance mode workaround

2014-09-08T21:30:42Z

Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes Cc: # v3.2+ Signed-off-by: Felipe Balbi Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

Revert "usb: ehci/ohci-exynos: Fix PHY getting sequence"

2014-08-27T22:23:53Z

This reverts commit 039368901ad0a6476c7ecf0cfe4f84d735e30135. Vivek writes: We not longer need this patch, since we have planned to remove the usb-phy drivers for samsung [1], we have completely deleted the support for the the same from ohci-exynos and ehci-exynos drivers too [2]. Sorry for the confusion, but this patch can be dropped and instead we can pick the patches in [2]. [1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35774.html [2] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35695.html https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35696.html Cc: Sachin Kamat Cc: Vivek Gautam Cc: Alan Stern Cc: Jingoo Han Cc: Sachin Kamat Cc: Jingoo Han Signed-off-by: Greg Kroah-Hartman

xhci: Disable streams on Via XHCI with device-id 0x3432

2014-08-27T20:35:38Z

This is a bit bigger hammer then I would like to use for this, but for now it will have to make do. I'm working on getting my hands on one of these so that I can try to get streams to work (with a quirk flag if necessary) and then we can re-enable them. For now this at least makes uas capable disk enclosures work again by forcing fallback to the usb-storage driver. https://bugzilla.kernel.org/show_bug.cgi?id=79511 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Hans de Goede Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-26T22:59:14Z

Since we want to keep support for both older usb-phys as well as the newer generic phys, lets first get the generic PHYs and fallback to older USB-PHYs only when we fail to get the former. This should fix the issue with ehci-exynos and ohci-exynos, wherein in the absence of SAMSUNG_USB2PHY config symbol, we end up getting the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs are not configured properly. Reported-by: Sachin Kamat Signed-off-by: Vivek Gautam Cc: Alan Stern Cc: Jingoo Han Tested-by: Sachin Kamat Acked-by: Jingoo Han Signed-off-by: Greg Kroah-Hartman

usb: ehci: using wIndex + 1 for hub port

2014-08-25T20:11:27Z

The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes "can't find device at roohub" problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. This patch is for v3.12+. Cc: stable@vger.kernel.org Signed-off-by: Peter Chen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

xhci: rework cycle bit checking for new dequeue pointers

2014-08-19T16:27:36Z

When we manually need to move the TR dequeue pointer we need to set the correct cycle bit as well. Previously we used the trb pointer from the last event received as a base, but this was changed in commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer") to use the dequeue pointer from the endpoint context instead It turns out some Asmedia controllers advance the dequeue pointer stored in the endpoint context past the event triggering TRB, and this messed up the way the cycle bit was calculated. Instead of adding a quirk or complicating the already hard to follow cycle bit code, the whole cycle bit calculation is now simplified and adapted to handle event and endpoint context dequeue pointer differences. Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer") Reported-by: Maciej Puzio Reported-by: Evan Langlois Reviewed-by: Julius Werner Tested-by: Maciej Puzio Tested-by: Evan Langlois Signed-off-by: Mathias Nyman Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman