On Tue, Sep 21, 2021 at 06:16:43PM -0700, Jack Pham wrote:
On Thu, Mar 11, 2021 at 01:53:51PM +0200, Mathias Nyman wrote:
A xHC USB 3 port might miss the first wake signal from a USB 3 device if the port LFPS reveiver isn't enabled fast enough after xHC resume.
xHC host will anyway be resumed by a PME# signal, but will go back to suspend if no port activity is seen. The device resends the U3 LFPS wake signal after a 100ms delay, but by then host is already suspended, starting all over from the beginning of this issue.
USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device needs to delay 100ms before resending the wake.
Don't suspend immediately if port activity isn't detected in resume. Instead add a retry. If there is no port activity then delay for 120ms, and re-check for port activity.
We have a use case with which this change is causing unnecessary delay. Consider a USB2* device is attached and host is initiating the resume. Since this is not a device initiated wakeup there wouldn't be any pending event seen on the PORTSC registers, yet this adds an additional 120ms delay to re-check the PORTSC before returning and allowing the USB core to perform resume signaling.
Is there a way to avoid this delay in that case? Perhaps could we distinguish whether we arrive here at xhci_resume() due to a host-initiated resume vs. a device remote wakeup?
Do you have a proposed patch that would do such a thing? Given that you are seeing the problem it should be easy for you to test :)
- I think it should be similar for attached USB3 devices as well, since
the host-initiated exit from U3 wouldn't happen until usb_port_resume().
Can you reliably detect "attached" devices?