On Sun, Feb 2, 2025 at 12:55 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. OK, I'm glad to see a better solution. :) Huacai > > Alan Stern
