Seems to me there should really be two usb_disconnect() calls, both of which feed disconect events to khubd. One of the calls would come internally, from hub status transfer processing. It's currently using the same API as the other entry point...
The other entry point would be for the HCD layer, during the two bus shutdown paths: during "rmmod", and after panic when the hardware frogged. Also ideally during the PM resume cases which need it. This is the one which needs to be synchronous; the other one wouldn't really need that.
That seems reasonable, although I'm not convinced that the two paths need to be treated differently (apart from issues of synchrony). Why would a
Well, if they're both feeding events to khubd then 90% of the logic would be the same (in khubd). Yes, synchronization would be the main difference.
PM resume require disconnecting a root hub, and by extension, everything beneath it -- unless the HC hardware had actually gone away while the system was asleep?
Host controllers can lose power and reset themselves during a PM suspend. That's equivalent to the root hub disconnecting, then reconnecting ... as in that OHCI routine.
[ re khubd ignoring USB_STATE_NOTATTACHED ]
The best way to prevent that from becoming a problem is for usb_disconnect() to insure the hub isn't on the event list to begin with. And the best way to insure _that_ is to unbind the hub driver.
I still can't see why it should be that complicated. I've never had to solve problems like that with such indirect solutions in other contexts.
Why shouldn't it be possible for the hub code to sort that stuff directly? Logically it's just setting a flag. Maybe dev->state should be protected by some lock, but certainly it's easy to have a bit that can record the disconnect even if a down_trylock() can't grab that lock. Then dev->state could be updated later when it's more "polite".
- 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
