Going back to February there was a bug report around the xHCI controller dieing on resume from s2idle when using an AMD Ryzen AI Max+ "Strix Halo" Framework Desktop. In turn all USB devices behind the xHCI controller are lost on resume, but unbinding and binding the driver can restore the functionality without a reboot. After months of back and forth communication, it looks like a solution has been figured out and comes down to a nuance of the PCI spec with needing a brief wait.

Framework Computer originally reported this Linux kernel bug that customer(s) experienced. AMD Linux engineer Mario Limonciello ultimately devised a patch that appears to properly address this scenario of the xHCI controller being lost on resume for some hardware.

The PCI specification outlines a minimum recovery time between programming a function from D3 to D0 and accessing it. That is a 10ms delay outlined in the PCI specification. But the Linux kernel doesn't have any mandatory delays in the D3cold path but only for D3hot. With the now-pending Linux kernel patch, a 10ms delay is ensured on the D3cold path and in turn it looks to resolve this issue.

Limonciello explained on the kernel mailing list :

"An issue has been reported that xHCI host controller doesn't come back from resume on some systems. This issue has a failure rate, but that failure rate is confusingly tied to the size of the VRAM reservation that the BIOS makes.

That is if the VRAM reservation is small (for example 512MB) then no failures. There are some comments that mention that the larger the VRAM size the higher the failure rate. I personally don't really understand why this would matter, but I would like to mention it in case it jogs anyone else's brain.

Various workarounds work:
* Using legacy interrupts instead of MSI
* Resetting controller on resume
* Creating device link dependency between XHCI and display PCI devices (for device resume ordering)

None of those workarounds appear to get at the root of the problem to me though.

I did some tracing around the code and cross referenced the PCI spec. The XHCI controller should be in D3cold during suspend and thus should go through a D3->D0 transition. The PCI spec says that D3 transitions need 10ms delay.

However we don't have any mandatory delays for endpoints in D3cold, only bridges have this. For endpoints we only have mandatory delays in D3hot.

So my suspicion is that adding a mandatory delay for the D3cold to D0 transition will help this issue, which is what this patch series does."

This patch affects just the common Linux PCI driver code. Judging from this kernel.org bug report that has been tracking the problem since February, it does appear that the patch fixes the issue on at least the Framework Desktop.