On Thu, 21 Aug 2014, Peter Chen wrote: > > > > > 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(). > > > > > > > > > > > The dp has already been pulled down and the flush pending FIFO buffer > > > has finished, so the controller should not try to access memory buffer > > > after that. > > > > In that case, why does the patch add a call to usb_ep_dequeue()? > > Shouldn't the request be unlinked already? > > > > I mean the controller should not try to access memory buffer after flush > pending buffer which should be done at usb_ep_dequeue, so it is safe we free > the request buffer after usb_ep_dequeue Host controller hardware most definitely _does_ continue to access buffer memory after a dequeue, because the hardware caches the transfer descriptors. I don't know how similar device controller hardware is to host controller hardware, but it certainly seems possible that there could be similar caching going on. > > It can be different for different UDCs. The documentation doesn't say > > that usb_ep_dequeue has to wait until the transfer has been cancelled and > > flushed. > > I think it should add this content, it is strange that we still need to > Wait the transfer has finished/cancelled after calling dequeue, we de-queue > the request, of cos we hope the request has finished, and its resource can be > re-used again. That is not true for usb_unlink_urb(). So why should it be true for usb_ep_dequeue()? Maybe what you want is something like usb_kill_urb(), for the gadget stack. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
