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] [day] [month] [year] [list]
Message-ID: <6363c5ba-c576-42a8-8a09-31d55768618c@rowland.harvard.edu>
Date: Wed, 5 Feb 2025 13:25:27 -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 Wed, Feb 05, 2025 at 01:59:24PM +0800, Mingcong Bai wrote:
> 在 2025/2/4 00:15, Alan Stern 写道:
> > 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

UHCI, not UCHI.

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

There is no such thing as an xHCI hub -- xHCI is a host controller 
technology, not a hub technology.  Perhaps you mean that it is a USB-3 
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,

/sys/bus/usb/devices/usb1 is the root hub, which is an emulated device 
that is closely tied to the host controller.  The external Genesys Logic 
hub is /sys/bus/usb/devices/1-1.

>  power/state is set to enabled. For the hub,

You mean power/wakeup, not power/state.  In fact, there is no 
power/state file for USB devices in sysfs.

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

Why is usb1/power/wakeup set to disabled?  Doesn't Huacai's patch set it 
to enabled?

Is 1-1 the keyboard device?  That is, did you plug the keyboard into the 
port that the Genesys Logic hub was using previously?

> 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).

No.  Runtime suspend has no relation to /sys/power.  It is controlled by 
/sys/bus/usb/devices/.../power/control.  If you write "auto" to this 
file for the device and for all the hubs above it (including the root 
hub) then they will be put into runtime suspend a few seconds after you 
stop using them, assuming no other USB devices are plugged into the same 
hubs.

> === Kernel w/o Huacai's Patch ===
> 
> The controller where I plugged in the USB hub, /sys/bus/usb/devices/usb1 and

/sys/bus/usb/devices/usb1 is the root hub, not the controller.  The two 
are related but they are not the same thing.  The controller is the 
parent device of the root hub; it lies under /sys/bus/pci/devices/.

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

This means there's something different between the way the keyboard 
sends its wakeup signal and the way the Genesys Logic hub sends its 
wakeup signal.

Can you post the output from "lsusb -t" for this system?

Also, can you enable dynamic debugging for usbcore by doing:

	echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control

and then post the dmesg log for a suspend/resume cycle?

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ