Re: [PATCH v1 2/3] usb: gadget: Use get_status callback to set remote wakeup capability

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Thu, Apr 10, 2025, Prashanth K wrote:
> 
> 
> On 10-04-25 03:42 am, Thinh Nguyen wrote:
> > On Wed, Apr 09, 2025, Thinh Nguyen wrote:
> >> On Wed, Apr 09, 2025, Prashanth K wrote:
> >>>
> >>>
> >>> On 09-04-25 06:25 am, Thinh Nguyen wrote:
> >>>>
> >>>> Not at the gadget level, I mean to create a configfs attribute common
> >>>> across different functions to allow the user to enable/disable the
> >>>> function wakeup capability via the configfs when you setup the function.
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Thanks,
> >>>> Thinh
> >>>
> >>> Thats a good idea, in fact I had the same thought. But thought of doing
> >>> it later since its beyond the scope of this patch/series.
> >>
> >> The way you have it done now forces a usb3x function driver to implement
> >> f->get_status to be able to respond with function wakeup capable.
> >> Previously, we automatically enable function wakeup capability for all
> >> functions if the USB_CONFIG_ATT_WAKEUP is set.
> 
> Currently function wakeup is implemented only on f_ecm and others don't
> have the capability, so the expectation is functions should add add the
> get_status callbacks while implementing remote/func wakeup and mark
> itself and RW/FW capable. And if get_status callback is not there, then
> func is not FW capable.
> 
> Current implementation sets RW/FW capability to all interfaces if
> USB_CONFIG_ATT_WAKEUP is set (which is not right). I have provided an
> example in the commit text where we incorrectly set FW capability.
> >>
> >> Arguably, this can cause a regression for remote capable devices to
> >> operate in usb3 speeds.
> > 
> > Sorry typos: I mean arguably, this can cause a regression for remote
> > wake capable devices to perform remote wakeup in usb3 speed.
> > 
> > BR,
> > Thinh
> > 
> >>
> >>>
> >>> We can add a configfs attribute to enable/disable FUNC_RW_CAP, and
> >>> functions can return get_status() based on the attribute.
> >>>
> >>
> >> That would be great! This would fit this series perfectly. Let me know
> >> if there's an issue.
> >>
> I seriously think we can take it out of this series and do that
> separately. The intention of this series was to fix the wakeup
> operations. And enable/disable func_wakeup from function driver would be
> a new implementation. Ill take it up after this.
> 

Fair enough. Thanks for the work!

BR,
Thinh