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

- Ross

Reply via email to