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
