Received-SPF: pass (google.com: domain of linux-kernel+bounces-47821-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240130064819.1362642-1-guanyulin@google.com> <0e4221b5-bafe-4bea-b533-0ed8add81ef1@rowland.harvard.edu>
In-Reply-To: <0e4221b5-bafe-4bea-b533-0ed8add81ef1@rowland.harvard.edu>
From: Guan-Yu Lin <guanyulin@google.com>
Date: Thu, 1 Feb 2024 17:02:00 +0800
Message-ID: <CAOuDEK2VSBcQdLKt27VrLUxH2S22275ffbe5mdVM=vBZDhceQA@mail.gmail.com>
Subject: Re: [PATCH] [RFC] usb: host: Allow userspace to control usb suspend flows
To: Alan Stern <stern@rowland.harvard.edu>
Cc: gregkh@linuxfoundation.org, mathias.nyman@intel.com, royluo@google.com, 
	hadess@hadess.net, benjamin.tissoires@redhat.com, 
	heikki.krogerus@linux.intel.com, oneukum@suse.com, grundler@chromium.org, 
	yajun.deng@linux.dev, dianders@chromium.org, linux-kernel@vger.kernel.org, 
	linux-usb@vger.kernel.org, badhri@google.com, albertccwang@google.com, 
	pumahsu@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 31, 2024 at 1:12=E2=80=AFAM Alan Stern <stern@rowland.harvard.e=
du> wrote:
>
> 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?
>
The subsystem, run by the co-processor, provides basic functionality even w=
hen
the main system is suspended or otherwise occupied. In our design, the
subsystem becomes engaged when the main system is powered on. The userspace
will interact with and control both main system (main processor) and the su=
b
system (co-processor). That way, the controllers will not be occupied by bo=
th
processors simultaneously.
>
> > 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 shoul=
d
> > 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.
>
This description does introduce ambiguity, In addition, the implementation =
does
affect more functionality than I expected. I'll re-design the feature to le=
t it
only affect `suspend to RAM`. The related comments/commit message will also=
 be
updated in the next version.
>
> 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.
>
Thanks for pointing that out. I'll use `disable_suspend2ram` in the next
version to better reflect what this feature does. I'll also update other
wordings accordingly.
>
> 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?
>
The implementation will be modified in the next version. This feature will
only focus on `suspend to RAM`.
The co-processor will not be powered when the system is powered off.
>
> Do you really want the new sysfs flag to be present even on systems
> that don't have a co-processor?
>
We've identified a use case where this feature would be essential, which is=
 a
system with both the main processor and the co-processor. However, other us=
e
cases may also benefit from this feature. So, I think we could create a bui=
ld
flag for related data structures and codes.
>
> Why does this affect only the USB subsystem?  Can't the co-processor
> use other, non-USB, devices on the system?
>
In our use case, the co-processor only supports USB subsystem. There might =
be
other co-processors support more subsystems, but we're not sure about how t=
hey
will interact with the system.
>
> Alan Stern