> However... Suppose you want to cancel an outstanding URB and then reuse
> that URB for a new request. Or suppose a driver's disconnect() routine
> has been called and it needs to cancel all outstanding URBs before
> allowing the driver to be unloaded from memory. In both cases it's
> necessary to wait until _after_ the completion handler has finished -- in
> the first case because you don't want to reuse the URB's data fields while
> the completion handler may still be looking at them, in the second case
> because you don't want the completion handler to try to run when its code
> segment has been unloaded.
>
> The second case is no longer an issue, even for the UHCI driver, because
> it now implements the appropriate endpoint_disable method. This will
> prevent the majority of possible problems.
Ceterum censeo: Until you've solved all problems, the issue still exists.
> But the first case still applies. (As does the case of maverick drivers
> like Bluetooth that don't use usb_free_urb().) So there has to be a way
> for a driver to wait until an URB's completion handler has finished.
> That's the need addressed by usb_wait_for_urb().
Is there anybody using a synchronous unlink who doesn't want that?
> > > At some future time we could consider replacing
> > > synchronous unlink_urb with asynchronous unlink plus wait_for_urb.
> >
> > Why? Does it cause undue hardship in the host controllers to have a
> > synchronous unlink_urb?
>
> There's two points of confusion here. First, the host controller drivers
> don't implement synchronous unlinking -- it's all handled higher up in
> core/hcd.c. As far as the HCDs are concerned everything is asynchronous.
As it should be.
> Second, synchronous unlink_urb doesn't do what is needed because it
> doesn't guarantee that the completion handler will have finished when it
> returns. It only guarantees that the completion handler will have
> finished if it returns _with no error_. A race can cause such an error,
> but the driver will still have to wait until the completion handler has
> finished. That's why usb_wait_for_urb() is needed.
But is very poorly implemented.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
