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
