Message-ID: <6838de5f-2984-4722-9ee5-c4c62d13911b@aosc.io>
Date: Wed, 5 Feb 2025 13:59:24 +0800
From: Mingcong Bai <jeffbai@...c.io>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Huacai Chen <chenhuacai@...nel.org>, Huacai Chen
 <chenhuacai@...ngson.cn>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org, Kexy Biscuit <kexybiscuit@...c.io>
Subject: Re: [PATCH] USB: core: Enable root_hub's remote wakeup for wakeup
 sources

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

Powered by blists - more mailing lists