Am Dienstag, 6. Januar 2004 00:06 schrieb Alan Stern:
> On Mon, 5 Jan 2004, David Brownell wrote:
>
> > Resetting a hub also resets devices on downstream ports ...
> > including the DVD you may have been burning! That's
> > not something that seems safe to try automatically on
> > all kinds of devices. For mice -- probably safe.
>
> Yep, it's a dangerous thing to do. But that's what the hub driver
> currently does.
We cannot avoid it. We lack the information needed to tell what
we are affecting. We could even hit somebody's root device this way.
> > I'm not sure how often that special case code has been used;
> > I don't recall noticing it happen (Maybe that's because
> > it's reporting with KERN_DEBUG. It should use dev_err.)
>
> Maybe it never has happened. Not having had much experience with them, I
> would imagine that hubs are usually pretty reliable.
>
>
> > > Even better, all the special-case code in hub.c:hub_reset() could be
> > > removed if we had a way to specify that usb_reset_device() should follow
> > > the "device morphed" path, regardless of whether the descriptors actually
> > > did change. For instance, we might say that this should happen whenever
> > > the device being reset is a hub.
> >
> > There are a lot of kinds of reset, and it's clear to me that the
> > current usb_reset_device() semantics are sometimes irrelevant.
> >
> > There should probably be a "powercycle the port" reset too.
Strong agreement.
> > (Gets back again to hub-wide resets. Not all hubs can do per-port
> > switching, sometimes power switching is ganged, so that'd force
> > all ports to powercycle not just the one.)
>
> That would be a good feature to have, if we can decide how to deal with
> the problem of power-ganged ports.
There is no difference to dealing with reset on a multi-interface device.
> > Why would you say hubs should act that way? It'd make sense
> > to me for hubs to be like usb-storage, and support a limited
> > amount of history during resets. Enough to do a more graceful
> > restart for devices that have significant driver state (like
> > the SCSI stack, which can show as files in a user's GUI).
>
> 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!
Not true for the downstream devices.
> A more sophisticated approach to this whole thing would be to make drivers
> aware that their device might undergo a reset for external reasons at any
> time. If the driver had some way to be notified of an upcoming reset then
> it could take steps to restore the device to its original state
> afterwards. Thus all drivers for devices downstream from a malfunctioning
> hub could be notified before (and again after) the hub is reset.
> Similarly, drivers bound to multiple interfaces could be notified when one
> of them decides to reset the device. (But what is a driver supposed to do
> about incoming requests during the reset period when the device is
> unavailable? Fail them, delay them, or whatever?)
>
> I suspect this is all too esoteric for us to worry about, at least for
> now.
On the contrary. I think you have solved the reentrancy due to reset problem.
It requires two new hooks, though.
> > No ... better just say that drivers for single-interface devices
> > sometimes need to manage their resets. Maybe they'd need a
> > usb_driver.reset() hook; maybe not. But usb-storage clearly
> > expects to recover from a reset, and I think eventually the hub
> > code should too (for PM resume and other cases, although in at
> > least some of those cases other driver callbacks may apply too).
>
> What can the hub driver do to recover from a reset? It can't preserve its
> children -- they will have been disconnected and they will show up again
> in the usual way as connect events once the reset is complete.
This should not be done. The children should be notified that a reset
has just completed.
[..]
> No, you almost certainly would. The hub upstream of the disconnected
> subtree would report the event within 32 ms (or whatever the status
> interrupt URB period is) whereas the missing hubs would cause single
> errors instead, and the hub driver doesn't do anything until it
> accumulates something like 10 errors. So disconnect processing would
> start at the top of the tree, not in the middle.
Don't depend on this. It is too brittle an assumption.
[..]
> > > This would permit an attractive concurrency in handling unplug events.
Concurrency is not attractive, unless performance is an issue.
It is just a source of problems. If something goes wrong in kernel space
you are heading for reboot. It is just a matter of time.
Regards
Oliver
-------------------------------------------------------
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
