On Mon, 5 Jan 2004, David Brownell wrote:
A hub doesn't have any state that it needs to preserve across a reset, or at least none that can't be reconstructed after the reset. Since the reset will automatically disconnect all downstream devices, we not only don't want to save the current state, we want to get rid of the state as easily as possible!
But "easily" for who? ...
Easily for developers -- sure, let's have resume processing that always destroys (then recreates) devices. We know that'll be a rich vein of bugs to mine, many of which will be worth fixing.
Easily for users ... that'd mean smarter resume processing, which avoids mining those particular bugs unless it's unavoidable.
In this case, easily for the hub driver -- since it has to reset the hub anyway, why not use usb_reset_device() to do so with no special case code?
And usb_reset_device() is going to great lengths to preserve the device driver state ... a fact that usb-storage relies on when it calls that routine!
Why shouldn't the hub driver do the same thing? If it's going to call usb_reset_device(), then hub driver state won't have changed. It'll know the child devices that used to be connected (and which are all but certainly still connected). It'll have to set them up again.
Leaving the code in there as it is won't make things any easier for users; their devices will still flicker out of existence and then come back reincarnated. Instead it will merely act as a source of errors.
To improve things from the users' standpoint will require substantial changes to a number of drivers but very little change to the hub driver.
Well, it's different when the reset is initiated by some other task (like khubd) than by something like usb-storage resetting to try to kick sense into the device. But since it would be the hub driver doing that reset ... it'd need to change too.
This is clearly outside the scope of my original message.
Well, so long as we're brainstorming in public, I just wanted to point this out as an example of a case where we should know that the current usb stack takes shortcuts that don't much help the "whole system". I don't see the hub driver improving in this area in 2.6.soon, but IMO it's worth thinking about while reworking the reset logic.
- 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
