linux-kernel - Re: [PATCH v2 1/5] usb: gadget: Add remote wakeup capable flag

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230121020223.l2tyvyqifc7umqpy@synopsys.com>
Date:   Sat, 21 Jan 2023 02:02:36 +0000
From:   Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To:     Alan Stern <stern@...land.harvard.edu>
CC:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        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 Fri, Jan 20, 2023, Alan Stern wrote:
> On Sat, Jan 21, 2023 at 12:21:10AM +0000, Thinh Nguyen wrote:
> > The way gadget->rw_capable is named and described, it's a capability
> > flag. That is, its value shouldn't change from the user config. Perhaps
> > we don't need that in the usb_gadget, and we can have something that
> > looks like this:
> > 
> > if (gadget->ops->wakeup && (c->bmAttributes & USB_CONFIG_ATT_WAKEUP))
> > 	usb_gadget_enable_remote_wakeup(g);
> > else
> > 	usb_gadget_disable_remote_wakeup(g);
> > 
> > The setting of the remote wakeup configuration can be tracked internally
> > by the dwc3 driver based on the usb_gadget_enable_remote_wakeup call.
> 
> 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.

BR,
Thinh