I'd describe it a bit differently: it ensures that the first phase of disconnection (preventing new URB submissions) completes, for any/all devices, before anything needs to block for the second or third phases (which can take an arbitrarily long time because they need dev->serialize and the third phase calls driver disconnect methods).
Yes, that is true. But, maybe I am dense, but why can't this be done by making state atomic or protect it by a spinlock?
Not dense ... but you do seem to have overlooked the (earlier) part of that note which said:
Maybe having a spinlock protect dev->state transitions would be workable, but it'd likely be a larger patch.
"Atomic" might work too, except that the value is an enum not an integer so there'd be some type punning in the atomic_set() and atomic_read() calls.
- Dave
Regards Oliver
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
