linux-kernel - Re: [PATCH] USB: core: Enable root_hub's remote wakeup for wakeup sources

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <06c81c97-7e5f-412b-b6af-04368dd644c9@rowland.harvard.edu>
Date: Mon, 3 Feb 2025 11:15:08 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Mingcong Bai <jeffbai@...c.io>
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

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?

> 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