Hi Alan, > In my opinion these semantics are insufficient. Certainly they are > not appropriate for the way usb_unlink_urb() is actually used in many > drivers. A very hasty survey of source files in drivers/usb/class > showns that most synchronous unlinkers require these semantics > instead: Regardless of whether the URB was in progress or not, when > the routine returns the URB must no longer be linked and must be > available for immediate reuse. Also the completion function must have > already returned so that it can safely be unloaded from memory (as in > rmmod). Resubmission within the completion function doesn't make much > sense in the context of a synchronous unlink, so it wouldn't hurt -- > and indeed it might help -- if the core fails such resubmissions. The > return code from the unlink doesn't really matter since callers > usually don't check it, so there's no harm in continuing to return > -EBUSY if the URB wasn't in progress.
better to be explicit I think: provide a routine for halting the endpoint (I guess this exists already). Then people who resubmit in the completion handler can do: halt the endpoint (all submissions to the endpoint will fail). unlink the urb (synchronously) restart the endpoint If I understand right, you are proposing to bundle the "halt the endpoint" part into usb_unlink_urb (sync)? Ciao, Duncan. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
