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? Every user visible function associated with that > state would flicker out of existence, then come back ... and it's a lot > more typical that it come back as "something else" in that case. Even > when it's clearly the same device, by all relevant metrics. > > 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? 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. This is clearly outside the scope of my original message. Alan Stern ------------------------------------------------------- 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
