If you mean that nobody has ever needed to cancel just a single synchronous message except as part of cancelling all of them for a disconnect, I agree.
Yes. Same is true when the driver uses asynchronous models too.
Surely you don't mean to say that drivers call usb_unlink_urb() with the URB_ASYNC_UNLINK flag set only during disconnect()?
No. But when would it be appropriate to unlink one request from the middle of an endpoint's queue? At best that's an esoteric and very error-prone case. And a good rule of thumb for designs is to get rid of all such models.
I see. You mean that whenever an unlink occurs, whether synchronous or not, the driver really wants to unlink all the urbs queued for that endpoint. But remember that, unlikely though it may be, it is possible for more than one driver to have requests queued for ep 0 at the same time. If one needs to cancel its request, you're still stuck with all the problems of unlinking a request from the middle of an output queue.
Since control endpoints (like ep0) are the only "non-stream" endpoints in USB, it's perhaps no surprise to find that they might be the (only?) example of a case where an "unlink one request" is really the appropriate model ... all other endpoints involve uni-directional data streaming.
How does your patch know which interface a request is intended for?
Looks at the endpoint addressing information.
Again, what about requests for endpoint 0?
Again, see above. In the rare cases that matters, we have a simple solution that'll work in most cases.
How will your simple solution work in the situation where two drivers are bound to different interfaces on the same device and one of the drivers is rmmod'ed? How does your patch prevent the core from accepting urbs for ep 0 from the driver being unloaded while still allowing submissions from the other driver? Or is this something that has never yet come up and will be dealt with when it really matters?
It's never come up and could be dealt with if it turns out to matter.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
