Re: [PATCH 2/2] xhci: drop 120ms U3 LFPS wake retry wait from runtime resume

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 8/31/26 22:03, Lovekesh Solanki wrote:
> On auto resume (is_auto_resume), xhci_resume() used to msleep(120)
> when there were suspended USB3 devices and no pending port event,
> to give USB3 devices time to resend their U3 LFPS wake (at 100ms
> intervals) if the first wake signalling failed.
> 
> The hub driver now holds the SS root hub awake for
> USB_SS_ROOT_HUB_U0_WAKE_TIME (120ms) after a resume, which covers that
> same window and lets the pending port event be picked up through the
> normal hub event path. Therefore, this legacy wait in xhci_resume()
> is redundant and can be removed.

I looked into this again and remember now why we didn't remove the msleep(120)
earlier.

If we want the hub driver to keep us awake to detect delayed port activity,
then we need to wake the (root) hub driver in xhci resume.

That means always calling usb_hcd_resume_root_hub() in runtime resume cases where
resume is caused by usb device remote wake. (xHCI PME# in PCI case), even if there
isn't any port activity yet.

We don't currently check if runtime resume is caused by xHC PME# wake in the xhci-pci
driver. Not sure if there's a driver api for it.
Instead we in resume sleep for 120ms if there exists connected and suspended USB3
devices without port activity, and then check again.

This msleep(120) is unnecessary if runtime resume was caused by userspace instead
of usb device initiated wake (seen as PME for PCI hosts)

Probably best to just take Patch 1/1 and look at this xhci resume part separately.

Thanks
Mathias