Comment # 12 on bug 1206758 from Oliver Neukum

(In reply to Pablo Sanchez from comment #10)
> (In reply to Oliver Neukum from comment #8)
> > The failure you are seeing is on the PCI level. From your logs it is unclear
> > whether the HC that fails to resume is hosting other busses. It is possible
> > that it is just not resumed without a device.
> 
> Hi,
> 
> My work-around is to resume, *then* connect the device.

Sorry, this probably needs a long explanation.

From usbcore's viewpoint your roothub on the XHCI without any device connected
to it will be in the state (suspended w. remote wakeup) after your system
resumes that is the desired state of the root hub, too. So without devices if
your system is suspended, no PM transitions will be done on the roothub.

If, however, your system is connected to your phone, the roothub and the phone
need to be in (active) before and after the system sleeps. So PM transitions
are certainly done.

My theory was that your system is generally incapable of a PM transition on the
PCI level at that time.
If that theory were true, your system should crash with any device that is in
(active) attached and it should also crash if you artificially force the
roothub into a PM transition on resume, which was my second suggestion.

> 
> > Do you have other devices to test to make sure it is not specific to your
> > phone? 
> 
> What an excellent idea.  As my phone is a Samsung S21, non-root, I hadn't
> thought it might be an issue.
> 
> Using another phone (OnePlus Nord), it works.

Please attach the output of "lsusb -v" in the working state with that second
phone connected.

> > Alternatively, if not, it would be necessary to set the "control"
> > attribute for your root hub to "on".
> 
> I think you're saying a work-around is for me to create a udev rule.  

No, that was for testing purposes only.
Something is failing on the PCI level. You cannot fix that with a udev rule.
So please test whether the fault is related to ASPM by doing Takashi's test.

From your log:

[26232.379255] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold
to D0, device inaccessible
[26232.457787] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold
to D0, device inaccessible

These must not happen. If they do, everything after that is as expected, though
not as desired. Unfortunately everything before them is as it should be. Hence
tests to determine the cause of this issue are needed.