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.
Or how about the approach I suggested (see text quoted above)? That'd be much simpler. There's no need to couple device state changes to the hub driver.
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.
That might work, on the other hand I don't see any reason to change that. I think it's good to have Linux track the device state; it's already helped sort out problems where usbcore is getting confused about such things.
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.
But "as soon as ..." is a synchronization ... :)
There may be parts of usbcore with "no need", but other things will. It's not good to have multiple devices with the same serial number, when the application software has a right to "know" that those devices actually have unique serial numbers.
Also sysfs needs to be properly cleaned up before the devices can (re)appear at their old locations.
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.
That could very well be true. I'm eagerly awaiting your patches ... ;)
- Dave
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
