[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8tIrx+F/4X9YyFT@rowland.harvard.edu>
Date: Fri, 20 Jan 2023 21:06:39 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: Elson Serrao <quic_eserrao@...cinc.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"balbi@...nel.org" <balbi@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"quic_wcheng@...cinc.com" <quic_wcheng@...cinc.com>,
"quic_jackp@...cinc.com" <quic_jackp@...cinc.com>
Subject: Re: [PATCH v2 1/5] usb: gadget: Add remote wakeup capable flag
On Sat, Jan 21, 2023 at 02:02:36AM +0000, Thinh Nguyen wrote:
> On Fri, Jan 20, 2023, Alan Stern wrote:
> > A UDC design might have multiple versions, some supporting remote wakeup
> > and others not. But drivers generally use a single static
> > usb_gadget_ops structure, and they don't modify it at runtime to account
> > for hardware differences. So if a single driver controls those multiple
> > versions, you can't rely on the presence of gadget->ops->wakeup to
> > indicate whether there actually is hardware remote wakeup support.
> >
> > Ideally, the usb_gadget structure should have a wakeup_capable flag
> > which the UDC driver would set appropriately (probably during its probe
> > routine).
> >
>
> I was thinking that it can be handled by the
> usb_gadget_enable_remote_wakeup() so we can do away with the
> wakeup_capable flag.
usb_gadget_enable_remote_wakeup() gets called when the gadget or
function is suspended, right? But a gadget driver may want to know long
before that whether the UDC supports remote wakeup, in order to set up
its config descriptor correctly.
Alan Stern
Powered by blists - more mailing lists