linux-kernel - Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage

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: <Pine.LNX.4.44L0.1812141034280.1570-100000@iolanthe.rowland.org>
Date:   Fri, 14 Dec 2018 10:35:58 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Paul Elder <paul.elder@...asonboard.com>
cc:     Felipe Balbi <balbi@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Bin Liu <b-liu@...com>, <kieran.bingham@...asonboard.com>,
        <gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <rogerq@...com>
Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to
 delay status stage

On Thu, 13 Dec 2018, Paul Elder wrote:

> > Suppose we have a core library routine like this:
> > 
> > void usb_gadget_control_complete(struct usb_gadget *gadget,
> > 		unsigned int no_implicit_status, int status)
> > {
> > 	struct usb_request *req;
> > 
> > 	if (no_implicit_status || status != 0)
> > 		return;
> > 
> > 	/* Send an implicit status-stage request for ep0 */
> > 	req = usb_ep_alloc_request(gadget->ep0, GFP_ATOMIC);
> > 	if (req) {
> > 		req->length = 0;
> > 		req->no_implicit_status = 1;
> > 		req->complete = /* req's deallocation routine */
> > 		usb_ep_queue(gadget->ep0, req, GFP_ATOMIC);
> > 	}
> > }
> > 
> > Then all a UDC driver would need to do is call 
> > usb_gadget_control_complete() after invoking a control request's 
> > completion handler.  The no_implicit_status and status arguments would 
> > be taken from the request that was just completed.
> > 
> > With this one call added to each UDC, all the existing function drivers
> > would work correctly.  Even though they don't explicitly queue
> > status-stage requests, the new routine will do so for them,
> > transparently.  Function drivers that want to handle their own
> > status-stage requests explicitly will merely have to set the
> > req->no_implicit_status bit.
> 
> I think this is a good idea. We still get the benefits of explicit
> status stage without being overly intrusive in the conversion, and we
> maintain the queue-based API.
> 
> Would it be fine for me to proceed in this direction for a v2?

It is as far as I'm concerned (Felipe might not agree).  Knock yourself
out.  :-)

Alan Stern

> > (We might or might not need to watch out for 0-length control-OUT 
> > transfers.  Function drivers _do_ queue status-stage requests for 
> > those.)
> 
> Thanks,
> 
> Paul Elder