On Wed, 20 Aug 2014, Felipe Balbi wrote:
> > > > --- a/drivers/usb/gadget/composite.c
> > > > +++ b/drivers/usb/gadget/composite.c
> > > > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct
> > > > usb_composite_dev *cdev)
> > > > }
> > > > if (cdev->req) {
> > > > kfree(cdev->req->buf);
> > > > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
> > >
> > > it's best to dequeue the request before freeing its buffer.
> >
> > In fact, it's best to wait for the request's completion routine to be
> > called before freeing the buffer. The hardware can access the buffer's
> > memory at any time before the completion routine runs.
>
> dequeue should cause the transfer to be cancelled and given back.
> There's a slight possible race window because we release the controller
> lock in order to call gadget driver's ->complete().
>
> Other than that, it should be fine. No ?
Dequeue causes the transfer to be cancelled and given back, yes. But
usb_ep_dequeue() is allowed to return before those things happen.
It depends on the implementation; in general the only way to know that
the hardware has finished aborting or completing the request is to wait
until the completion routine is called.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
