On Fri, Jan 20, 2023, Alan Stern wrote: > 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. > No, this is to be called during set configuration. If the configuration doesn't support remote wakeup, the device should not be able to send remote wakeup. BR, Thinh
