linux-kernel - Re: [PATCH] [RFC] usb: host: Allow userspace to control usb suspend flows

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: <0e4221b5-bafe-4bea-b533-0ed8add81ef1@rowland.harvard.edu>
Date: Tue, 30 Jan 2024 12:12:19 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Guan-Yu Lin <guanyulin@...gle.com>
Cc: gregkh@...uxfoundation.org, mathias.nyman@...el.com, royluo@...gle.com,
  hadess@...ess.net, benjamin.tissoires@...hat.com,
  heikki.krogerus@...ux.intel.com, oneukum@...e.com, grundler@...omium.org,
  yajun.deng@...ux.dev, dianders@...omium.org, linux-kernel@...r.kernel.org,
  linux-usb@...r.kernel.org, badhri@...gle.com, albertccwang@...gle.com,
  pumahsu@...gle.com
Subject: Re: [PATCH] [RFC] usb: host: Allow userspace to control usb suspend
 flows

On Tue, Jan 30, 2024 at 06:47:13AM +0000, Guan-Yu Lin wrote:
> In a system with sub-system engaged, the controllers are controlled by

What is a sub-system and how does it become engaged?

> both the main processor and the co-processor. Chances are when the main
> processor decides to suspend the USB device, the USB device might still
> be used by the co-processor. In this scenario, we need a way to let
> system know whether it can suspend the USB device or not. We introduce a
> new sysfs entry "deprecate_device_pm" to allow userspace to control the
> device power management functionality on demand. As the userspace should
> possess the information of both the main processor and the co-processor,
> it should be able to address the conflict mentioned above.

This description and the comments and documentation in the patch all
talk about "device power management".  But in fact the patch only
affects system power management; it does not affect runtime power
management.

Also, "deprecate_device_pm" does not seem like a very good name.
You're not deprecating power management; you're just disabling it
temporarily.  You should find a better name.

Do you really want your new flag to affect device suspend during
hibernation?  Does the co-processor remain powered when the system is
powered off and unplugged?

Do you really want the new sysfs flag to be present even on systems
that don't have a co-processor?

Why does this affect only the USB subsystem?  Can't the co-processor
use other, non-USB, devices on the system?

Alan Stern