Re: [PATCH] USB: core: Enable root_hub's remote wakeup for wakeup sources

[Alan Stern]

On Sat, Feb 01, 2025 at 02:42:43PM +0800, Huacai Chen wrote:
> Hi, Alan,
> 
> On Fri, Jan 31, 2025 at 11:17 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jan 31, 2025 at 06:06:30PM +0800, Huacai Chen wrote:
> > > Now we only enable the remote wakeup function for the USB wakeup source
> > > itself at usb_port_suspend(). But on pre-XHCI controllers this is not
> > > enough to enable the S3 wakeup function for USB keyboards,
> >
> > Why do you say this?  It was enough on my system with an EHCI/UHCI
> > controller when I wrote that code.  What hardware do you have that isn't
> > working?
> >
> > >  so we also
> > > enable the root_hub's remote wakeup (and disable it on error). Frankly
> > > this is unnecessary for XHCI, but enable it unconditionally make code
> > > simple and seems harmless.
> >
> > This does not make sense.  For hubs (including root hubs), enabling
> > remote wakeup means that the hub will generate a wakeup request when
> > there is a connect, disconnect, or over-current change.  That's not what
> > you want to do, is it?  And it has nothing to do with how the hub
> > handles wakeup requests received from downstream devices.
> >
> > You need to explain what's going on here in much more detail.  What
> > exactly is going wrong, and why?  What is the hardware actually doing,
> > as compared to what we expect it to do?
> OK, let me tell a long story:
> 
> At first, someone reported that on Loongson platform we cannot wake up
> S3 with a USB keyboard, but no problem on x86. At that time we thought
> this was a platform-specific problem.
> 
> After that we have done many experiments, then we found that if the
> keyboard is connected to a XHCI controller, it can wake up, but cannot
> wake up if it is connected to a non-XHCI controller, no matter on x86
> or on Loongson. We are not familiar with USB protocol, this is just
> observed from experiments.
> 
> You are probably right that enabling remote wakeup on a hub means it
> can generate wakeup requests rather than forward downstream devices'
> requests. But from experiments we found that if we enable the "wakeup"
> knob of the root_hub via sysfs, then a keyboard becomes able to wake
> up S3 (for non-XHCI controllers). So we guess that the enablement also
> enables forwarding. So maybe this is an implementation-specific
> problem (but most implementations have problems)?
> 
> This patch itself just emulates the enablement of root_hub's remote
> wakeup automatically (then we needn't operate on sysfs).

I'll run some experiments on my system.  Maybe you're right about the 
problem, but your proposed solution looks wrong.

Alan Stern