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

xhci: Fix runtime suspended xhci from blocking system suspend.

2014-07-09T17:51:19+00:00

commit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream. The system suspend flow as following: 1, Freeze all user processes and kenrel threads. 2, Try to suspend all devices. 2.1, If pci device is in RPM suspended state, then pci driver will try to resume it to RPM active state in the prepare stage. 2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two workqueue items to resume usb2&usb3 roothub devices. 2.3, Call suspend callbacks of devices. 2.3.1, All suspend callbacks of all hcd's children, including roothub devices are called. 2.3.2, Finally, hcd_pci_suspend callback is called. Due to workqueue threads were already frozen in step 1, the workqueue items can't be scheduled, and the roothub devices can't be resumed in this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in usb_hcd_resume_root_hub won't be cleared. Finally, hcd_pci_suspend will return -EBUSY, and system suspend fails. The reason why this issue doesn't show up very often is due to that choose_wakeup will be called in step 2.3.1. In step 2.3.1, if udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then udev will resume to RPM active for changing the wakeup settings. This has been a lucky hit which hides this issue. For some special xHCI controllers which have no USB2 port, then roothub will not match hub driver due to probe failed. Then its do_remote_wakeup will be set to zero, and we won't be as lucky. xhci driver doesn't need to resume roothub devices everytime like in the above case. It's only needed when there are pending event TRBs. This patch should be back-ported to kernels as old as 3.2, that contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb "USB: XHCI: resume root hubs when the controller resumes" Signed-off-by: Wang, Yu Acked-by: Alan Stern [use readl() instead of removed xhci_readl(), reword commit message -Mathias] Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: correct burst count field for isoc transfers on 1.0 xhci hosts

2014-07-09T17:51:19+00:00

commit 3213b151387df0b95f4eada104f68eb1c1409cb3 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e33b9519143f06f507dd7cbee6b7a621885 "xhci 1.0: Set transfer burst count field." Suggested-by: ShiChun Ma Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

USB: EHCI: avoid BIOS handover on the HASEE E200

2014-07-01T03:01:30+00:00

commit b0a50e92bda3c4aeb8017d4e6c6e92146ebd5c9b upstream. Leandro Liptak reports that his HASEE E200 computer hangs when we ask the BIOS to hand over control of the EHCI host controller. This definitely sounds like a bug in the BIOS, but at the moment there is no way to fix it. This patch works around the problem by avoiding the handoff whenever the motherboard and BIOS version match those of Leandro's computer. Signed-off-by: Alan Stern Reported-by: Leandro Liptak Tested-by: Leandro Liptak Signed-off-by: Greg Kroah-Hartman

xhci: delete endpoints from bandwidth list before freeing whole device

2014-06-11T19:04:12+00:00

commit 5dc2808c4729bf080487e61b80ee04e0fdb12a37 upstream. 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). Tested-by: Ville Syrjälä Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

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

2014-05-06T14:51:44+00:00

commit 01bb59ebffdec314da8da66266edf29529372f9b upstream. 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 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: extend quirk for Renesas cards

2014-05-06T14:51:44+00:00

commit 6db249ebefc6bf5c39f35dfaacc046d8ad3ffd70 upstream. 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 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Limit the spurious wakeup fix only to HP machines

2014-04-14T13:44:29+00:00

commit 6962d914f317b119e0db7189199b21ec77a4b3e0 upstream. We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive. Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice. This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell". Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 Signed-off-by: Takashi Iwai Signed-off-by: Sarah Sharp Tested-by: Reported-by: Niklas Schnelle Reported-by: Giorgos Reported-by: Signed-off-by: Ben Hutchings Cc: Yang Yingliang Signed-off-by: Greg Kroah-Hartman

xhci: Fix spurious wakeups after S5 on Haswell

2014-04-14T13:44:29+00:00

commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 upstream. Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum Signed-off-by: Takashi Iwai Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Yang Yingliang Signed-off-by: Greg Kroah-Hartman

xhci: quirk for extra long delay for S4

2014-04-14T13:44:29+00:00

commit 455f58925247e8a1a1941e159f3636ad6ee4c90b upstream. It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by: Oliver Neukum Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: - Adjust context - Use xhci_dbg() instead of xhci_dbg_trace()] Signed-off-by: Ben Hutchings [yangyl: Backported to 3.4: Adjust context] Signed-off-by: Yang Yingliang Signed-off-by: Greg Kroah-Hartman

xhci: Don't enable/disable RWE on bus suspend/resume.

2014-04-14T13:44:28+00:00

commit f217c980ca980e3a645b7485ea5eae9a747f4945 upstream. The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable remote wakeup for devices in the lower power link state L1. It has nothing to do with the device suspend remote wakeup from L2. The RWE bit is designed to be set once (when USB 2.0 LPM is enabled for the port) and cleared only when USB 2.0 LPM is disabled for the port. The xHCI bus suspend method was setting the RWE bit erroneously, and the bus resume method was clearing it. The xHCI 1.0 specification with errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware Controlled LPM": "While Hardware USB2 LPM is enabled, software shall not modify the HIRDBESL or RWE fields of the USB2 PORTPMSC register..." If we have previously enabled USB 2.0 LPM for a device, that means when the USB 2.0 bus is resumed, we violate the xHCI specification by clearing RWE. It also means that after a bus resume, the host would think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM enabled, which is not what we want. 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 kernel that supported USB 2.0 Link PM. Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: deleted code was cosmetically different] Signed-off-by: Ben Hutchings Cc: Yang Yingliang Signed-off-by: Greg Kroah-Hartman