> > Freeing an URB you own is always legal. > > > > Unlinking an URB that's not linked is a different issue.
(That "not" shouldn't have been there....) > > For the moment I don't want to confuse things by talking > > about those cases. > > I don't think that you can seperate the issues. I do, and have. > Either the driver owns the urb during the callback or it doesn't. > > If you own the urb, you may certainly free it. That was the case I was discussing. The other case was for (periodic) URBs that were still linked. > However, we must be able to unlink an urb even while the > completion handler is running, else we race with every > completion handler that resubmits its urb. > Yet we must trust the urb pointer to be valid to do an unlink. I don't see what you're implying. Synchronous unlink in the completion handler does not work, as a rule. So from the perspective of the driver, which does an async unlink (only relevant for a periodic URB), the URB is going to still be linked until it gets a callback with "-ECONNRESET" saying that the async unlink completed. Likewise, that URB is still owned by the HCD/usbcore until that final callback. Also, any driver resubmitting an URB (manually) is exactly analagous to freeing it, allocating a new one, initializing it, and then submitting that one. (Except the smaller overhead.) > IMHO freeing an urb in the completion handler is asking for trouble. And why might that be? As you said above: if the driver owns the URB, it may certainly free it. And when any callback reports that the URB was unlinked (all control/bulk callbacks, and the "-ECONNRESET" and "-ENOENT" ones for periodic URBs), then it's clearly owned by the driver, not the HCD/usbcore. (Otherwise it'd still be linked...) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
