I'm recombining the different parts of this thread, since things seem to be winding down.
On Wed, 7 Jan 2004, David Brownell wrote: > 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". This is a key issue: whether usbdev->state needs to be protected by some sort of lock. So long as it is only changed by the hub driver no lock is required. The problem is that it can be changed by other threads as well via usb_set_configuration() and usb_reset_configuration(), maybe other routines too. The best approach might be to have these routines _not_ change usbdev->state but instead ask the hub driver to change it for them. That change (which need not take place immediately) could then be synchronized with the other actions of the hub driver in some private way. In particular, and most importantly, it would mean that usbdev->serialize would _not_ protect usbdev->state, contrary to what I've been assuming all along. This would make it easy to change the state to NOTATTACHED for all devices in a subtree as soon as a disconnection is detected. The remainder of disconnect processing (unbinding drivers, unregistering devices, etc.) could then be handled in another thread with no penalty. These changes are sufficiently well localized that they could be introduced in 2.6. As another possible approach, we might want to make USB_STATE_CONFIGURED _not_ a state at all. Then usb_set_configuration et al. wouldn't have to touch usbdev->state and life would be simpler. The equivalent information is available anyhow by way of usbdev->actconfig. > [ re khubd ignoring USB_STATE_NOTATTACHED ] As I mentioned yesterday, if usb_disconnect() is changed to disable each device before processing its children, this issue becomes less important. There's also the question of how to prevent the hub release() routine from running while the hub is actively in use without incurring deadlock when the hub is reset; making the hub driver use usbdev->serialize rather than hub->khubd_sem should take care of that. > >>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. I don't see synchronization being an issue. For example, consider a PM resume that has to reset the root hub. If the disconnect call would remove the pointer from the bus structure to the root hub and then instantiate a new root hub, there would be no need to wait for all the old devices to go through the disconnect procedure. The PM resume could continue right away, as soon as the disconnect call returned. I see the real issue being the distinction between root hubs and other devices. So we should have two varieties of usb_disconnect (or maybe two somewhat different internal pathways in a single routine) based on whether or not the device in question is a root hub. That would also accomplish what you want. Alan Stern ------------------------------------------------------- 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
