Hi, I'm hitting an issue on a Broadwell based Chromebox that appears to be related to the XHCI_SPURIOUS_WAKEUP quirk. Here are the reproduction steps: 1) Start with a fully booted system on a recent kernel. I've been testing with v5.4-rc4. 2) Gracefully shut down the system, either with 'halt -p' or by pushing the power button. This causes the XHCI_SPURIOUS_WAKEUP quirk to be applied on shutdown via xhci_shutdown(). 3) Quickly (within a few seconds) restart the system using the power button. 4) After the system restarts, we end up in a state where USB 2.0 devices work fine, but all USB 3.X devices don't work at all. The kernel never sees them being inserted, we never call usb_new_device() or any other USB related kernel code. This state persists for the duration of the boot on all ports for the internal USB 3.0 hub, and is independent of which devices were plugged into the hub during boot. Attaching a USB analyzer between the USB hub and the USB 3.0 device, I see that the hub sees the device insertion, but disables SuperSpeed. >From then on all the USB analyzer sees is garbage, and the connection never successfully drops down to USB 2.0. Disabling the above mentioned quirk prevents this from happening, and it also doesn't happen if the system is warm rebooted or if the system is left off for a longer period of time (~10 seconds or more) before powering back on. So, a few questions: 1) I'm running on a Chromebox using Coreboot. Does anyone have a BIOS-based BDW system to see if they can reproduce it there? 2) What is the appropriate way to deal with this issue? From looking at the history of the quirk, it looks like it was put in for good reasons and that it still needs to be there for other systems. Assuming other vendors' systems don't reproduce the above issue, should I just exclude Google made systems from the quirk? Something else? Thanks, - Ross
