> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern > Sent: Thursday, August 21, 2014 8:38 AM > > 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. AFAIK, it has always been a requirement that usb_ep_dequeue() release the data buffer and call the urb's completion routine before it returns. Quite a few of the function drivers depend on that, after the call to usb_ep_dequeue() they immediately free the data buffer. So if it's not explicitly documented like that, it should be. -- Paul -- 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
