Consider this proposal for an addition (not a change!) to the existing
API. Let's define 3 new bits in urb->flags: URB_LINKED, URB_COMPLETING,
and URB_INVALID (maybe someone can come up with a better name than that
last one). URB_LINKED will be set by the HCD precisely at the time the
URB is linked. URB_COMPLETING will be set by the core during the time the
URB's completion handler is running. (And the core will carefully set
URB_COMPLETING in giveback_urb before or at exactly the same time as clearing URB_LINKED.)
I won't like such new mode bits any more than the current current URB_ASYNC_UNLINK, I have to say ... :(
Then usb_wait_for_urb() becomes a simple wait loop, polling for
(urb->flags & (URB_LINKED | URB_COMPLETING)) == 0
Very simple, easily seen to be precise and correct.
But then, so is retrying synchronous usb_unlink_urb() when it returns -EBUSY. Usually just once, unless the device driver's resubmit logic isn't properly disabled.
The third flag is to help drivers avoid the need for locking synchronization to prevent resubmission. The idea is very simple: If the URB_INVALID flag is set, a low-level HC driver will refuse to link the URB. This test _must_ be made within the same spinlock-protected region that contains point A, so that it is sufficiently atomic with respect to submission and unlinking.
The usb_sg_request model solves this class of problem by forcing an explicit re-initialization before resubmission.
With these mechanisms available, a driver can safely stop an URB from being resubmitted and wait for it to be idle as follows:
urb->flags |= URB_INVALID; usb_unlink_urb(&urb); // Asynchronous unlink usb_wait_for_urb(&urb); urb->flags &= ~URB_INVALID;
And also code in the resubmit path too, yes? Robust drivers would need to change their resubmit logic, you're creating new fault paths.
I guess I don't see why usbcore should be involved there. Drivers without some "I'm shutting down" state flag can easily add one and use it to control whether they resubmit; and it'll help with other situations that an URB_INVALID flag can't address (since it's URB-wide, not device-wide).
What drivers are suffering now from that "resubmits during driver shutdown" syndrome ... do you have any in mind, or is this concern not that concrete? It'd be simpler just to fix those drivers; they need changes in any case.
No locking is needed in the driver; the core takes of it automatically. When this sequence completes, the URB is guaranteed not to be linked and the completion handler is guaranteed not to be running. Even if it always resubmits. (Although it is necessary that the handler does not clear urb->flags!) The URB can safely be reused or the driver module unloaded.
Of course, if these drivers weren't trying to mix up the synchronous and asynchronous APIs, AND have completion handlers which inappropriately resubmit, they'd not have any problems either.
- Dave
------------------------------------------------------- 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
