[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <09fce208-72b1-49e8-988e-ea149fbaf0b5@suse.com>
Date: Thu, 1 Feb 2024 10:38:44 +0100
From: Oliver Neukum <oneukum@...e.com>
To: Guan-Yu Lin <guanyulin@...gle.com>, Alan Stern <stern@...land.harvard.edu>
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 01.02.24 10:02, Guan-Yu Lin wrote:
> On Wed, Jan 31, 2024 at 1:12 AM Alan Stern <stern@...land.harvard.edu> wrote:
>>
>> On Tue, Jan 30, 2024 at 06:47:13AM +0000, Guan-Yu Lin wrote:
>> 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 they
> will interact with the system.
Hi,
it would be very good if you decided this now, before we add attributes.
The reason is that if this feature is needed for multiple subsystems,
the attribute should be added to the generic device structure, so that
the naming and semantics are consistent.
You really don't want to repeat this discussion for every subsystem.
Regards
Oliver
Powered by blists - more mailing lists