linux-kernel - Re: [PATCH] usb: host: enable suspend-to-RAM control in userspace

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]

Date: Fri, 2 Feb 2024 16:51:06 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Guan-Yu Lin <guanyulin@...gle.com>, gregkh@...uxfoundation.org,
 mathias.nyman@...el.com, stern@...land.harvard.edu, royluo@...gle.com,
 benjamin.tissoires@...hat.com, hadess@...ess.net,
 heikki.krogerus@...ux.intel.com, grundler@...omium.org, oneukum@...e.com,
 dianders@...omium.org, yajun.deng@...ux.dev
Cc: linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
 USB <linux-usb@...r.kernel.org>, Linux PM list <linux-pm@...r.kernel.org>,
 "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH] usb: host: enable suspend-to-RAM control in userspace

On 2.2.2024 10.42, Guan-Yu Lin wrote:
> In systems with both a main processor and a co-processor, asynchronous
> controller management can lead to conflicts. For example, the main
> processor might attempt to suspend a USB device while the co-processor
> is actively transferring data. To address this, we introduce a new
> sysfs entry, "disable_suspend2ram", which allows userspace to control
> the suspend-to-RAM functionality of devices on a specific USB bus.
> Since the userspace has visibility into the activities of both
> processors, it can resolve potential conflicts.
> 
> Signed-off-by: Guan-Yu Lin <guanyulin@...gle.com>
> ---

Doesn't setting this new disable_suspend2ram break system suspend on all
other systems except this one?

On any system with a PCI xHC we end up trying to suddenly stop the xHC
host with all connected usb devices still fully up and running.

In the xhci platform device case again nothing will be stopped or suspended,
but PM framework assumes everything is suspended correctly.

So then xHC either continues running and generates interrupts, or it might
be abruptly powered off if the bus above it suspends.
(For example if the xhci platform device is created by a PCI DWC3, and it
goes to D3 state)

EHCI and other hosts face similar issues with trying to suspend the
controller when the devices connected to it are fully up and running.

To me it looks like this whole co-processor case needs to be developed and
designed into the pm framework

Thanks
Mathias