Re: [PATCH 2/4] xhci: Improve detection of device initiated wake signal.

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Sep 21, 2021 at 06:16:43PM -0700, Jack Pham wrote:
> Hi Mathias,
> 
> 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?

thanks,

greg k-h