Hi Alan,
在 2025/2/4 00:15, Alan Stern 写道:
On Tue, Feb 04, 2025 at 12:01:37AM +0800, Mingcong Bai wrote:
Hi Alan, Huacai,
<snip>
I just tried running the experiment on my system. I enabled wakeup for the mouse device, made sure it was disabled for the intermediate hub and the root hub, and made sure it was enabled for the host controller. (Those last three are the default settings.) Then I put the system in S3 suspend by writing "mem" to /sys/power/state, and when the system was asleep I pressed one of the mouse buttons -- and the system woke up. This was done under a 6.12.10 kernel, with an EHCI host controller, not xHCI.
So it seems like something is wrong with your system in particular, not the core USB code in general. What type of host controller is your mouse attached to? Have you tested whether the mouse is able to wake up from runtime suspend, as opposed to S3 suspend?
Just to chime in with my own test results. I was looking at this with Huacai a few days back and we suspected that this had something to do with particular systems, as you have found; we also suspected that if a keyboard was connected to a non-xHCI controller, it would fail to wake up the system.
I conducted a simple experiment on my Lenovo ThinkPad X200s, which does not come with any USB 3.0 port. Here are my findings:
What sort of USB controller does the X200s have? Is the controller enabled for wakeup?
What happens with runtime suspend rather than S3 suspend?
It has the Intel Corporation 82801I (ICH9 Family) USB UCHI/USB2 EHCI controller with PCI IDs 17aa:20f0/17aa:20f1. The hub is a Genesys Logic, Inc. Hub with an ID of 05e3:0610 - this is an xHCI hub.
Sorry but the record here is going to get a bit messy... But let's start with a kernel with Huacai's patch.
=== Kernel + Huacai's Patch ===
1. If I plug in the external keyboard via the hub, /sys/bus/usb/devices/usb1, power/state is set to enabled. For the hub, corresponding to usb1/1-1, power/wakeup is set to disabled.
2. If I plug the keyboard directly into the chassis, usb1/power/wakeup is set to disabled, but usb1/1-1/power/wakeup is set to enabled.
The system wakes up via external keyboard plugged directly into the chassis **or** the hub either way, regardless if I used S3 or runtime suspend (which I assume to be echo freeze > /sys/power/state).
=== Kernel w/o Huacai's Patch ===
The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and the hub, corresponding to usb1/1-1, their power/wakeup entries are both set to disabled. Same for when I have the patch applied.
However, if I plug the external keyboard into the chassis, it would fail to wakeup regardless of S3/runtime suspend (freeze). If I plug the external keyboard via that USB Hub though, it would wake up the machine. The findings are consistent between S3/freeze.
- With upstream code, the system would not wake up with neither the
internal nor the external keyboards. One exception being the Fn key on the internal keyboard, which would wake up the system (but I suspect that this is EC behaviour). This behaviour is consistent across any USB port on the laptop and, regardless if the external keyboard was connected to the laptop itself or via a hub.
- With Huacai's code, I was able to wake up the laptop with an external
keyboard in all the scenarios listed in (1). The internal keyboard still failed to wake up the system unless I strike the Fn key.
I should note, however, that the internal keyboard is not connected via USB so it's probably irrelevant information anyway.
As for mice, it seems that the kernel disables wake-up via USB mice and enables wake-up via USB keyboards. This is also consistent with your findings.
Yes, and of course you can manually change the default wakeup settings whenever you want.
Alan Stern
Best Regards, Mingcong Bai