[ good summary deleted ]
Well, as you can see it's a lot of interlocking issues, not just the lack of some functionality in UHCI. While the lines of responsibility are clearly drawn at the moment, not everyone feels they are drawn well. So while this was definitely a bug in the bluetooth driver, one can argue that the USB API should be changed to make the core do more of the work.
Which is why I keep coming back to thinking uhci_endpoint_disable() should exist: the core DOES do that work in most non-UHCI cases!
That'd fix most of the real "observed in the wild" bugs of this type. Certainly not all of the potential cases where synchronous unlink is abused ... just the bulk of the ones that appear in practice.
The way to make that into an API change is to require that all HCDs implement endpoint_disable, and guarantee the consequence to USB drivers: that all (non-control) urbs have completed when the disconnect() routine is called. (That lifecycle is more attuned to a "fire and forget" approach to URB management, fwiw.)
Until that change is made, however, we just have to keep in mind that synchronous unlinks are liable to be sources of trouble.
Primarily because most of the uses of it don't care about _unlink_ as much as something else. Removing those abuses in disconnect() paths will make it easy to identify and fix the other cases.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
