lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250411010016.dhy45itnjzly5xpg@synopsys.com>
Date: Fri, 11 Apr 2025 01:00:24 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Prashanth K <prashanth.k@....qualcomm.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kees Bakker <kees@...erbout.nl>,
        William McVicker <willmcvicker@...gle.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...nel.org" <stable@...nel.org>
Subject: Re: [PATCH v1 2/3] usb: gadget: Use get_status callback to set remote
 wakeup capability

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ