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.
1. 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.
2. 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
