#
28cbed49 |
|
03-Mar-2024 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
xhci: Allow RPM on the USB controller (1022:43f7) by default Enable runtime PM by default for older AMD 1022:43f7 xHCI 1.1 host as it is proven to work. Driver enables runtime PM by default for newer xHCI 1.2 host. Link: https://lore.kernel.org/all/12335218.O9o76ZdvQC@natalenko.name/ Cc: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240304054327.2564500-1-Basavaraj.Natikar@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
74151b53 |
|
29-Feb-2024 |
Niklas Neronin <niklas.neronin@intel.com> |
xhci: save slot ID in struct 'xhci_port' Slot ID is a index of a virtual device in struct 'xhci_hcd->devs[]'. Previously, to get the slot ID associated with a port, we had to loop through all devices and compare ports, which is very inefficient. Instead, the slot ID (of the device which is directly connected to the port), is added to the its corresponding 'xhci_port' struct. As a result, finding the port's device is quick and easy. Function 'xhci_find_slot_id_by_port()' is removed, as it is no longer needed. Signed-off-by: Niklas Neronin <niklas.neronin@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240229141438.619372-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
36b24ebf |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: minor coding style cleanup in 'xhci_try_enable_msi()' Remove extra spaces/indentation and add spaces where required. This commit does not change any functionality. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9831960d |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: rework 'xhci_try_enable_msi()' MSI and MSI-X setup code Simplify 'xhci_try_enable_msi()' and reduce unnecessary function calls. xHCI driver first tries to allocate 'num_online_cpu()' number of MSI-X vectors, if that fails it falls back to a single MSI vector. There is no good reason for this, we currently only support a primary interrupter. However, we are still interested in knowing if there are more vectors available, which will be utilized once we get secondary interrupter support. Call 'pci_alloc_irq_vectors()' once (with MSI-X and MSI flag), instead of separately for MSI-X and MSI. And accept any number of MSI-X or MSI vectors between 1 and 'num_online_cpu()'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-17-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
dfbf4441 |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: change 'msix_count' to encompass MSI or MSI-X vectors Instead of variable 'msix_count' containing the number of MSI-X vectors, now it can contains MSI or MSI-X vector amount. Because both interrupt methods allow several vectors. Thus, 'msix_count' is renamed to 'nvecs'. Additionally, instead of storing the maximum possible vector amount, now it stores the amount of successfully allocated vectors, or negative integer on allocation failure. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a795f708 |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: refactor static MSI function The current way the xhci driver sets up MSI interrupts is overly complex and messy. The whole MSI setup can be done in one simple function. Continue refactoring MSI/MSI-X setup by incorporating 'xhci_setup_msi()' into 'xhci_try_enable_msi()'. Now all interrupt enabling is contained in one function, which should make it easier to rework. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
74554e9c |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: refactor static MSI-X function The current way the xhci driver sets up MSI/MSI-X interrupts is overly complex and messy. The whole MSI/MSI-X setup can be done in one simple function. Start refactoring this by incorporating 'xhci_setup_msix()' into 'xhci_try_enable_msi()'. 'xhci_setup_msix()' is a static function which is only called by 'xhci_try_enable_msi()'. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f977f4c9 |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: add handler for only one interrupt line Current xHCI driver only supports one "interrupter", meaning we will only use one MSI/MSI-X interrupt line. Thus, add handler only to the first interrupt line. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5080ef2d |
|
01-Dec-2023 |
Niklas Neronin <niklas.neronin@linux.intel.com> |
xhci: check if legacy irq is available before using it as fallback Move the error check "No MSI-X/MSI found and no IRQ in BIOS" inside 'goto legacy'. It is better to check if the IRQ interrupt is available, before trying to add a handler. Additionally the aforementioned error message is much more clear. Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231201150647.1307406-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
24be0b3c |
|
05-Dec-2023 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
Revert "xhci: Loosen RPM as default policy to cover for AMD xHC 1.1" This reverts commit 4baf1218150985ee3ab0a27220456a1f027ea0ac. Enabling runtime pm as default for all AMD xHC 1.1 controllers caused regression. An initial attempt to fix those was done in commit a5d6264b638e ("xhci: Enable RPM on controllers that support low-power states") but new issues are still seen. Revert this to get those AMD xHC 1.1 systems working This patch went to stable an needs to be reverted from there as well. Fixes: 4baf12181509 ("xhci: Loosen RPM as default policy to cover for AMD xHC 1.1") Link: https://lore.kernel.org/linux-usb/55c50bf5-bffb-454e-906e-4408c591cb63@molgen.mpg.de Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231205090548.1377667-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a5d6264b |
|
19-Oct-2023 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
xhci: Enable RPM on controllers that support low-power states Use the low-power states of the underlying platform to enable runtime PM. If the platform doesn't support runtime D3, then enabling default RPM will result in the controller malfunctioning, as in the case of hotplug devices not being detected because of a failed interrupt generation. Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231019102924.2797346-16-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4baf1218 |
|
19-Oct-2023 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
xhci: Loosen RPM as default policy to cover for AMD xHC 1.1 The AMD USB host controller (1022:43f7) isn't going into PCI D3 by default without anything connected. This is because the policy that was introduced by commit a611bf473d1f ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices") only covered 1.2 or later. The 1.1 specification also has the same requirement as the 1.2 specification for D3 support. So expand the runtime PM as default policy to all AMD 1.1 devices as well. Fixes: a611bf473d1f ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices") Link: https://composter.com.ua/documents/xHCI_Specification_for_USB.pdf Co-developed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20231019102924.2797346-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5bef4b3c |
|
13-Jul-2023 |
Oliver Neukum <oneukum@suse.com> |
Revert "xhci: add quirk for host controllers that don't update endpoint DCS" This reverts commit 5255660b208aebfdb71d574f3952cf48392f4306. This quirk breaks at least the following hardware: 0b:00.0 0c03: 1106:3483 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1106:3483 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 66 Region 0: Memory at fb400000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable+ Count=1/4 Maskable- 64bit+ Address: 00000000fee007b8 Data: 0000 Capabilities: [c4] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 89W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <16us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Kernel driver in use: xhci_hcd Kernel modules: xhci_pci with the quirk enabled it fails early with [ 0.754373] pci 0000:0b:00.0: xHCI HW did not halt within 32000 usec status = 0x1000 [ 0.754419] pci 0000:0b:00.0: quirk_usb_early_handoff+0x0/0x7a0 took 31459 usecs [ 2.228048] xhci_hcd 0000:0b:00.0: xHCI Host Controller [ 2.228053] xhci_hcd 0000:0b:00.0: new USB bus registered, assigned bus number 7 [ 2.260073] xhci_hcd 0000:0b:00.0: Host halt failed, -110 [ 2.260079] xhci_hcd 0000:0b:00.0: can't setup: -110 [ 2.260551] xhci_hcd 0000:0b:00.0: USB bus 7 deregistered [ 2.260624] xhci_hcd 0000:0b:00.0: init 0000:0b:00.0 fail, -110 [ 2.260639] xhci_hcd: probe of 0000:0b:00.0 failed with error -110 The hardware in question is an external PCIe card. It looks to me like the quirk needs to be narrowed down. But this needs information about the hardware showing the issue this quirk is to fix. So for now a clean revert. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 5255660b208a ("xhci: add quirk for host controllers that don't update endpoint DCS") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230713112830.21773-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d5e234ff |
|
02-Jun-2023 |
Weitao Wang <WeitaoWang-oc@zhaoxin.com> |
xhci: Add ZHAOXIN xHCI host U1/U2 feature support Add U1/U2 feature support of xHCI for ZHAOXIN. Since both INTEL and ZHAOXIN need to check the tier where the device is located to determine whether to enabled U1/U2, remove the previous INTEL U1/U2 tier policy and add common policy in xhci_check_tier_policy. If vendor has specific U1/U2 enable policy,quirks can be add to declare. Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Message-ID: <20230602144009.1225632-12-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d9b0328d |
|
02-Jun-2023 |
Weitao Wang <WeitaoWang-oc@zhaoxin.com> |
xhci: Show ZHAOXIN xHCI root hub speed correctly Some ZHAOXIN xHCI controllers follow usb3.1 spec, but only support gen1 speed 5Gbps. While in Linux kernel, if xHCI suspport usb3.1, root hub speed will show on 10Gbps. To fix this issue of ZHAOXIN xHCI platforms, read usb speed ID supported by xHCI to determine root hub speed. And add a quirk XHCI_ZHAOXIN_HOST for this issue. [fix warning about uninitialized symbol -Mathias] Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Message-ID: <20230602144009.1225632-11-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2a865a65 |
|
02-Jun-2023 |
Weitao Wang <WeitaoWang-oc@zhaoxin.com> |
xhci: Fix TRB prefetch issue of ZHAOXIN hosts On some ZHAOXIN hosts, xHCI will prefetch TRB for performance improvement. However this TRB prefetch mechanism may cross page boundary, which may access memory not allocated by xHCI driver. In order to fix this issue, two pages was allocated for a segment and only the first page will be used. And add a quirk XHCI_ZHAOXIN_TRB_FETCH for this issue. Cc: stable@vger.kernel.org Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Message-ID: <20230602144009.1225632-10-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f9277281 |
|
02-Jun-2023 |
Weitao Wang <WeitaoWang-oc@zhaoxin.com> |
xhci: Fix resume issue of some ZHAOXIN hosts On ZHAOXIN ZX-100 project, xHCI can't work normally after resume from system Sx state. To fix this issue, when resume from system Sx state, reinitialize xHCI instead of restore. So, Add XHCI_RESET_ON_RESUME quirk for ZX-100 to fix issue of resuming from system Sx state. Cc: stable@vger.kernel.org Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Message-ID: <20230602144009.1225632-9-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0a477620 |
|
02-Jun-2023 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: get rid of XHCI_PLAT quirk that used to prevent MSI setup The XHCI_PLAT quirk was only needed to ensure non-PCI xHC host avoided setting up MSI interrupts in generic xhci codepaths. The MSI setup code is now moved to PCI specific xhci-pci.c file so the quirk is no longer needed. Remove setting the XHCI_PLAT quirk for HiSilocon SoC xHC, NVIDIA Tegra xHC, MediaTek xHC, the generic xhci-plat driver, and the checks for XHCI_PLAT in xhci-pci.c MSI setup code. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Message-ID: <20230602144009.1225632-5-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1f7d5520 |
|
28-Apr-2023 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
USB: Extend pci resume function to handle PM events Currently, the pci_resume method has only a flag indicating whether the system is resuming from hibernation. In order to handle all PM events like AUTO_RESUME (runtime resume from device in D3), RESUME (system resume from s2idle, S3 or S4 states) etc change the pci_resume method to handle all PM events. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230428140056.1318981-2-Basavaraj.Natikar@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2a821fc3 |
|
15-May-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
xhci-pci: Only run d3cold avoidance quirk for s2idle Donghun reports that a notebook that has an AMD Ryzen 5700U but supports S3 has problems with USB after resuming from suspend. The issue was bisected down to commit d1658268e439 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir"). As this issue only happens on S3, narrow the broken D3cold quirk to only run in s2idle. Fixes: d1658268e439 ("usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir") Reported-and-tested-by: Donghun Yoon <donghun.yoon@lge.com> Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230515134059.161110-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
130eac41 |
|
28-Mar-2023 |
Arnd Bergmann <arnd@arndb.de> |
xhci: use pm_ptr() instead of #ifdef for CONFIG_PM conditionals A recent patch caused an unused-function warning in builds with CONFIG_PM disabled, after the function became marked 'static': drivers/usb/host/xhci-pci.c:91:13: error: 'xhci_msix_sync_irqs' defined but not used [-Werror=unused-function] 91 | static void xhci_msix_sync_irqs(struct xhci_hcd *xhci) | ^~~~~~~~~~~~~~~~~~~ This could be solved by adding another #ifdef, but as there is a trend towards removing CONFIG_PM checks in favor of helper macros, do the same conversion here and use pm_ptr() to get either a function pointer or NULL but avoid the warning. As the hidden functions reference some other symbols, make sure those are visible at compile time, at the minimal cost of a few extra bytes for 'struct usb_device'. Fixes: 9abe15d55dcc ("xhci: Move xhci MSI sync function to to xhci-pci") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230328131114.1296430-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9abe15d5 |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: Move xhci MSI sync function to to xhci-pci Move function to sync MSI from xhci.c to xhci-pci.c to decouple PCI specific code from generic xhci code. No functional changes, function is an exact copy [commit message rewording -Mathias] Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-15-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0c540438 |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: Call MSI sync function from xhci-pci instead of generic xhci code Call function to sync MSI interrupts from pci specific xhci_pci_suspend() function in xhci-pci.c instead of from generic xhci_suspend() [commit message rewording -Mathias] Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-14-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ba47b1aa |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: Move functions to cleanup MSI to xhci-pci Move function to cleanup MSI from xhci.c to xhci-pci.c This is to decouple PCI specific code from generic xhci code. No functional changes, function is an exact copy Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-13-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ed526ba2 |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: move PCI specific MSI/MSIX cleanup away from generic xhci functions Call the PCI specific MSI/MSIX interrupt freeing code from the xhci-pci callbacks instead of generic xhci code, decoupling PCI parts from generic xhci functions. Adds xhci_pci_stop() that overrides xhci_stop() for PCI xHC controllers. This will free MSIX interrupts a bit later in the hc_driver stop callback, but is still earlier than usb core frees "legacy" interrupts, or interrupts for other hosts. Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fabbd95c |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: Move functions to setup msi to xhci-pci Move functions to setup msi from xhci.c to xhci-pci.c to decouple PCI specific code from generic xhci code. No functional changes, functions are an exact copy [commit message rewording -Mathias] Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
944e7deb |
|
17-Mar-2023 |
Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> |
xhci: Avoid PCI MSI/MSIX interrupt reinitialization at resume xhci MSI setup is currently done at the same time as xHC host is started in xhci_run(). This couples the generic xhci code with PCI, and will reconfigure MSI/MSIX interrupts every time xHC is started. Decouple MSI/MSIX configuration from generic xhci code by moving MSI/MSIX part to a PCI specific xhci_pci_run() function overriding xhci_run(). This allows us to remove unnecessay MSI/MSIX reconfiguration done every time PCI xhci resumes from suspend. i.e. remove the xhci_cleanup_msix() call from xhci_resume() and the xhci_try_enale_msi() call in xhci_run() called a bit later by xhci_resume() [minor changes and commit message rewrite -Mathias] Signed-off-by: Josue David Hernandez Gutierrez <josue.d.hernandez.gutierrez@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8e77d3d5 |
|
30-Mar-2023 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
Revert "usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS" This reverts commit 4c2604a9a6899bab195edbee35fc8d64ce1444aa. Asynch probe caused regression in a setup with both Renesas and Intel xHC controllers. Devices connected to the Renesas disconnected shortly after boot. With Asynch probe the busnumbers got interleaved. xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 2 xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3 xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4 Reason why this commit causes regression is still unknown, but revert it while debugging the issue. Fixes: 4c2604a9a689 ("usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/linux-usb/20230307132120.5897c5af@deangelis.fenrir.org.uk Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230330143056.1390020-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
74622f0a |
|
16-Jan-2023 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Detect lpm incapable xHC USB3 roothub ports from ACPI tables USB3 ports on xHC hosts may have retimers that cause too long exit latency to work with native USB3 U1/U2 link power management states. For now only use usb_acpi_port_lpm_incapable() to evaluate if port lpm should be disabled while setting up the USB3 roothub. Other ways to identify lpm incapable ports can be added here later if ACPI _DSM does not exist. Limit this to Intel hosts for now, this is to my knowledge only an Intel issue. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230116142216.1141605-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
23a3b8d5 |
|
16-Jan-2023 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Add update_hub_device override for PCI xHCI hosts Allow PCI hosts to check and tune roothub and port settings before the hub is up and running. This override is needed to turn off U1 and U2 LPM for some ports based on per port ACPI _DSM, _UPC, or possibly vendor specific mmio values for Intel xHC hosts. Usb core calls the host update_hub_device once it creates a hub. Entering U1 or U2 link power save state on ports with this limitation will cause link to fail, turning the usb device unusable in that setup. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230116142216.1141605-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
93915a41 |
|
16-Jan-2023 |
Ricardo Ribalda <ribalda@chromium.org> |
xhci-pci: set the dma max_seg_size Allow devices to have dma operations beyond 64K, and avoid warnings such as: xhci_hcd 0000:00:14.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230116142216.1141605-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c3bbacd6 |
|
30-Nov-2022 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: disable U3 suspended ports in S4 hibernate poweroff_late stage Disable U3 suspended ports in hibernate S4 poweroff_late for systems with XHCI_RESET_TO_DEFAULT quirk, if wakeup is not enabled. This reduces the number of self-powered usb devices from surviving in U3 suspended state into next reboot. Bootloader/firmware on these systems can't handle usb ports in U3, and will timeout, causing extra delay during reboot/restore from S4. Add pci_poweroff_late() callback to struct usb_hcd to get this done at the correct stage in hibernate. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221130091944.2171610-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fed70b61 |
|
30-Nov-2022 |
Reka Norman <rekanorman@chromium.org> |
xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N ADL-N systems have the same issue as ADL-P, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to ADL-N as well. This patch depends on commit 34cd2db408d5 ("xhci: Add quirk to reset host back to default state at shutdown"). The issue it fixes is a ~20s boot time delay when booting from S5. It affects ADL-N devices, and ADL-N support was added starting from v5.16. Cc: stable@vger.kernel.org Signed-off-by: Reka Norman <rekanorman@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221130091944.2171610-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4c2604a9 |
|
28-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
usb: xhci-pci: Set PROBE_PREFER_ASYNCHRONOUS This driver often takes on the order of 10ms to start, but in some cases takes more than 100ms. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20221028184507.v2.2.I5a309231785d3a4e37118a25e84f5caa0136a343@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a611bf47 |
|
24-Oct-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices For optimal power consumption of USB4 routers the XHCI PCIe endpoint used for tunneling must be in D3. Historically this is accomplished by a long list of PCIe IDs that correspond to these endpoints because the xhci_hcd driver will not default to allowing runtime PM for all devices. As both AMD and Intel have released new products with new XHCI controllers this list continues to grow. In reviewing the XHCI specification v1.2 on page 607 there is already a requirement that the PCI power management states D3hot and D3cold must be supported. In the quirk list, use this to indicate that runtime PM should be allowed on XHCI controllers. The following controllers are known to be xHC 1.2 and dropped explicitly: * AMD Yellow Carp * Intel Alder Lake * Intel Meteor Lake * Intel Raptor Lake [keep PCI ID for Alder Lake PCH for recently added quirk -Mathias] Cc: stable@vger.kernel.org Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221024142720.4122053-4-mathias.nyman@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
34cd2db4 |
|
24-Oct-2022 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Add quirk to reset host back to default state at shutdown Systems based on Alder Lake P see significant boot time delay if boot firmware tries to control usb ports in unexpected link states. This is seen with self-powered usb devices that survive in U3 link suspended state over S5. A more generic solution to power off ports at shutdown was attempted in commit 83810f84ecf1 ("xhci: turn off port power in shutdown") but it caused regression. Add host specific XHCI_RESET_TO_DEFAULT quirk which will reset host and ports back to default state in shutdown. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221024142720.4122053-3-mathias.nyman@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4f547472 |
|
24-Oct-2022 |
Jens Glathe <jens.glathe@oldschoolsolutions.biz> |
usb: xhci: add XHCI_SPURIOUS_SUCCESS to ASM1042 despite being a V0.96 controller This appears to fix the error: "xhci_hcd <address>; ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13" that appear spuriously (or pretty often) when using a r8152 USB3 ethernet adapter with integrated hub. ASM1042 reports as a 0.96 controller, but appears to behave more like 1.0 Inspired by this email thread: https://markmail.org/thread/7vzqbe7t6du6qsw3 Cc: stable@vger.kernel.org Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221024142720.4122053-2-mathias.nyman@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4e55e22d |
|
31-Aug-2022 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
USB: hcd-pci: Drop the unused id parameter from usb_hcd_pci_probe() Since the HC driver is now passed to the function with its own parameter (it used to be picked from id->driver_data), the id parameter serves no purpose. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220831125052.71584-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8ffdc53a |
|
23-Jun-2022 |
Utkarsh Patel <utkarsh.h.patel@intel.com> |
xhci-pci: Allow host runtime PM as default for Intel Meteor Lake xHCI Meteor Lake TCSS(Type-C Subsystem) xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@kernel.org Signed-off-by: Utkarsh Patel <utkarsh.h.patel@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220623111945.1557702-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7516da47 |
|
23-Jun-2022 |
Tanveer Alam <tanveer1.alam@intel.com> |
xhci-pci: Allow host runtime PM as default for Intel Raptor Lake xHCI In the same way as Intel Alder Lake TCSS (Type-C Subsystem) the Raptor Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@kernel.org Signed-off-by: Tanveer Alam <tanveer1.alam@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220623111945.1557702-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
74f55a62 |
|
11-May-2022 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Allow host runtime PM as default for Intel Alder Lake N xHCI Alder Lake N TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3 and thus save energy Cc: stable@kernel.org Suggested-by: Gopal Vamshi Krishna <vamshi.krishna.gopal@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220511220450.85367-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
15ad5b61 |
|
11-May-2022 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Remove quirk for over 10 year old evaluation hardware The XHCI_RESET_EP_QUIRK was added in 2009 to support prototype xHC hardware from Fresco Logic that needed an additional configure endpoint command after a reset endpoint. That hardware should not have made it to the market. Now, 13 years later its about time we get rid of it. quirk was added in commit ac9d8fe7c6a8 ("USB: xhci: Add quirk for Fresco Logic xHCI hardware.") Print a debug message about the removed quirk if against all odds we run into this controller. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220511220450.85367-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d8bfe509 |
|
08-Apr-2022 |
Evan Green <evgreen@chromium.org> |
xhci: Enable runtime PM on second Alderlake controller Alderlake has two XHCI controllers with PCI IDs 0x461e and 0x51ed. We had previously added the quirk to default enable runtime PM for 0x461e, now add it for 0x51ed as well. Signed-off-by: Evan Green <evgreen@chromium.org> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20220408114225.1.Ibcff6b86ed4eacfe4c4bc89c90e18416f3900a3e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e4844092 |
|
21-Dec-2021 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Fresco FL1100 controller should not have BROKEN_MSI quirk set. The Fresco Logic FL1100 controller needs the TRUST_TX_LENGTH quirk like other Fresco controllers, but should not have the BROKEN_MSI quirks set. BROKEN_MSI quirk causes issues in detecting usb drives connected to docks with this FL1100 controller. The BROKEN_MSI flag was apparently accidentally set together with the TRUST_TX_LENGTH quirk Original patch went to stable so this should go there as well. Fixes: ea0f69d82119 ("xhci: Enable trust tx length quirk for Fresco FL11 USB controller") Cc: stable@vger.kernel.org cc: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211221112825.54690-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f886d4fb |
|
15-Dec-2021 |
Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com> |
usb: xhci: Extend support for runtime power management for AMD's Yellow carp. AMD's Yellow Carp platform has few more XHCI controllers, enable the runtime power management support for the same. Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211215093216.1839065-1-Nehal-Bakulchandra.shah@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
97918f79 |
|
12-Oct-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
usb: xhci: Use to_pci_driver() instead of pci_dev->driver Struct pci_driver contains a struct device_driver, so for PCI devices, it's easy to convert a device_driver * to a pci_driver * with to_pci_driver(). The device_driver * is in struct device, so we don't need to also keep track of the pci_driver * in struct pci_dev. Replace pdev->driver with to_pci_driver(). This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-11-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
660a92a5 |
|
14-Oct-2021 |
Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com> |
usb: xhci: Enable runtime-pm by default on AMD Yellow Carp platform AMD's Yellow Carp platform supports runtime power management for XHCI Controllers, so enable the same by default for all XHCI Controllers. [ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias] Cc: stable <stable@vger.kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ea0f69d8 |
|
07-Oct-2021 |
Nikolay Martynov <mar.kolya@gmail.com> |
xhci: Enable trust tx length quirk for Fresco FL11 USB controller Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth. Cc: stable@vger.kernel.org Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5255660b |
|
07-Oct-2021 |
Jonathan Bell <jonathan@raspberrypi.org> |
xhci: add quirk for host controllers that don't update endpoint DCS Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. [ bjorn: rebased to v5.14-rc2 ] Link: https://github.com/raspberrypi/linux/issues/3060 Cc: stable@vger.kernel.org Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
884c2744 |
|
17-Jul-2021 |
Moritz Fischer <mdf@kernel.org> |
usb: renesas-xhci: Remove renesas_xhci_pci_exit() Remove empty function renesas_xhci_pci_exit() that does not actually do anything. Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by: Moritz Fischer <mdf@kernel.org> Link: https://lore.kernel.org/r/20210718015111.389719-3-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0665e387 |
|
02-Jul-2021 |
Greg Thelen <gthelen@google.com> |
usb: xhci: avoid renesas_usb_fw.mem when it's unusable Commit a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory") added renesas_usb_fw.mem firmware reference to xhci-pci. Thus modinfo indicates xhci-pci.ko has "firmware: renesas_usb_fw.mem". But the firmware is only actually used with CONFIG_USB_XHCI_PCI_RENESAS. An unusable firmware reference can trigger safety checkers which look for drivers with unmet firmware dependencies. Avoid referring to renesas_usb_fw.mem in circumstances when it cannot be loaded (when CONFIG_USB_XHCI_PCI_RENESAS isn't set). Fixes: a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory") Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Thelen <gthelen@google.com> Link: https://lore.kernel.org/r/20210702071224.3673568-1-gthelen@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d1658268 |
|
27-May-2021 |
Mario Limonciello <mario.limonciello@amd.com> |
usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir The XHCI controller is required to enter D3hot rather than D3cold for AMD s2idle on this hardware generation. Otherwise, the 'Controller Not Ready' (CNR) bit is not being cleared by host in resume and eventually this results in xhci resume failures during the s2idle wakeup. Link: https://lore.kernel.org/linux-usb/1612527609-7053-1-git-send-email-Prike.Liang@amd.com/ Suggested-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Cc: stable <stable@vger.kernel.org> # 5.11+ Link: https://lore.kernel.org/r/20210527154534.8900-1-mario.limonciello@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
3c128781 |
|
12-May-2021 |
Sandeep Singh <sandeep.singh@amd.com> |
xhci: Add reset resume quirk for AMD xhci controller. One of AMD xhci controller require reset on resume. Occasionally AMD xhci controller does not respond to Stop endpoint command. Once the issue happens controller goes into bad state and in that case controller needs to be reset. Cc: <stable@vger.kernel.org> Signed-off-by: Sandeep Singh <sandeep.singh@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b8135111 |
|
12-May-2021 |
Abhijeet Rao <abhijeet.rao@intel.com> |
xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCI In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Cc: stable@vger.kernel.org Signed-off-by: Abhijeet Rao <abhijeet.rao@intel.com> Signed-off-by: Nikunj A. Dadhania <nikunj.dadhania@intel.com> Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b71c669a |
|
11-Mar-2021 |
Forest Crossman <cyrozap@gmail.com> |
usb: xhci: Fix ASMedia ASM1042A and ASM3242 DMA addressing I've confirmed that both the ASMedia ASM1042A and ASM3242 have the same problem as the ASM1142 and ASM2142/ASM3142, where they lose some of the upper bits of 64-bit DMA addresses. As with the other chips, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Cc: stable@vger.kernel.org Signed-off-by: Forest Crossman <cyrozap@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210311115353.2137560-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a4a251f8 |
|
11-Mar-2021 |
Stanislaw Gruszka <stf_xl@wp.pl> |
usb: xhci: do not perform Soft Retry for some xHCI hosts On some systems rt2800usb and mt7601u devices are unable to operate since commit f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") Seems that some xHCI controllers can not perform Soft Retry correctly, affecting those devices. To avoid the problem add xhci->quirks flag that restore pre soft retry xhci behaviour for affected xHCI controllers. Currently those are AMD_PROMONTORYA_4 and AMD_PROMONTORYA_2, since it was confirmed by the users: on those xHCI hosts issue happen and is gone after disabling Soft Retry. [minor commit message rewording for checkpatch -Mathias] Fixes: f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") Cc: <stable@vger.kernel.org> # 4.20+ Reported-by: Bernhard <bernhard.gebetsberger@gmx.at> Tested-by: Bernhard <bernhard.gebetsberger@gmx.at> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541 Link: https://lore.kernel.org/r/20210311115353.2137560-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5a8e3229 |
|
08-Dec-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
xhci-pci: Allow host runtime PM as default for Intel Maple Ridge xHCI Intel Maple Ridge is successor of Titan Ridge Thunderbolt controller. As Titan Ridge this one also includes xHCI host controller. In order to safe energy we should put it to low power state by default when idle. For this reason allow host runtime PM for Maple Ridge. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201208092912.1773650-5-mathias.nyman@linux.intel.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c4d1ca05 |
|
08-Dec-2020 |
Hans de Goede <hdegoede@redhat.com> |
xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LP The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt controller awake if the host controller is not allowed to sleep. This is the case even if no USB devices are connected to the host. Add the Intel Alpine Ridge LP product-id to the list of product-ids for which we allow runtime PM by default. Fixes: 2815ef7fe4d4 ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge") Cc: <stable@vger.kernel.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201208092912.1773650-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2a632815 |
|
28-Oct-2020 |
Sandeep Singh <sandeep.singh@amd.com> |
usb: xhci: Workaround for S3 issue on AMD SNPS 3.0 xHC On some platform of AMD, S3 fails with HCE and SRE errors. To fix this, need to disable a bit which is enable in sparse controller. Cc: stable@vger.kernel.org #v4.19+ Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sandeep Singh <sandeep.singh@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201028203124.375344-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
768430e4 |
|
29-Jun-2020 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
usb: xhci-pci: Add support for reset controllers Some atypical users of xhci-pci might need to manually reset their xHCI controller before starting the HCD setup. Check if a reset controller device is available to the PCI bus and trigger a reset. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20200629161845.6021-6-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ec37198a |
|
27-Jul-2020 |
Forest Crossman <cyrozap@gmail.com> |
usb: xhci: Fix ASMedia ASM1142 DMA addressing I've confirmed that the ASMedia ASM1142 has the same problem as the ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA addresses when in fact it does not. As with the ASM2142/ASM3142, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1841cb25 |
|
27-Jul-2020 |
Forest Crossman <cyrozap@gmail.com> |
usb: xhci: define IDs for various ASMedia host controllers Not all ASMedia host controllers have a device ID that matches its part number. #define some of these IDs to make it clearer at a glance which chips require what quirks. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Forest Crossman <cyrozap@gmail.com> Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
dbb0897e |
|
17-Jul-2020 |
Forest Crossman <cyrozap@gmail.com> |
usb: xhci: Fix ASM2142/ASM3142 DMA addressing The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA addresses, which can cause silent memory corruption or IOMMU errors on platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk to fix this issue. Signed-off-by: Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a66d21d7 |
|
14-May-2020 |
Vinod Koul <vkoul@kernel.org> |
usb: xhci: Add support for Renesas controller with memory Some rensas controller like uPD720201 and uPD720202 need firmware to be loaded. Add these devices in table and invoke renesas firmware loader functions to check and load the firmware into device memory when required. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-4-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ff4c65ca |
|
14-May-2020 |
Vinod Koul <vkoul@kernel.org> |
usb: hci: add hc_driver as argument for usb_hcd_pci_probe usb_hcd_pci_probe expects users to call this with driver_data set as hc_driver, that limits the possibility of using the driver_data for driver data. Add hc_driver as argument to usb_hcd_pci_probe and modify the callers ehci/ohci/xhci/uhci to pass hc_driver as argument and freeup the driver_data used Tested xhci driver on Dragon-board RB3, compile tested ehci, ohci and uhci. [For all but the xHCI parts] [For the xhci part] Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-2-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6a7c533d |
|
12-Mar-2020 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
xhci-pci: Allow host runtime PM as default for Intel Tiger Lake xHCI In the same way as Intel Ice Lake TCSS (Type-C Subsystem) the Tiger Lake TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3cold and thus save energy. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200312144517.1593-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2170a98d |
|
12-Mar-2020 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
usb: xhci: Enable LPM for VIA LABS VL805 This PCIe controller chip is used on the Raspberry Pi 4 and multiple adapter cards. There is no publicly available documentation for the chip, yet both the downstream RPi4 kernel and the controller cards support/advertise LPM support. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200312144517.1593-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
16263abc |
|
06-Mar-2020 |
Alberto Mattea <alberto@mattea.info> |
usb: xhci: apply XHCI_SUSPEND_DELAY to AMD XHCI controller 1022:145c This controller timeouts during suspend (S3) with [ 240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout [ 240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event thus preventing the system from entering S3. Moreover it remains in an undefined state where some connected devices stop working until a reboot. Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly. CC: stable@vger.kernel.org Signed-off-by: Alberto Mattea <alberto@mattea.info> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c02f1ef6 |
|
18-Feb-2020 |
Corentin Labbe <clabbe@baylibre.com> |
usb: host: xhci-pci: remove useless cast for driver.name pci_driver name is const char pointer, so it not useful to cast hcd_name (which is already const char). Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Link: https://lore.kernel.org/r/1582054383-35760-20-git-send-email-clabbe@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a3ae87dc |
|
10-Feb-2020 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: apply XHCI_PME_STUCK_QUIRK to Intel Comet Lake platforms Intel Comet Lake based platform require the XHCI_PME_STUCK_QUIRK quirk as well. Without this xHC can not enter D3 in runtime suspend. Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
024d411e |
|
10-Feb-2020 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: fix runtime pm enabling for quirky Intel hosts Intel hosts that need the XHCI_PME_STUCK_QUIRK flag should enable runtime pm by calling xhci_pme_acpi_rtd3_enable() before usb_hcd_pci_probe() calls pci_dev_run_wake(). Otherwise usage count for the device won't be decreased, and runtime suspend is prevented. usb_hcd_pci_probe() only decreases the usage count if device can generate run-time wake-up events, i.e. when pci_dev_run_wake() returns true. This issue was exposed by pci_dev_run_wake() change in commit 8feaec33b986 ("PCI / PM: Always check PME wakeup capability for runtime wakeup support") and should be backported to kernels with that change Cc: <stable@vger.kernel.org> # 4.13+ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6056a0f8 |
|
17-Dec-2019 |
Guenter Roeck <linux@roeck-us.net> |
usb: xhci: Fix build warning seen with CONFIG_PM=n The following build warning is seen if CONFIG_PM is disabled. drivers/usb/host/xhci-pci.c:498:13: warning: unused function 'xhci_pci_shutdown' Fixes: f2c710f7dca8 ("usb: xhci: only set D3hot for pci device") Cc: Henry Lin <henryl@nvidia.com> Cc: stable@vger.kernel.org # all stable releases with f2c710f7dca8 Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20191218011911.6907-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f2c710f7 |
|
11-Dec-2019 |
Henry Lin <henryl@nvidia.com> |
usb: xhci: only set D3hot for pci device Xhci driver cannot call pci_set_power_state() on non-pci xhci host controllers. For example, NVIDIA Tegra XHCI host controller which acts as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform hits this issue during shutdown. Cc: <stable@vger.kernel.org> Fixes: 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") Signed-off-by: Henry Lin <henryl@nvidia.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
07a594f3 |
|
15-Nov-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
xhci-pci: Allow host runtime PM as default also for Intel Ice Lake xHCI Intel Ice Lake has two xHCI controllers one on PCH and the other as part of the CPU itself. The latter is also part of the so called Type C Subsystem (TCSS) sharing ACPI power resources with the PCIe root ports and the Thunderbolt controllers. In order to put the whole TCSS block into D3cold the xHCI needs to be runtime suspended as well when idle. For this reason allow runtime PM as default for Ice Lake TCSS xHCI controller. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1573836603-10871-5-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4fbb8aa7 |
|
04-Jul-2019 |
Ryan Kennedy <ryan5544@gmail.com> |
usb: pci-quirks: Minor cleanup for AMD PLL quirk usb_amd_find_chipset_info() is used for chipset detection for several quirks. It is strange that its return value indicates the need for the PLL quirk, which means it is often ignored. This patch adds a function specifically for checking the PLL quirk like the other ones. Additionally, rename probe_result to something more appropriate. Signed-off-by: Ryan Kennedy <ryan5544@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20190704153529.9429-3-ryan5544@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8fde481e |
|
20-Feb-2019 |
Balaji Manoharan <m.balaji@intel.com> |
usb: xhci: Fix for Enabling USB ROLE SWITCH QUIRK on INTEL_SUNRISEPOINT_LP_XHCI This fix enables USB role feature on intel commercial nuc platform which is based on Kabylake chipset. Signed-off-by: Balaji Manoharan <m.balaji@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a7d57abc |
|
05-Dec-2018 |
Sandeep Singh <sandeep.singh@amd.com> |
xhci: workaround CSS timeout on AMD SNPS 3.0 xHC 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 <Shyam-sundar.S-k@amd.com> Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Cc: <stable@vger.kernel.org> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
11644a76 |
|
09-Nov-2018 |
Cherian, George <George.Cherian@cavium.com> |
xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc Implement workaround for ThunderX2 Errata-129 (documented in CN99XX Known Issues" available at Cavium support site). As per ThunderX2errata-129, USB 2 device may come up as USB 1 if a connection to a USB 1 device is followed by another connection to a USB 2 device, the link will come up as USB 1 for the USB 2 device. Resolution: Reset the PHY after the USB 1 device is disconnected. The PHY reset sequence is done using private registers in XHCI register space. After the PHY is reset we check for the PLL lock status and retry the operation if it fails. From our tests, retrying 4 times is sufficient. Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround in handle_xhci_port_status(). Cc: stable@vger.kernel.org Signed-off-by: George Cherian <george.cherian@cavium.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f0680904 |
|
09-Nov-2018 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Fix leaking USB3 shared_hcd at xhci removal Ensure that the shared_hcd pointer is valid when calling usb_put_hcd() The shared_hcd is removed and freed in xhci by first calling usb_remove_hcd(xhci->shared_hcd), and later usb_put_hcd(xhci->shared_hcd) Afer commit fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") the shared_hcd was never properly put as xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was called. shared_hcd (USB3) is removed before primary hcd (USB2). While removing the primary hcd we might need to handle xhci interrupts to cleanly remove last USB2 devices, therefore we need to set xhci->shared_hcd to NULL before removing the primary hcd to let xhci interrupt handler know shared_hcd is no longer available. xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before adding them. so to keep the correct reverse removal order use a temporary shared_hcd variable for them. For more details see commit 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them") Fixes: fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") Cc: Joel Stanley <joel@jms.id.au> Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Thierry Reding <treding@nvidia.com> Cc: Jianguo Sun <sunjianguo1@huawei.com> Cc: <stable@vger.kernel.org> Reported-by: Jack Pham <jackp@codeaurora.org> Tested-by: Jack Pham <jackp@codeaurora.org> Tested-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c02588a3 |
|
01-Oct-2018 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms Intel Apollo Lake has the same internal USB role mux as Intel Cherry Trail. Cc: <stable@vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ffe84e01 |
|
01-Oct-2018 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Add missing CAS workaround for Intel Sunrise Point xHCI The workaround for missing CAS bit is also needed for xHC on Intel sunrisepoint PCH. For more details see: Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2815ef7f |
|
20-Sep-2018 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge The xhci controller on Alpine and Titan Ridge keeps the whole thunderbolt awake if the host controller is not allowed tp sleep. This is the case even if no USB devices are connected to the host. Because of this bigger impact, allow runtime pm as default for these xhci controllers in the driver. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c2ef60fe |
|
23-May-2018 |
Marc Zyngier <maz@kernel.org> |
Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue" This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. Now that we can properly reset the uPD72020x without a hard PCI reset, let's get rid of the existing quirks. Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Faiz Abbas <faiz_abbas@ti.com> Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
12de0a35 |
|
23-May-2018 |
Marc Zyngier <maz@kernel.org> |
xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers Some Renesas controllers get into a weird state if they are reset while programmed with 64bit addresses (they will preserve the top half of the address in internal, non visible registers). You end up with half the address coming from the kernel, and the other half coming from the firmware. Also, changing the programming leads to extra accesses even if the controller is supposed to be halted. The controller ends up with a fatal fault, and is then ripe for being properly reset. On the flip side, this is completely unsafe if the defvice isn't behind an IOMMU, so we have to make sure that this is the case. Can you say "broken"? This is an alternative method to the one introduced in 8466489ef5ba ("xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"), which will subsequently be removed. Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Faiz Abbas <faiz_abbas@ti.com> Tested-by: Domenico Andreoli <domenico.andreoli@linux.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
621faf4f |
|
20-Apr-2018 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
xhci: Fix USB ports for Dell Inspiron 5775 The Dell Inspiron 5775 is a Raven Ridge. The Enable Slot command timed out when a USB device gets plugged: [ 212.156326] xhci_hcd 0000:03:00.3: Error while assigning device slot ID [ 212.156340] xhci_hcd 0000:03:00.3: Max number of devices this xHCI host supports is 64. [ 212.156348] usb usb2-port3: couldn't allocate usb_device AMD suggests that a delay before xHC suspends can fix the issue. I can confirm it fixes the issue, so use the suspend delay quirk for Raven Ridge's xHC. Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fa31b3cb |
|
20-Mar-2018 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Add Intel extended cap / otg phy mux handling The xHCI controller on various Intel SoCs has an extended cap mmio-range which contains registers to control the muxing to the xHCI (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a role-sw driver included in the xHCI code (under drivers/usb/host) is not desirable. So this commit adds a simple handler for this extended capability, which creates a platform device with the caps mmio region as resource, this allows us to write a separate platform role-sw driver for the role-switch. Note this commit adds a call to the new xhci_ext_cap_init() function to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must be called only once. If in the future we also want to handle ext-caps on non pci xHCI HCDs from xhci_ext_cap_init() a call to it should also be added to other bus probe paths. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
191edc5e |
|
08-Mar-2018 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
xhci: Fix front USB ports on ASUS PRIME B350M-A When a USB device gets plugged on ASUS PRIME B350M-A's front ports, the xHC stops working: [ 549.114587] xhci_hcd 0000:02:00.0: WARN: xHC CMD_RUN timeout [ 549.114608] suspend_common(): xhci_pci_suspend+0x0/0xc0 returns -110 [ 549.114638] xhci_hcd 0000:02:00.0: can't suspend (hcd_pci_runtime_suspend returned -110) Delay before running xHC command CMD_RUN can workaround the issue. Use a new quirk to make the delay only targets to the affected xHC. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bde0716d |
|
12-Feb-2018 |
Joe Lee <asmt.swfae@gmail.com> |
xhci: workaround for AMD Promontory disabled ports wakeup For AMD Promontory xHCI host, although you can disable USB ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. [commit and code comment rephrasing -Mathias] Signed-off-by: Joe Lee <asmt.swfae@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
da997066 |
|
21-Dec-2017 |
Daniel Thompson <daniel.thompson@linaro.org> |
usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201 When plugging in a USB webcam I see the following message: xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? handle_tx_event: 913 callbacks suppressed All is quiet again with this patch (and I've done a fair but of soak testing with the camera since). Cc: <stable@vger.kernel.org> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ab725cbe |
|
08-Dec-2017 |
Adam Wallis <awallis@codeaurora.org> |
usb: xhci: allow imod-interval to be configurable The xHCI driver currently has the IMOD set to 160, which translates to an IMOD interval of 40,000ns (160 * 250)ns Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller") introduced a QUIRK for the MTK platform to adjust this interval to 20, which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is due to the fact that the MTK controller IMOD interval is 8 times as much as defined in xHCI spec. Instead of adding more quirk bits for additional platforms, this patch introduces the ability for vendors to set the IMOD_INTERVAL as is optimal for their platform. By using device_property_read_u32() on "imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds. If no interval is specified, the default of 40,000ns (IMOD=160) will be used. No bounds checking has been implemented due to the fact that a vendor may have violated the spec and would need to specify a value outside of the max 8,000 IRQs/second limit specified in the xHCI spec. Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Adam Wallis <awallis@codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9ed64195 |
|
06-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
USB: host: xhci: Remove redundant license text Now that the SPDX tag is in all USB files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5fd54ace |
|
03-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
USB: add SPDX identifiers to all remaining files in drivers/usb/ It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bcd6a7aa |
|
18-Sep-2017 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts" This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f. Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to function after enabling runtime PM. All boards with this chipsets will be affected, so revert the commit. The original patch was added to stable 4.9, 4.11 and 4.12 and needs to reverted from there as well Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8466489e |
|
01-Aug-2017 |
Marc Zyngier <maz@kernel.org> |
xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue The Renesas uPD72020x XHCI controller seems to suffer from a really annoying bug, where it may retain some of its DMA programming across a XHCI reset, and despite the driver correctly programming new DMA addresses. This is visible if the device has been using 64-bit DMA addresses, and is then switched to using 32-bit DMA addresses. The top 32 bits of the address (now zero) are ignored are replaced by the 32 bits from the *previous* programming. Sticking with 64-bit DMA always works, but doesn't seem very appropriate. A PCI reset of the device restores the normal functionality, which is done at probe time. Unfortunately, this has to be done before any quirk has been discovered, hence the intrusive nature of the fix. Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> CC: stable@vger.kernel.org # v4.11+
|
#
9da5a109 |
|
20-Jul-2017 |
Jiahau Chang <jiahau@gmail.com> |
xhci: Bad Ethernet performance plugged in ASM1042A host When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by: Ian Pilcher <arequipeno@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
dec08194 |
|
19-Jun-2017 |
Jiahau Chang <jiahau@gmail.com> |
xhci: Limit USB2 port wake support for AMD Promontory hosts For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. This will disable wake on connect, disconnect and overcurrent on AMD Promontory USB2 ports [checkpatch cleanup and commit message reword -Mathias] Cc: <stable@vger.kernel.org> Cc: Tsai Nicholas <nicholas.tsai@amd.com> Signed-off-by: Jiahau Chang <Lars_Chang@asmedia.com.tw> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d2f48f05 |
|
09-Jun-2017 |
Corentin Labbe <clabbe.montjoie@gmail.com> |
usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk When plugging an USB webcam I see the following message: [106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [106390.583860] handle_tx_event: 913 callbacks suppressed With this patch applied, I get no more printing of this message. Cc: <stable@vger.kernel.org> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
94116f81 |
|
05-Jun-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
ACPI: Switch to use generic guid_t in acpi_evaluate_dsm() acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 bytes. Instead we convert them to use guid_t type. At the same time we convert current users. acpi_str_to_uuid() becomes useless after the conversion and it's safe to get rid of it. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Borislav Petkov <bp@suse.de> Acked-by: Dan Williams <dan.j.williams@intel.com> Cc: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Joerg Roedel <jroedel@suse.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
a0c16630 |
|
17-May-2017 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton Intel Denverton microserver is Atom based and need the PME and CAS quirks as well. Cc: stable <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
69307ccb |
|
07-Apr-2017 |
Roger Quadros <rogerq@ti.com> |
usb: xhci: bInterval quirk for TI TUSB73x0 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 Cc: stable <stable@vger.kernel.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
989bad11 |
|
23-Jan-2017 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: remove unnecessary return in xhci_pci_setup() Remove the unnecessary return line in xhci_pci_setup(). Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6c97cfc1 |
|
03-Jan-2017 |
Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> |
usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Apollo Lake Intel Apollo Lake also requires XHCI_PME_STUCK_QUIRK. Adding its PCI ID to quirk. Cc: <stable@vger.kernel.org> Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
346e9973 |
|
20-Oct-2016 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: workaround for hosts missing CAS bit If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4c39135a |
|
20-Oct-2016 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: add restart quirk for Intel Wildcatpoint PCH xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the same quirks to prevent machines from spurious restart while shutting them down. Reported-by: Hasan Mahmood <hasan.mahm@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f1f6d9a8 |
|
16-Aug-2016 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: don't dereference a xhci member after removing xhci Remove the hcd after checking for the xhci last quirks, not before. This caused a hang on a Alpine Ridge xhci based maching which remove the whole xhci controller when unplugging the last usb device CC: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9d26d3a8 |
|
02-Jun-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
PCI: Put PCIe ports into D3 during suspend Currently the Linux PCI core does not touch power state of PCI bridges and PCIe ports when system suspend is entered. Leaving them in D0 consumes power unnecessarily and may prevent the CPU from entering deeper C-states. With recent PCIe hardware we can power down the ports to save power given that we take into account few restrictions: - The PCIe port hardware is recent enough, starting from 2015. - Devices connected to PCIe ports are effectively in D3cold once the port is transitioned to D3 (the config space is not accessible anymore and the link may be powered down). - Devices behind the PCIe port need to be allowed to transition to D3cold and back. There is a way both drivers and userspace can forbid this. - If the device behind the PCIe port is capable of waking the system it needs to be able to do so from D3cold. This patch adds a new flag to struct pci_device called 'bridge_d3'. This flag is set and cleared by the PCI core whenever there is a change in power management state of any of the devices behind the PCIe port. When system later on is suspended we only need to check this flag and if it is true transition the port to D3 otherwise we leave it in D0. Also provide override mechanism via command line parameter "pcie_port_pm=[off|force]" that can be used to disable or enable the feature regardless of the BIOS manufacturing date. Tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d95815ba |
|
01-Jun-2016 |
Hans de Goede <hdegoede@redhat.com> |
USB: xhci: Add broken streams quirk for Frescologic device id 1009 I got one of these cards for testing uas with, it seems that with streams it dma-s all over the place, corrupting memory. On my first tests it managed to dma over the BIOS of the motherboard somehow and completely bricked it. Tests on another motherboard show that it does work with streams disabled. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
98d74f9c |
|
08-Apr-2016 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will remove the xhci controller from the PCI bus when the last USB device is disconnected. Add a flag to indicate that the host is being removed to avoid queueing configure_endpoint commands for the dropped endpoints. For PCI hotplugged controllers this will prevent 5 second command timeouts For static xhci controllers the configure_endpoint command is not needed in the removal case as everything will be returned, freed, and the controller is reset. For now the flag is only set for PCI connected host controllers. Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0d46faca |
|
08-Apr-2016 |
Rafal Redzimski <rafal.f.redzimski@intel.com> |
usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host Broxton B0 also requires XHCI_PME_STUCK_QUIRK. Adding PCI device ID for Broxton B and adding to quirk. Cc: <stable@vger.kernel.org> Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com> Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ccc04afb |
|
26-Jan-2016 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well. Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
92149c93 |
|
26-Jan-2016 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: set SSIC port unused only if xhci_suspend succeeds XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers in some Intel SoC chips. With this quirk applied, SSIC port is set to "unused" prior to xhci_suspend(). This may cause problem if host fails to suspend. In this case, the port is set to unused without host further entering D3, and the port will not be usable anymore. Cc: stable@vger.kernel.org Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7e70cbff |
|
26-Jan-2016 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: add a quirk bit for ssic port unused Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") share a single quirk bit XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and might happen on different hardwares. Need to separate them by adding a quirk bit for the later. Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fa895377 |
|
26-Jan-2016 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: handle both SSIC ports in PME stuck quirk Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") adds a workaround for a limitation of PME storm caused by SSIC port in some Intel SoCs. This commit only handled one SSIC port, while there are actually two SSIC ports in the chips. This patch handles both SSIC ports. Without this fix, users still see PME storm. Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
84ed9152 |
|
04-Dec-2015 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable() There is a memory leak because acpi_evaluate_dsm() actually returns an object which the caller is supposed to release. Fix this by calling ACPI_FREE() for the returned object (this expands to kfree() so passing NULL there is fine as well). While there correct indentation in !CONFIG_ACPI case. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable <stable@vger.kernel.org> # v4.2 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
32479d4b |
|
24-Nov-2015 |
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> |
usb: host: xhci: cleanup hcd private size This patch cleanups the hcd private size to suitable size. The previous code has "sizeof(struct xhci_hcd *)" in xhci_hc_driver as hcd_priv_size and sizeof(struct xhci_hcd) in xhci_plat_overrides or xhci_pci_overrides as extra_priv_size. However, the xhci driver uses a "sizeof(struct xhcd_hcd)" memory space in each hcd (main_hcd and shared_hcd) actually. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fd7cd061 |
|
12-Oct-2015 |
Laura Abbott <labbott@fedoraproject.org> |
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Cc: Takashi Iwai <tiwai@suse.de> Cc: Oliver Neukum <oneukum@suse.com> [Added more history to commit message -Mathias] Cc: stable <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b50107bb |
|
01-Oct-2015 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: check xhci hardware for USB 3.1 support Set the controller speed to HCD_USB31 to if host hardware supports USB 3.1 For PCI xhci controllers the USB 3.1 support is checked from SBRN bits in pci config space. Platform controllers will need to set xhci->sbrn == 0x31 to indicate USB 3.1 support before calling xhci_gen_setup(). Also make sure xhci driver works correctly with speed set to HCD_USB31 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2b7627b7 |
|
21-Sep-2015 |
Tomer Barletz <barletz@gmail.com> |
xhci: Move xhci_pme_quirk() behind #ifdef CONFIG_PM xhci_pme_quirk() is only used when CONFIG_PM is defined. Compiling a kernel without PM complains about this function [reworded commit message -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: Tomer Barletz <barletz@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
abce329c |
|
21-Jul-2015 |
Rajmohan Mani <rajmohan.mani@intel.com> |
xhci: Workaround to get D3 working in Intel xHCI The xHCI in Intel CherryView / Braswell Platform requires a driver workaround to get xHCI D3 working. Without this workaround, xHCI might not enter D3. Workaround is to configure SSIC PORT as "unused" before D3 entry and "used" after D3 exit. This is done through a vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset 0x883c), in xhci suspend / resume callbacks. Verified xHCI D3 works fine in CherryView / Braswell platform. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c3c5819a |
|
21-Jul-2015 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: call BIOS workaround to enable runtime suspend on Intel Braswell Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled xhci from going to D3 state in runtime suspend. Driver needs to verify it can deal with the hw by calling an ACPI _DSM method to get D3 enabled. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
cd33a321 |
|
29-May-2015 |
Roger Quadros <rogerq@ti.com> |
usb: xhci: cleanup xhci_hcd allocation HCD core allocates memory for HCD private data in usb_create_[shared_]hcd() so make use of that mechanism to allocate the struct xhci_hcd. Introduce struct xhci_driver_overrides to provide the size of HCD private data and hc_driver operation overrides. As of now we only need to override the reset and start methods. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
227a4fd8 |
|
23-Mar-2015 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers When a device with an isochronous endpoint is plugged into the Intel xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under Intel xHCI host controllers, if the event ring is full of events from transfers with BEI set, an "Event Ring is Full" event will be posted to the last entry of the event ring, but no interrupt is generated. Host will cease all transfer and command executions and wait until software completes handling the pending events in the event ring. That means xHC stops, but event of "event ring is full" is not notified. As the result, the xHC looks like dead to user. This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And it should be backported to kernels as old as 3.0, that contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching."). Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Alistair Grant <akgrant0710@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b8cb91e0 |
|
06-Mar-2015 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Workaround for PME stuck issues in Intel xhci The xhci in Intel Sunrisepoint and Cherryview platforms need a driver workaround for a Stuck PME that might either block PME events in suspend, or create spurious PME events preventing runtime suspend. Workaround is to clear a internal PME flag, BIT(28) in a vendor specific PMCTRL register at offset 0x80a4, in both suspend resume callbacks Without this, xhci connected usb devices might never be able to wake up the system from suspend, or prevent device from going to suspend (xhci d3) Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7f5c4d63 |
|
05-Dec-2014 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers Streams do not work reliabe on Fresco Logic FL1000G xhci controllers, trying to use them results in errors like this: 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001 As always I've ordered a pci-e addon card with a Fresco Logic controller for myself to see if I can come up with a better fix then the big hammer, in the mean time this will make uas devices work again (in usb-storage mode) for FL1000G users. Reported-by: Marcin ZajÄ…czkowski <mszpak@wp.pl> Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a1377e53 |
|
18-Nov-2014 |
Lu Baolu <baolu.lu@linux.intel.com> |
usb: xhci: rework root port wake bits if controller isn't allowed to wakeup When system is being suspended, if host device is not allowed to do wakeup, xhci_suspend() needs to clear all root port wake on bits. Otherwise, some platforms may generate spurious wakeup, even if PCI PME# is disabled. The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"), which also got into stable, turned out to not work correctly and had to be reverted, and is now rewritten. Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> [Mathias Nyman: reword commit message] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b45abacd |
|
27-Oct-2014 |
Oliver Neukum <oneukum@suse.de> |
xhci: no switching back on non-ULT Haswell The switch back is limited to ULT even on HP. The contrary finding arose by bad luck in BIOS versions for testing. This fixes spontaneous resume from S3 on some HP laptops. Signed-off-by: Oliver Neukum <oneukum@suse.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2391eacb |
|
28-Oct-2014 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Disable streams on Asmedia 1042 xhci controllers Streams seem to be broken on the Asmedia 1042. An uas capable Seagate disk which is known to work fine with other controllers causes the system to freeze when connected over usb-3 with this controller, where as it works fine with uas in usb-2 ports, indicating a problem with streams. This is a bit bigger hammer then I would like to use for this, but for now it will have to make do. I've ordered a pci-e usb controller card with an Asmedia 1042, once that arrives I'll 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. Reported-by: Bogdan Mihalcea <bogdan.mihalcea@infim.ro> Cc: Bogdan Mihalcea <bogdan.mihalcea@infim.ro> Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
29e409f0 |
|
03-Oct-2014 |
Andrew Bresticker <abrestic@chromium.org> |
xhci: Allow xHCI drivers to be built as separate modules Instead of building all of the xHCI code into a single module, separate it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers. Also update the PCI/platform drivers with module descriptions/licenses and have them register their respective drivers in their initcalls. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e1cd9727 |
|
03-Oct-2014 |
Andrew Bresticker <abrestic@chromium.org> |
xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will have been set based on xhci_compliance_mode_recovery_timer_quirk_check() in xhci_init(). Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
1885d9a3 |
|
03-Oct-2014 |
Andrew Bresticker <abrestic@chromium.org> |
xhci: Introduce xhci_init_driver() Since the struct hc_driver is mostly the same across the xhci-pci, xhci-plat, and the upcoming xhci-tegra driver, introduce the function xhci_init_driver() which will populate the hc_driver with the default xHCI operations. The caller must supply a setup function which will be used as the hc_driver's reset callback. Note that xhci-plat also overrides the default ->start() callback so that it can do rcar-specific initialization. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e21eba05 |
|
24-Aug-2014 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Disable streams on Via XHCI with device-id 0x3432 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 <hdegoede@redhat.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2597fe99 |
|
19-Aug-2014 |
Huang Rui <ray.huang@amd.com> |
usb: xhci: amd chipset also needs short TX quirk AMD xHC also needs short tx quirk after tested on most of chipset generations. That's because there is the same incorrect behavior like Fresco Logic host. Please see below message with on USB webcam attached on xHC host: [ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Reported-by: Arindam Nath <arindam.nath@amd.com> Tested-by: Shriraj-Rai P <shriraj-rai.p@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
170625e9 |
|
25-Jul-2014 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Rename Asrock P67 pci product-id to EJ168 The 7023 product id is the generic product id for the Etron EJ168, it is not specific to the version found on the Asrock P67 motherboard. The same id is e.g. also used on Gigabyte motherboards and on no-name pci-e usb-3 addon cards. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8f873c1f |
|
25-Jul-2014 |
Hans de Goede <hdegoede@redhat.com> |
xhci: Blacklist using streams on the Etron EJ168 controller Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
0a939993 |
|
20-May-2014 |
Denis Turischev <denis.turischev@compulab.co.il> |
xhci: Switch only Intel Lynx Point-LP ports to EHCI on shutdown. Patch "xhci: Switch Intel Lynx Point ports to EHCI on shutdown." commit c09ec25d3684cad74d851c0f028a495999591279 is not fully correct It switches both Lynx Point and Lynx Point-LP ports to EHCI on shutdown. On some Lynx Point machines it causes spurious interrupt, which wake the system: bugzilla.kernel.org/show_bug.cgi?id=76291 On Lynx Point-LP on the contrary switching ports to EHCI seems to be necessary to fix these spurious interrupts. Signed-off-by: Denis Turischev <denis@compulab.co.il> Reported-by: Wulf Richartz <wulf.richartz@gmail.com> Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
85f4e45b |
|
14-May-2014 |
Oliver Neukum <oneukum@suse.de> |
xhci: unified loggig of RESET_ON_RESUME Either we log for all chips we set the quirk for or for none. This patch reports it for all chips. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6db249eb |
|
25-Apr-2014 |
Igor Gnatenko <i.gnatenko.brain@gmail.com> |
xhci: extend quirk for Renesas cards 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 <rfr-bugs@yandex.ru> Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Cc: stable@vger.kernel.org # 3.14 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
c09ec25d |
|
25-Apr-2014 |
Denis Turischev <denis.turischev@compulab.co.il> |
xhci: Switch Intel Lynx Point ports to EHCI on shutdown. 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 <denis@compulab.co.il> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bcffae77 |
|
03-Mar-2014 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
xhci: Prevent runtime pm from autosuspending during initialization xHCI driver has its own pci probe function that will call usb_hcd_pci_probe to register its usb-2 bus, and then continue to manually register the usb-3 bus. usb_hcd_pci_probe does a pm_runtime_put_noidle at the end and might thus trigger a runtime suspend before the usb-3 bus is ready. Prevent the runtime suspend by increasing the usage count in the beginning of xhci_pci_probe, and decrease it once the usb-3Â bus is ready. xhci-platform driver is not using usb_hcd_pci_probe to set up busses and should not need to have it's usage count increased during probe. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
14aec589 |
|
11-Feb-2014 |
Oliver Neukum <oneukum@suse.de> |
storage: accept some UAS devices if streams are unavailable On some older XHCIs streams are not supported and the UAS driver will fail at probe time. For those devices storage should try to bind to UAS devices. This patch adds a flag for stream support to HCDs and evaluates it. [Note: Sarah fixed a bug where the USB 2.0 root hub, not USB 3.0 root hub would get marked as being able to support streams.] Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
|
#
25cd2882 |
|
17-Jan-2014 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
usb/xhci: Change how we indicate a host supports Link PM. The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963adb4ad8c5f2a89ca1d99fb7bb721e7599f "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
|
#
1aa9578c |
|
17-Jan-2014 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Fix resume issues on Renesas chips in Samsung laptops Don Zickus <dzickus@redhat.com> writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Don Zickus <dzickus@redhat.com> Tested-by: Prarit Bhargava <prarit@redhat.com> Cc: stable # 2.6.37
|
#
48fc7dbd |
|
05-Dec-2013 |
Dan Williams <dan.j.williams@intel.com> |
usb: xhci: change enumeration scheme to 'new scheme' by default Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
6962d914 |
|
09-Dec-2013 |
Takashi Iwai <tiwai@suse.de> |
xhci: Limit the spurious wakeup fix only to HP machines 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 Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: <dashing.meng@gmail.com> Reported-by: Niklas Schnelle <niklas@komani.de> Reported-by: Giorgos <ganastasiouGR@gmail.com> Reported-by: <art1@vhex.net>
|
#
638298dc |
|
12-Sep-2013 |
Takashi Iwai <tiwai@suse.de> |
xhci: Fix spurious wakeups after S5 on Haswell 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 <oneukum@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
455f5892 |
|
30-Sep-2013 |
Oliver Neukum <oneukum@suse.de> |
xhci: quirk for extra long delay for S4 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 <oneukum@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
f875fdbf |
|
24-Sep-2013 |
Alan Stern <stern@rowland.harvard.edu> |
USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm field in their pci_driver structures should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. The corresponding change has already been made for ohci-hcd. Without this change, controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4bdfe4c3 |
|
05-Aug-2013 |
Xenia Ragiadakou <burzalodowa@gmail.com> |
xhci: add trace for debug messages related to quirks This patch defines a new trace event, which is called xhci_dbg_quirks and belongs in the event class xhci_log_msg, and adds tracepoints that trace the debug messages associated with xHCs' quirks. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
07f3cb7c |
|
30-Jun-2013 |
George Cherian <george.cherian@ti.com> |
usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
26b76798 |
|
23-Jul-2013 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
Intel xhci: refactor EHCI/xHCI port switching Make the Linux xHCI driver automatically try to switchover the EHCI ports to xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host. This means we will no longer have to add Intel xHCI hosts to a quirks list when the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device IDs to the quirks list is not sustainable. During suspend ports may be swicthed back to EHCI by BIOS and not properly restored to xHCI at resume. Previously both EHCI and xHCI resume functions switched ports back to XHCI, but it's enough to do it in xHCI only because the hub driver doesn't start running again until after both hosts are resumed. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
c3897aa5 |
|
18-Apr-2013 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Disable D3cold for buggy TI redrivers. Some xHCI hosts contain a "redriver" from TI that silently drops port status connect changes if the port slips into Compliance Mode. If the port slips into compliance mode while the host is in D0, there will not be a port status change event. If the port slips into compliance mode while the host is in D3, the host will not send a PME. This includes when the system is suspended (S3) or hibernated (S4). If this happens when the system is in S3/S4, there is nothing software can do. Other port status change events that would normally cause the host to wake the system from S3/S4 may also be lost. This includes remote wakeup, disconnects and connects on other ports, and overrcurrent events. A decision was made to _NOT_ disable system suspend/hibernate on these systems, since users are unlikely to enable wakeup from S3/S4 for the xHCI host. Software can deal with this issue when the system is in S0. A work around was put in to poll the port status registers for Compliance Mode. The xHCI driver will continue to poll the registers while the host is runtime suspended. Unfortunately, that means we can't allow the PCI device to go into D3cold, because power will be removed from the host, and the config space will read as all Fs. Disable D3cold in the xHCI PCI runtime suspend function. This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Huang Ying <ying.huang@intel.com> Cc: stable@vger.kernel.org
|
#
3f5eb141 |
|
19-Mar-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
usb: add find_raw_port_number callback to struct hc_driver() xhci driver divides the root hub into two logical hubs which work respectively for usb 2.0 and usb 3.0 devices. They are independent devices in the usb core. But in the ACPI table, it's one device node and all usb2.0 and usb3.0 ports are under it. Binding usb port with its acpi node needs the raw port number which is reflected in the xhci extended capabilities table. This patch is to add find_raw_port_number callback to struct hc_driver(), fill it with xhci_find_raw_port_number() which will return raw port number and add a wrap usb_hcd_find_raw_port_number(). Otherwise, refactor xhci_find_real_port_number(). Using xhci_find_raw_port_number() to get real index in the HW port status registers instead of scanning through the xHCI roothub port array. This can help to speed up. All addresses in xhci->usb2_ports and xhci->usb3_ports array are kown good ports and don't include following bad ports in the extended capabilities talbe. (1) root port that doesn't have an entry (2) root port with unknown speed (3) root port that is listed twice and with different speeds. So xhci_find_raw_port_number() will only return port num of good ones and never touch bad ports above. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
77b84767 |
|
19-Oct-2012 |
Felipe Balbi <balbi@ti.com> |
usb: host: xhci: move HC_STATE_SUSPENDED check to xhci_suspend() that check will have to be done by all users of xhci_suspend() so it sounds a lot better to move the check to xhci_suspend() in order to avoid code duplication. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
bba18e33 |
|
17-Oct-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Extend Fresco Logic MSI quirk. Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error: do_IRQ: 3.176 No irq handler for vector (irq -1) Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable. 04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 51 Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 41b1 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: A Sh <smr.ash1991@gmail.com> Tested-by: A Sh <smr.ash1991@gmail.com> Cc: stable@vger.kernel.org
|
#
80fab3b2 |
|
19-Sep-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Intel Panther Point BEI quirk. When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. If another transfer is sent (such as running `sudo lsusb -v`), the next transfer event seems to "unstick" the event ring, the xHCI driver gets an interrupt, and the disconnect is reported to the USB core. The fix is not to use the BEI flag under the Panther Point xHCI host. This will impact power consumption and system responsiveness, because the xHCI driver will receive an interrupt for every frame in all isochronous URBs instead of once per URB. Intel chipset developers confirm that this bug will be hit if the BEI flag is used on any endpoint, not just ones that are behind a hub. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
e95829f4 |
|
23-Jul-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Switch PPT ports to EHCI on shutdown. The Intel desktop boards DH77EB and DH77DF have a hardware issue that can be worked around by BIOS. 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 will work around this, but not all. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. The Intel Windows driver switches the ports back to EHCI, so change the Linux xHCI driver to do the same. Unfortunately, we can't tell the two effected boards apart from other working motherboards, because the vendors will change the DMI strings for the DH77EB and DH77DF boards to their own custom names. One example is Compulab's mini-desktop, the Intense-PC. Instead, key off the Panther Point xHCI host PCI vendor and device ID, and switch the ports over for all PPT xHCI hosts. The only impact this will have on non-effected boards is to add a couple hundred milliseconds delay on boot when the BIOS has to switch the ports over from EHCI to xHCI. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Denis Turischev <denis@compulab.co.il> Tested-by: Denis Turischev <denis@compulab.co.il> Cc: stable@vger.kernel.org
|
#
5cb7df2b |
|
02-Jul-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk. Gary reports that with recent kernels, he notices more xHCI driver warnings: xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? We think his Etron xHCI host controller may have the same buggy behavior as the Fresco Logic xHCI host. When a short transfer is received, the host will mark the transfer as successfully completed when it should be marking it with a short completion. Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron host is discovered. Note that Gary has revision 1, but if Etron fixes this bug in future revisions, the quirk will have no effect. This patch should be backported to kernels as old as 2.6.36, that contain a backported version of commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk for Fresco Logic host." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Gary E. Miller <gem@rellim.com> Cc: stable@vger.kernel.org
|
#
e3567d2c |
|
16-May-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Add Intel U1/U2 timeout policy. All Intel xHCI host controllers support USB 3.0 Link Power Management. The Panther Point xHCI host controller needs the xHCI driver to calculate the U1 and U2 timeout values, because it will blindly accept a MEL that would cause scheduling issues. The Lynx Point xHCI host controller will reject MEL values that are too high, but internally it implements the same algorithm that is needed for Panther Point xHCI. Simplify the code paths by just having the xHCI driver calculate what the U1/U2 timeouts should be. Comments on the policy are in the code. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
3b3db026 |
|
09-May-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Add infrastructure for host-specific LPM policies. The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM) is highly host controller specific. Here are a few examples of why it's host specific: 1. Setting the U1/U2 timeout too short may cause the link to go into U1/U2 in between service intervals, which some hosts may tolerate, and some may not. 2. The host controller has to modify its bus schedule in order to take into account the Maximum Exit Latency (MEL) to bring all the links from the host to the device into U0. If the MEL is too big, and it takes too long to bring the links into an active state, the host controller may not be able to service periodic endpoints in time. 3. Host controllers may also have scheduling limitations that force them to disable U1 or U2 if a USB device is behind too many tiers of hubs. We could take an educated guess at what U1/U2 timeouts may work for a particular host controller. However, that would result in a binary search on every new configuration or alt setting installation, with multiple failed Evaluate Context commands. Worse, the host may blindly accept the timeouts and just fail to update its schedule for U1/U2 exit latencies, which could result in randomly delayed periodic transfers. Since we don't want to cause jitter in periodic transfers, or delay config/alt setting changes too much, lay down a framework that xHCI vendors can extend in order to add their own U1/U2 timeout policies. To extend the framework, they will need to: - Modify the PCI init code to add a new xhci->quirk for their host, and set the XHCI_LPM_SUPPORT quirk flag. - Add their own vendor-specific hooks, like the ones that will be added in xhci_call_host_update_timeout_for_endpoint() and xhci_check_tier_policy() - Make the LPM enable/disable methods call those functions based on the xhci->quirk for their host. An example will be provided for the Intel xHCI host controller in the next patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
1530bbc6 |
|
08-May-2012 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Add new short TX quirk for Fresco Logic host. Sergio reported that when he recorded audio from a USB headset mic plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded "robotic". When plugged into the USB 2.0 port under EHCI on the same laptop, the audio sounded fine. The device is: Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset The problem was tracked down to the Fresco Logic xHCI host controller not correctly reporting short transfers on isochronous IN endpoints. The driver would submit a 96 byte transfer, the device would only send 88 or 90 bytes, and the xHCI host would report the transfer had a "successful" completion code, with an untransferred buffer length of 8 or 6 bytes. The successful completion code and non-zero untransferred length is a contradiction. The xHCI host is supposed to only mark a transfer as successful if all the bytes are transferred. Otherwise, the transfer should be marked with a short packet completion code. Without the EHCI bus trace, we wouldn't know whether the xHCI driver should trust the completion code or the untransferred length. With it, we know to trust the untransferred length. Add a new xHCI quirk for the Fresco Logic host controller. If a transfer is reported as successful, but the untransferred length is non-zero, print a warning. For the Fresco Logic host, change the completion code to COMP_SHORT_TX and process the transfer like a short transfer. This should be backported to stable kernels that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sergio Correia <lists@uece.net> Tested-by: Sergio Correia <lists@uece.net> Cc: stable@vger.kernel.org Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
457a4f61 |
|
29-Mar-2012 |
Elric Fu <elricfu1@gmail.com> |
xHCI: add XHCI_RESET_ON_RESUME quirk for VIA xHCI host The suspend operation of VIA xHCI host have some issues and hibernate operation works fine, so The XHCI_RESET_ON_RESUME quirk is added for it. This patch should base on "xHCI: Don't write zeroed pointer to xHC registers" that is released by Sarah. Otherwise, the host system error will ocurr in the hibernate operation process. This should be backported to stable kernels as old as 2.6.37, that contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add reset on resume quirk for asrock p67 host". Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
|
#
a46c46a1 |
|
16-Mar-2012 |
Gerard Snitselaar <dev@snitselaar.org> |
usb: xhci: fix section mismatch in linux-next xhci_unregister_pci() is called in xhci_hcd_init(). Signed-off-by: Gerard Snitselaar <dev@snitselaar.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
0de13500 |
|
01-Dec-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
Revert "xHCI: reset-on-resume quirk for NEC uPD720200" This reverts commit df711fc9962b9491af2b92bd0d21ecbfefe4e5fa. The commit added a reset-on-resume quirk because the NEC chipset stopped responding to commands about 30 minutes after a system resume from suspend. We thought it was a chipset issue, but it turns out that the xHCI driver was zeroing out the link TRB after a successful context restore during resume. The host controller would fall off the command ring sometime later, causing it to not respond to new commands. The link TRB issue has been fixed with commit 158886cd2cf4599e04f9b7e10cb767f5f39b14f1 "xHCI: fix bug in xhci_clear_command_ring()", so revert the reset-on-resume quirk, as it's not necessary. Commit df711fc9962b9491af2b92bd0d21ecbfefe4e5fa was marked for stable trees back to 2.6.37, but according to my mail, it has not made it into Linus' tree or the stable trees yet. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Julian Sikorski <belegdol@gmail.com> Cc: Andiry Xu <andiry.xu@amd.com>
|
#
df711fc9 |
|
16-Nov-2011 |
Andiry Xu <andiry.xu@amd.com> |
xHCI: reset-on-resume quirk for NEC uPD720200 Julian Sikorski reports NEC uPD720200 does not work stable after suspend and resume. Re-initialize the host in xhci_resume(). This should be backported to stable kernels as old as 2.6.37. The kernel will need to include commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add reset on resume quirk for asrock p67 host" for this patch to work. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Reported-by: Julian Sikorski <belegdol@gmail.com> Tested-by: Julian Sikorski <belegdol@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
6eb0de82 |
|
03-Jul-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
usb: Add module.h to drivers/usb consumers who really use it. The situation up to this point meant that module.h was pretty much everywhere, regardless of whether you asked for it or not. We are fixing that, so give the USB folks who want it an actual include of it. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
0cc47d54 |
|
23-Sep-2011 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
usb/xhci: remove CONFIG_PCI in xhci.c's probe function This removes the need of ifdefs within the init function and with it the headache about the correct clean without bus X but with bus/platform Y & Z. xhci-pci is only compiled if CONFIG_PCI is selected which can be de-selected now without trouble. For now the result is kinda useless because we have no other glue code. However, since nobody is using USB_ARCH_HAS_XHCI then it should not be an issue :) Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
552e0c4f |
|
23-Sep-2011 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
usb/xhci: move xhci_gen_setup() away from -pci. xhci_gen_setup() is generic so it can be used to perform the bare xhci setup even on non-pci based platform. The typedef for the function pointer is moved into the headerfile Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
da3c9c4f |
|
23-Sep-2011 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
usb/xhci: refactor xhci_pci_setup() xhci_pci_setup() is split into three pieces: - xhci_gen_setup() The major remaining of xhci_pci_setup() is now containing the generic part of the xhci setup. It allocates the xhci struct, setup hcs_params? and friends, performs xhci_halt(), xhci_init and so one. It also obtains the quirks via a callback - xhci_pci_quirks() It checks the origin of the xhci core and sets core specific quirks. - xhci_pci_setup() PCI specific setup functions. Besides calling xhci_gen_setup() with xhci_pci_quirks() as an argument it performs PCI specific setup like obtaining the address of sbrn via a PCI config space. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
7e393a83 |
|
23-Sep-2011 |
Andiry Xu <andiry.xu@amd.com> |
xHCI: AMD isoc link TRB chain bit quirk Setting the chain (CH) bit in the link TRB of isochronous transfer rings is required by AMD 0.96 xHCI host controller to successfully transverse multi-TRB TD that span through different memory segments. When a Missed Service Error event occurs, if the chain bit is not set in the link TRB and the host skips TDs which just across a link TRB, the host may falsely recognize the link TRB as a normal TRB. You can see this may cause big trouble - the host does not jump to the right address which is pointed by the link TRB, but continue fetching the memory which is after the link TRB address, which may not even belong to the host, and the result cannot be predicted. This causes some big problems. Without the former patch I sent: "xHCI: prevent infinite loop when processing MSE event", the system may hang. With that patch applied, system does not hang, but the host still access wrong memory address and isoc transfer will fail. With this patch, isochronous transfer works as expected. This patch should be applied to kernels as old as 2.6.36, which was when the first isochronous support was added for the xHCI host controller. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
65580b43 |
|
23-Sep-2011 |
Andiry Xu <andiry.xu@amd.com> |
xHCI: set USB2 hardware LPM If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
9574323c |
|
23-Sep-2011 |
Andiry Xu <andiry.xu@amd.com> |
xHCI: test USB2 software LPM This patch tests USB2 software LPM for a USB2 LPM-capable device. When a lpm-capable device is addressed, if the host also supports software LPM, apply a test by putting the device into L1 state and resume it to see if the device can do L1 suspend/resume successfully. If the device fails to enter L1 or resume from L1 state, it may not function normally and usbcore may disconnect and re-enumerate it. In this case, store the device's Vid and Pid information, make sure the host will not test LPM for it twice. The test result is per device/host. Some devices claim to be lpm-capable, but fail to enter L1 or resume. So the test is necessary. The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines the HIRD field to BESL, and adds another register Port Hardware LPM Control (PORTHLPMC). However, this should not affect the LPM behavior on xHC which does not implement 1.0 errata. USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension descriptor. If the device reports it uses BESL, driver should use BESL instead of HIRD for it. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b5dd18d8 |
|
07-Sep-2011 |
Yong Zhang <yong.zhang0@gmail.com> |
USB: irq: Remove IRQF_DISABLED This flag is a NOOP and can be removed now. Signed-off-by: Yong Zhang <yong.zhang0@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
86cc558e |
|
02-Sep-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Add software BW checking quirk to Intel PPT xHCI The xHCI host controller in the Intel Panther Point chipset needs to have software check whether new devices will fit in the available bus bandwidth. Activate the software bandwidth checking quirk when we find the right PCI device. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
c877b3b2 |
|
15-Jun-2011 |
Maarten Lankhorst <m.b.lankhorst@gmail.com> |
xhci: Add reset on resume quirk for asrock p67 host The asrock p67 xhci controller completely dies on resume, add a quirk for this, to bring the host back online after a suspend. This should be backported to stable kernels as old as 2.6.37. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
|
#
f5182b41 |
|
02-Jun-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Disable MSI for some Fresco Logic hosts. Some Fresco Logic hosts, including those found in the AUAU N533V laptop, advertise MSI, but fail to actually generate MSI interrupts. Add a new xHCI quirk to skip MSI enabling for the Fresco Logic host controllers. Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device ID 0x1000, regardless of PCI revision ID, do not support MSI. This should be backported to stable kernels as far back as 2.6.36, which was the first kernel to support MSI on xHCI hosts. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com> Cc: stable@kernel.org
|
#
2cf95c18 |
|
11-May-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
Intel xhci: Limit number of active endpoints to 64. The Panther Point chipset has an xHCI host controller that has a limit to the number of active endpoints it can handle. Ideally, it would signal that it can't handle anymore endpoints by returning a Resource Error for the Configure Endpoint command, but they don't. Instead it needs software to keep track of the number of active endpoints, across configure endpoint commands, reset device commands, disable slot commands, and address device commands. Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it to track the number of endpoints the xHC has active. This gets a little tricky, because commands to change the number of active endpoints can fail. This patch adds a new xHCI quirk for these Intel hosts, and the new code should not have any effect on other xHCI host controllers. Fail a new device allocation if we don't have room for the new default control endpoint. Use the endpoint ring pointers to determine what endpoints were active before a Reset Device command or a Disable Slot command, and drop those once the command completes. Fail a configure endpoint command if it would add too many new endpoints. We have to be a bit over zealous here, and only count the number of new endpoints to be added, without subtracting the number of dropped endpoints. That's because a second configure endpoint command for a different device could sneak in before we know if the first command is completed. If the first command dropped resources, the host controller fails the command for some reason, and we're nearing the limit of endpoints, we could end up oversubscribing the host. To fix this race condition, when evaluating whether a configure endpoint command will fix in our bandwidth budget, only add the new endpoints to xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore changed endpoints (ones that are dropped and then re-added), as that shouldn't effect the host's endpoint resources. When the configure endpoint command completes, subtract off the dropped endpoints. This may mean some configuration changes may temporarily fail, but it's always better to under-subscribe than over-subscribe resources. (Originally my plan had been to push the resource allocation down into the ring allocation functions. However, that would cause us to allocate unnecessary resources when endpoints were changed, because the xHCI driver allocates a new ring for the changed endpoint, and only deletes the old ring once the Configure Endpoint command succeeds. A further complication would have been dealing with the per-device endpoint ring cache.) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
ad808333 |
|
25-May-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
Intel xhci: Ignore spurious successful event. The xHCI host controller in the Panther Point chipset sometimes produces spurious events on the event ring. If it receives a short packet, it first puts a Transfer Event with a short transfer completion code on the event ring. Then it puts a Transfer Event with a successful completion code on the ring for the same TD. The xHCI driver correctly processes the short transfer completion code, gives the URB back to the driver, and then prints a warning in dmesg about the spurious event. These warning messages really fill up dmesg when an HD webcam is plugged into xHCI. This spurious successful event behavior isn't technically disallowed by the xHCI specification, so make the xHCI driver just ignore the spurious completion event. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
69e848c2 |
|
22-Feb-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
Intel xhci: Support EHCI/xHCI port switching. The Intel Panther Point chipsets contain an EHCI and xHCI host controller that shares some number of skew-dependent ports. These ports can be switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX that is controlled by registers in the xHCI PCI configuration space. The USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled separately from the USB 2.0 data wires. This switchover mechanism is there to support users who do a custom install of certain non-Linux operating systems that don't have official USB 3.0 support. By default, the ports are under EHCI, SuperSpeed terminations are off, and USB 3.0 devices will show up under the EHCI controller at reduced speeds. (This was more palatable for the marketing folks than having completely dead USB 3.0 ports if no xHCI drivers are available.) Users should be able to turn on xHCI by default through a BIOS option, but users are happiest when they don't have to change random BIOS settings. This patch introduces a driver method to switchover the ports from EHCI to xHCI before the EHCI driver finishes PCI enumeration. We want to switch the ports over before the USB core has the chance to enumerate devices under EHCI, or boot from USB mass storage will fail if the boot device connects under EHCI first, and then gets disconnected when the port switches over to xHCI. Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The PCI quirks code will run before any other PCI probe function is called, so this avoids the issue with boot devices. Another issue is with BIOS behavior during system resume from hibernate. If the BIOS doesn't support xHCI, it may switch the devices under EHCI to allow use of the USB keyboard, mice, and mass storage devices. It's supposed to remember the value of the port routing registers and switch them back when the OS attempts to take control of the xHCI host controller, but we all know not to trust BIOS writers. Make both the xHCI driver and the EHCI driver attempt to switchover the ports in their PCI resume functions. We can't guarantee which PCI device will be resumed first, so this avoids any race conditions. Writing a '1' to an already set port switchover bit or a '0' to a cleared port switchover bit should have no effect. The xHCI PCI configuration registers will be documented in the EDS-level chipset spec, which is not public yet. I have permission from legal and the Intel chipset group to release this patch early to allow good Linux support at product launch. I've tried to document the registers as much as possible, so please let me know if anything is unclear. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
7fc2a616 |
|
25-Apr-2011 |
Ben Hutchings <ben@decadent.org.uk> |
xhci-hcd: Include <linux/slab.h> in xhci-pci.c Commit b02d0ed677acb3465e7600366f2353413bf24074 ('xhci: Change hcd_priv into a pointer') added calls to kzalloc() and kfree() in xhci-pci.c. On most architectures <linux/slab.h> is indirectly included, but on some it is not. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>, Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
c41136b0 |
|
22-Mar-2011 |
Andiry Xu <andiry.xu@amd.com> |
xHCI: Implement AMD PLL quirk This patch disable the optional PM feature inside the Hudson3 platform under the following conditions: 1. If an isochronous device is connected to xHCI port and is active; 2. Optional PM feature that powers down the internal Bus PLL when the link is in low power state is enabled. The PM feature needs to be disabled to eliminate PLL startup delays when the link comes out of low power state. The performance of DMA data transfer could be impacted if system delay were encountered and in addition to the PLL start up delays. Disabling the PM would leave room for unpredictable system delays in order to guarantee uninterrupted data transfer to isochronous audio or video stream devices that require time sensitive information. If data in an audio/video stream was interrupted then erratic audio or video performance may be encountered. AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the quirk code to pci-quirks.c and export them, xHCI driver can call it directly without having the quirk implementation in itself. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
b3209379 |
|
07-Mar-2011 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Fixes for suspend/resume of shared HCDs. Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs, since it refers to whether the shared hardware is accessible. Make sure each bus is marked as suspended by setting usb_hcd->state to HC_STATE_SUSPENDED when the PCI host controller is resumed. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
f6ff0ac8 |
|
16-Dec-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Register second xHCI roothub. This patch changes the xHCI driver to allocate two roothubs. This touches the driver initialization and shutdown paths, roothub emulation code, and port status change event handlers. This is a rather large patch, but it can't be broken up, or it would break git-bisect. Make the xHCI driver register its own PCI probe function. This will call the USB core to create the USB 2.0 roothub, and then create the USB 3.0 roothub. This gets the code for registering a shared roothub out of the USB core, and allows other HCDs later to decide if and how many shared roothubs they want to allocate. Make sure the xHCI's reset method marks the xHCI host controller's primary roothub as the USB 2.0 roothub. This ensures that the high speed bus will be processed first when the PCI device is resumed, and any USB 3.0 devices that have migrated over to high speed will migrate back after being reset. This ensures that USB persist works with these odd devices. The reset method will also mark the xHCI USB2 roothub as having an integrated TT. Like EHCI host controllers with a "rate matching hub" the xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller. It doesn't really have a TT, but we'll lie and say it has an integrated TT. We need to do this because the USB core will reject LS/FS devices under a HS hub without a TT. Other details: ------------- The roothub emulation code is changed to return the correct number of ports for the two roothubs. For the USB 3.0 roothub, it only reports the USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS ports. The code to disable a port now checks the speed of the roothub, and refuses to disable SuperSpeed ports under the USB 3.0 roothub. The code for initializing a new device context must be changed to set the proper roothub port number. Since we've split the xHCI host into two roothubs, we can't just use the port number in the ancestor hub. Instead, we loop through the array of hardware port status register speeds and find the Nth port with a similar speed. The port status change event handler is updated to figure out whether the port that reported the change is a USB 3.0 port, or a non-SuperSpeed port. Once it figures out the port speed, it kicks the proper roothub. The function to find a slot ID based on the port index is updated to take into account that the two roothubs will have over-lapping port indexes. It checks that the virtual device with a matching port index is the same speed as the passed in roothub. There's also changes to the driver initialization and shutdown paths: 1. Make sure that the xhci_hcd pointer is shared across the two usb_hcd structures. The xhci_hcd pointer is allocated and the registers are mapped in when xhci_pci_setup() is called with the primary HCD. When xhci_pci_setup() is called with the non-primary HCD, the xhci_hcd pointer is stored. 2. Make sure to set the sg_tablesize for both usb_hcd structures. Set the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit DMA. (The PCI DMA mask is set from the primary HCD further down in the xhci_pci_setup() function.) 3. Ensure that the host controller doesn't start kicking khubd in response to port status changes before both usb_hcd structures are registered. xhci_run() only starts the xHC running once it has been called with the non-primary roothub. Similarly, the xhci_stop() function only halts the host controller when it is called with the non-primary HCD. Then on the second call, it resets and cleans up the MSI-X irqs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
b02d0ed6 |
|
26-Oct-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
xhci: Change hcd_priv into a pointer. Instead of allocating space for the whole xhci_hcd structure at the end of usb_hcd, make the USB core allocate enough space for a pointer to the xhci_hcd structure. This will make it easy to share the xhci_hcd structure across the two roothubs (the USB 3.0 usb_hcd and the USB 2.0 usb_hcd). Deallocate the xhci_hcd at PCI remove time, so the hcd_priv will be deallocated after the usb_hcd is deallocated. We do this by registering a different PCI remove function that calls the usb_hcd_pci_remove() function, and then frees the xhci_hcd. usb_hcd_pci_remove() calls kput() on the usb_hcd structure, which will deallocate the memory that contains the hcd_priv pointer, but not the memory it points to. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
#
5535b1d5 |
|
14-Oct-2010 |
Andiry Xu <andiry.xu@amd.com> |
USB: xHCI: PCI power management implementation This patch implements the PCI suspend/resume. Please refer to xHCI spec for doing the suspend/resume operation. For S3, CSS/SRS in USBCMD is used to save/restore the internal state. However, an error maybe occurs while restoring the internal state. In this case, it means that HC internal state is wrong and HC will be re-initialized. Signed-off-by: Libin Yang <libin.yang@amd.com> Signed-off-by: Dong Nguyen <dong.nguyen@amd.com> Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
9777e3ce |
|
14-Oct-2010 |
Andiry Xu <andiry.xu@amd.com> |
USB: xHCI: bus power management implementation This patch implements xHCI bus suspend/resume function hook. In the patch it goes through all the ports and suspend/resume the ports if needed. If any port is in remote wakeup, abort bus suspend as what ehci/ohci do. Signed-off-by: Libin Yang <libin.yang@amd.com> Signed-off-by: Crane Cai <crane.cai@amd.com> Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f0615c45 |
|
14-Oct-2010 |
Andiry Xu <andiry.xu@amd.com> |
USB: xHCI: change xhci_reset_device() to allocate new device Rename xhci_reset_device() to xhci_discover_or_reset_device(). If xhci_discover_or_reset_device() is called to reset a device which does not exist or does not match the udev, it calls xhci_alloc_dev() to re-allocate the device. This would prevent the reset device failure, possibly due to the xHC restore error during S3/S4 resume. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
006d5820 |
|
29-Jul-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Set DMA mask for host. Tell the USB core that we can do DMA directly (instead of needing it to memory-map the buffers for PIO). If the xHCI host supports 64-bit addresses, set the DMA mask accordingly. Otherwise indicate the host can handle 32-bit DMA addresses. This improves performance because the USB core doesn't have to spend time remapping buffers in high memory into the 32-bit address range. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
0238634d |
|
24-May-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Print NEC firmware version. The NEC xHCI host controller firmware version can be found by putting a vendor-specific command on the command ring and extracting the BCD encoded-version out of the vendor-specific event TRB. The firmware version debug line in dmesg will look like: xhci_hcd 0000:05:00.0: NEC firmware version 30.21 (NEC merged with Renesas Technologies and became Renesas Electronics on April 1, 2010. I have their OK to merge this vendor-specific code.) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Satoshi Otani <satoshi.otani.xm@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
326b4810 |
|
19-Apr-2010 |
Randy Dunlap <randy.dunlap@oracle.com> |
USB: clean up some host controller sparse warnings Fix usb sparse warnings: drivers/usb/host/isp1362-hcd.c:2220:50: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:43:24: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:49:24: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:161:24: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:198:16: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:319:31: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:1231:33: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-pci.c:177:23: warning: non-ANSI function declaration of function 'xhci_register_pci' drivers/usb/host/xhci-pci.c:182:26: warning: non-ANSI function declaration of function 'xhci_unregister_pci' drivers/usb/host/xhci-ring.c:342:32: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:525:34: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:1009:32: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:1031:32: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:1041:16: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:1096:30: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-ring.c:1100:27: warning: Using plain integer as NULL pointer drivers/usb/host/xhci-mem.c:224:27: warning: symbol 'xhci_alloc_container_ctx' was not declared. Should it be static? drivers/usb/host/xhci-mem.c:242:6: warning: symbol 'xhci_free_container_ctx' was not declared. Should it be static? Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Lothar Wassmann <LW@KARO-electronics.de> Signed-off By: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
eab1cafc |
|
05-Apr-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: Support for allocating USB 3.0 streams. Bulk endpoint streams were added in the USB 3.0 specification. Streams allow a device driver to overload a bulk endpoint so that multiple transfers can be queued at once. The device then decides which transfer it wants to work on first, and can queue part of a transfer before it switches to a new stream. All this switching is invisible to the device driver, which just gets a completion for the URB. Drivers that use streams must be able to handle URBs completing in a different order than they were submitted to the endpoint. This requires adding new API to set up xHCI data structures to support multiple queues ("stream rings") per endpoint. Drivers will allocate a number of stream IDs before enqueueing URBs to the bulk endpoints of the device, and free the stream IDs in their disconnect function. See Documentation/usb/bulk-streams.txt for details. The new mass storage device class, USB Attached SCSI Protocol (UASP), uses these streams API. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
bc88d2eb |
|
18-May-2010 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Limit bus sg_tablesize to 62 TRBs. When a scatter-gather list is enqueued to the xHCI driver, it translates each entry into a transfer request block (TRB). Only 63 TRBs can be used per ring segment, and there must be one additional TRB reserved to make sure the hardware does not think the ring is empty (so the enqueue pointer doesn't equal the dequeue pointer). Limit the bus sg_tablesize to 62 TRBs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
a5f0efab |
|
09-Dec-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: Add call to notify xHC of a device reset. Add a new host controller driver method, reset_device(), that the USB core will use to notify the host of a successful device reset. The call may fail due to out-of-memory errors; attempt the port reset sequence again if that happens. Update hub_port_init() to allow resetting a configured device. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4c1bd3d7 |
|
24-Aug-2009 |
David Vrabel <david.vrabel@csr.com> |
USB: make urb scatter-gather support more generic The WHCI HCD will also support urbs with scatter-gather lists. Add a usb_bus field to indicated how many sg list elements are supported by the HCD. Use this to decide whether to pass the scatter-list to the HCD or not. Make the usb-storage driver use this new field. Signed-off-by: David Vrabel <david.vrabel@csr.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
b356b7c7 |
|
04-Sep-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: Add hub descriptor update hook for xHCI Add a hook for updating xHCI internal structures after khubd fetches the hub descriptor and sets up the hub's TT information. The xHCI driver must update the internal structures before devices under the hub can be enumerated. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ac1c1b7f |
|
04-Sep-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Support USB hubs. For a USB hub to work under an xHCI host controller, the xHC's internal scheduler must be made aware of the hub's characteristics. Add an xHCI hook that the USB core will call after it fetches the hub descriptor. This hook will add hub information to the slot context for that device, including whether it has multiple TTs or a single TT, the number of ports on the hub, and TT think time. Setting up the slot context for the device is different for 0.95 and 0.96 xHCI host controllers. Some of the slot context reserved fields in the 0.95 specification were changed into hub fields in the 0.96 specification. Don't set the TT think time or number of ports for a hub if we're dealing with a 0.95-compliant xHCI host controller. The 0.95 xHCI specification says that to modify the hub flag, we need to issue an evaluate context command. The 0.96 specification says that flag can be set with a configure endpoint command. Issue the correct command based on the version reported by the hardware. This patch does not add support for multi-TT hubs. Multi-TT hubs expose a single TT on alt setting 0, and multi-TT on alt setting 1. The xHCI driver can't handle setting alternate interfaces yet. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
ac9d8fe7 |
|
07-Aug-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Add quirk for Fresco Logic xHCI hardware. This Fresco Logic xHCI host controller chip revision puts bad data into the output endpoint context after a Reset Endpoint command. It needs a Configure Endpoint command (instead of a Set TR Dequeue Pointer command) after the reset endpoint command. Set up the input context before issuing the Reset Endpoint command so we don't copy bad data from the output endpoint context. The HW also can't handle two commands queued at once, so submit the TRB for the Configure Endpoint command in the event handler for the Reset Endpoint command. Devices that stall on control endpoints before a configuration is selected will not work under this Fresco Logic xHCI host controller revision. This patch is for prototype hardware that will be given to other companies for evaluation purposes only, and should not reach consumer hands. Fresco Logic's next chip rev should have this bug fixed. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
a1587d97 |
|
27-Jul-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Deal with stalled endpoints. When an endpoint on a device under an xHCI host controller stalls, the host controller driver must let the hardware know that the USB core has successfully cleared the halt condition. The HCD submits a Reset Endpoint Command, which will clear the toggle bit for USB 2.0 devices, and set the sequence number to zero for USB 3.0 devices. The xHCI urb_enqueue will accept new URBs while the endpoint is halted, and will queue them to the hardware rings. However, the endpoint doorbell will not be rung until the Reset Endpoint Command completes. Don't queue a reset endpoint command for root hubs. khubd clears halt conditions on the roothub during the initialization process, but the roothub isn't a real device, so the xHCI host controller doesn't need to know about the cleared halt. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
f94e0186 |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Bandwidth allocation support Since the xHCI host controller hardware (xHC) has an internal schedule, it needs a better representation of what devices are consuming bandwidth on the bus. Each device is represented by a device context, with data about the device, endpoints, and pointers to each endpoint ring. We need to update the endpoint information for a device context before a new configuration or alternate interface setting is selected. We setup an input device context with modified endpoint information and newly allocated endpoint rings, and then submit a Configure Endpoint Command to the hardware. The host controller can reject the new configuration if it exceeds the bus bandwidth, or the host controller doesn't have enough internal resources for the configuration. If the command fails, we still have the older device context with the previous configuration. If the command succeeds, we free the old endpoint rings. The root hub isn't a real device, so always say yes to any bandwidth changes for it. The USB core will enable, disable, and then enable endpoint 0 several times during the initialization sequence. The device will always have an endpoint ring for endpoint 0 and bandwidth allocated for that, unless the device is disconnected or gets a SetAddress 0 request. So we don't pay attention for when xhci_check_bandwidth() is called for a re-add of endpoint 0. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
d0e96f5a |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Control transfer support. Allow device drivers to enqueue URBs to control endpoints on devices under an xHCI host controller. Each control transfer is represented by a series of Transfer Descriptors (TDs) written to an endpoint ring. There is one TD for the Setup phase, (optionally) one TD for the Data phase, and one TD for the Status phase. Enqueue these TDs onto the endpoint ring that represents the control endpoint. The host controller hardware will return an event on the event ring that points to the (DMA) address of one of the TDs on the endpoint ring. If the transfer was successful, the transfer event TRB will have a completion code of success, and it will point to the Status phase TD. Anything else is considered an error. This should work for control endpoints besides the default endpoint, but that hasn't been tested. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3ffbba95 |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
0f2a7930 |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: Root hub support. Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
7f84eef0 |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
66d4eadd |
|
27-Apr-2009 |
Sarah Sharp <sarah.a.sharp@linux.intel.com> |
USB: xhci: BIOS handoff and HW initialization. Add PCI initialization code to take control of the xHCI host controller away from the BIOS, halt, and reset the host controller. The xHCI spec says that BIOSes must give up the host controller within 5 seconds. Add some host controller glue functions to handle hardware initialization and memory allocation for the host controller. The current xHCI prototypes use PCI interrupts, but the xHCI spec requires MSI-X interrupts. Add code to support MSI-X interrupts, but use the PCI interrupts for now. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|