Le mar. 24 sept. 2019 à 09:55, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> a écrit : > Just fyi, turns out initial xHCI 1.1 spec was a bit unclear about SBRN > and minor revision numbers, later xHCI specs clarify them better. > A few USB 3.1 capable xHCI hosts were based on that spec, not just the ASM2142. > They have SBRN set to 30h and minor revision 0x1. > I'll send a patch to detect those correctly. > > But it won't fix your inconsistency with PortSpeed bits in PORTSC register. Do you know anything I could try do debug the problem if it happens again ? > > > > > Btw, I found another problem on resuming the system after a suspend : > > [ 137.029272] pcieport 0000:00:01.1: PME: Spurious native interrupt! > > ... > > [ 137.129618] xhci_hcd 0000:08:00.0: WARN: xHC restore state timeout > > [ 137.129624] xhci_hcd 0000:08:00.0: PCI post-resume error -110! > > [ 137.129625] xhci_hcd 0000:08:00.0: HC died; cleaning up > > [ 137.129633] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110 > > [ 137.129636] PM: Device 0000:08:00.0 failed to resume async: error -110 > > Then a "echo 1 > remove, then "echo 1 > ../rescan" on sysfs got it back. > > This is a completely different issue, but at least, I can reproduce > > this one reliably. > > > > Looks like the xHCI PCI controller wasn't fully powered up to D0 state yet > when xhci_resume was called. Looks similar to what is discussed in thread: > > https://marc.info/?l=linux-usb&m=156681068319529&w=2 In the runtime suspend case, on this laptop the xhci is stuck in D3, where in my case it stays in D0. I tried https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@xxxxxxxxxxxxxxx/, but it doesn't help. On my machine, the PCIe "port" is supposed to support 8GT/s (but the controller is on the motherboard, so there is no official specification about how the internal peripherals are linked), the device too, but it's always in 5GT/s mode (in Windows too), so perhaps it changes the delays.
