- in error recovery by disabling ports we should (currently don't - but that's a bug) go _up_ the tree.
Why would that be? If code has a valid lock on a hub, to disable or reset a port on that hub, why would it get a lock on the parent of that hub?
For error recovery. If an attempt to disable the port fails, we can't simply leave things as they stand -- there will be an unaddressed device attached to the bus. It will be necessary to disconnect the entire hub to avoid problems. And doing that requires a lock on the hub's parent.
That requirement would cascade all the way down from the root ... a lock tree would handle that neatly. When doing such things, don't drop the root lock until you're done ... but it'd not need to lock out tasks that are configuring devices elsewhere in the tree.
I hope you're actually saying that if the device is in the DEFAULT state (a brief instant during port reset) that might need to happen. Right now nothing does such things ... has that been making trouble? Hubs that can't disable ports would seem to be rather broken...
When the goal is just to disable a port with a device in ADDRESS or CONFIGURED states, there's no real harm if it can't be disabled. No point in changing anything more than the state of that one hub.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
