Received-SPF: pass (google.com: domain of linux-kernel+bounces-48465-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240130064819.1362642-1-guanyulin@google.com>
 <0e4221b5-bafe-4bea-b533-0ed8add81ef1@rowland.harvard.edu>
 <CAOuDEK2VSBcQdLKt27VrLUxH2S22275ffbe5mdVM=vBZDhceQA@mail.gmail.com> <09fce208-72b1-49e8-988e-ea149fbaf0b5@suse.com>
In-Reply-To: <09fce208-72b1-49e8-988e-ea149fbaf0b5@suse.com>
From: Guan-Yu Lin <guanyulin@google.com>
Date: Fri, 2 Feb 2024 00:00:00 +0800
Message-ID: <CAOuDEK3YcHxm4H2+n1r5KZoFK9PG9+XeJD49FCKaeX+KFhkrzQ@mail.gmail.com>
Subject: Re: [PATCH] [RFC] usb: host: Allow userspace to control usb suspend flows
To: Oliver Neukum <oneukum@suse.com>
Cc: Alan Stern <stern@rowland.harvard.edu>, gregkh@linuxfoundation.org, 
	mathias.nyman@intel.com, royluo@google.com, hadess@hadess.net, 
	benjamin.tissoires@redhat.com, heikki.krogerus@linux.intel.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 Thu, Feb 1, 2024 at 5:38=E2=80=AFPM Oliver Neukum <oneukum@suse.com> wro=
te:
>
>
>
> On 01.02.24 10:02, Guan-Yu Lin wrote:
> > On Wed, Jan 31, 2024 at 1:12=E2=80=AFAM Alan Stern <stern@rowland.harva=
rd.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 mi=
ght be
> > other co-processors support more subsystems, but we're not sure about h=
ow 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
>

Hi,

Given that in our use case the co-processor only supports USB subsystem, I'=
d
like to proceed with adding the attribute exclusively within the USB subsys=
tem.
Please let me know if there is any further consideration, thanks.