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: <2a8d65f4-6832-49c5-9d61-f8c0d0552ed4@aosc.io>
Date: Tue, 4 Feb 2025 00:01:37 +0800
From: Mingcong Bai <jeffbai@...c.io>
To: Alan Stern <stern@...land.harvard.edu>,
 Huacai Chen <chenhuacai@...nel.org>
Cc: 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, 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:

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.

Best Regards,
Mingcong Bai

> Alan Stern
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ