kernel/linux.git/drivers/usb/host, branch v3.15.2

xhci: delete endpoints from bandwidth list before freeing whole device

2014-05-28T21:53:53+00:00

Lists of endpoints are stored for bandwidth calculation for roothub ports. Make sure we remove all endpoints from the list before the whole device, containing its endpoints list_head stuctures, is freed. This used to be done in the wrong order in xhci_mem_cleanup(), and triggered an oops in resume from S4 (hibernate). Cc: stable Tested-by: Ville Syrjälä Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: pci-quirks: Prevent Sony VAIO t-series from switching usb ports

2014-05-28T20:17:46+00:00

Sony VAIO t-series machines are not capable of switching usb2 ports over from Intel EHCI to xHCI controller. If tried the USB2 port will be left unconnected and unusable. This patch should be backported to stable kernels as old as 3.12, that contain the commit 26b76798e0507429506b93cd49f8c4cfdab06896 "Intel xhci: refactor EHCI/xHCI port switching" Cc: stable # 3.12 Reported-by: Jorge Tested-by: Jorge Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

fsl-usb: do not test for PHY_CLK_VALID bit on controller version 1.6

2014-05-03T22:04:28+00:00

Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller present in these SoCs has bit 17 of USBx_CONTROL register marked as Reserved - there is no PHY_CLK_VALID bit there. Testing for this bit in ehci_fsl_setup_phy() behaves differently on two P1020RDB boards available here - on one board test passes and fsl-usb init succeeds, but on other board test fails, causing fsl-usb init to fail. This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on controller version 1.6 that (per manual) does not have this bit. Signed-off-by: Nikita Yushchenko Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: OHCI: fix problem with global suspend on ATI controllers

2014-05-03T21:58:46+00:00

Some OHCI controllers from ATI/AMD seem to have difficulty with "global" USB suspend, that is, suspending an entire USB bus without setting the suspend feature for each port connected to a device. When we try to resume the child devices, the controller gives timeout errors on the unsuspended ports, requiring resets, and can even cause ohci-hcd to hang; see http://marc.info/?l=linux-usb&m=139514332820398&w=2 and the following messages. This patch fixes the problem by adding a new quirk flag to ohci-hcd. The flag causes the ohci_rh_suspend() routine to suspend each unsuspended, enabled port before suspending the root hub. This effectively converts the "global" suspend to an ordinary root-hub suspend. There is no need to unsuspend these ports when the root hub is resumed, because the child devices will be resumed anyway in the course of a normal system resume ("global" suspend is never used for runtime PM). This patch should be applied to all stable kernels which include commit 0aa2832dd0d9 (USB: use "global suspend" for system sleep on USB-2 buses) or a backported version thereof. Signed-off-by: Alan Stern Reported-by: Peter Münster Tested-by: Peter Münster CC: Signed-off-by: Greg Kroah-Hartman

usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

2014-04-25T16:34:10+00:00

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by: David Cohen Cc: stable@vger.kernel.org # 3.2 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: extend quirk for Renesas cards

2014-04-25T16:34:10+00:00

After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor: Renesas Technology Corp. [1912] SDevice: uPD720202 USB 3.0 Host Controller [0015] Rev: 02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by: Anatoly Kharchenko Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko Cc: stable@vger.kernel.org # 3.14 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

2014-04-25T16:34:10+00:00

The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. This patch should be backported to stable kernels as old as 3.12, that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell" Signed-off-by: Denis Turischev Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-04-25T16:34:10+00:00

We have observed a rare cycle state desync bug after Set TR Dequeue Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that doesn't fetch new TRBs and thus an unresponsive USB device). It always triggers when a previous Set TR Dequeue Pointer command has set the pointer to the final Link TRB of a segment, and then another URB gets enqueued and cancelled again before it can be completed. Further investigation showed that the xHC had returned the Link TRB in the TRB Pointer field of the Transfer Event (CC == Stopped -- Length Invalid), but when xhci_find_new_dequeue_state() later accesses the Endpoint Context's TR Dequeue Pointer field it is set to the first TRB of the next segment. The driver expects those two values to be the same in this situation, and uses the cycle state of the latter together with the address of the former. This should be fine according to the XHCI specification, since the endpoint ring should be stopped when returning the Transfer Event and thus should not advance over the Link TRB before it gets restarted. However, real-world XHCI implementations apparently don't really care that much about these details, so the driver should follow a more defensive approach to try to work around HC spec violations. This patch removes the stopped_trb variable that had been used to store the TRB Pointer from the last Transfer Event of a stopped TRB. Instead, xhci_find_new_dequeue_state() now relies only on the Endpoint Context, requiring a small amount of additional processing to find the virtual address corresponding to the TR Dequeue Pointer. Some other parts of the function were slightly rearranged to better fit into this model. This patch should be backported to kernels as old as 2.6.31 that contain the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB cancellation support." Signed-off-by: Julius Werner Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: ohci-jz4740: FEAT_POWER is a port feature, not a hub feature

2014-04-16T20:59:41+00:00

Power control of hub ports target the CLEAR_FEATURE and SET_FEATURE requests to ports, not to the hub. Fix the hub control function to detect the request correctly. Signed-off-by: Laurent Pinchart Acked-by: Lars-Peter Clausen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: ohci-jz4740: Fix uninitialized variable warning

2014-04-16T20:59:40+00:00

The ret variable is not initialized in all code paths of the ohci_jz4740_hub_control function. Fix it. Signed-off-by: Laurent Pinchart Acked-by: Lars-Peter Clausen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman