This would permit an attractive concurrency in handling unplug events.
Concurrency is not attractive, unless performance is an issue.
It is just a source of problems.
Well, the real world is concurrent, so the problems are there regardless of whether the software is geared to handle it. There are several sources of (concurrent) disconnect events:
- hub status event reports - rmmod - hcd panic - certain PM resume scenarios
Plus, the "device morphed" port reset path needs to look a lot like a disconnect -- except that the device goes to USB_STATE_ADDRESS not USB_STATE_NOTATTACHED, and the cleanup after drivers are disconnected looks a lot more like the usb_new_device() in that last patch I sent than in like the current version of that routine.
- Dave
------------------------------------------------------- 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
