On Sat, 26 Jun 2004, David Brownell wrote: > Alan Stern wrote: > > I've pretty much reached the end of the changes originally lined up > > for the hub driver, but there are two areas that still need > > attention: unbinding and error recovery. The problems and solutions > > And suspend/resume (which I think is in-hand for the moment, but > surely deserves more attention) ... and power on/off, which we > don't yet use.
To be sure. The items I mentioned are only the ones on _my_ to-do list. > > If the hub driver is unbound, then the system won't be able to use the > > hub very well. In particular, connect changes won't be detected. On > > the other hand, devices that were plugged into the hub may still be > > electronically accessible. The cleanest way to handle this is to > > disable all the in-use ports and call usb_disconnect() for their > > children. However, it's a little questionable how we can do this. > > I'm not sure I see the issue. The hub disconnect() routine should > shut down all (hub-managed) children before it returns, and disconnect > all those devices from the usb device trees. Yes it should. On the other hand, disconnect() routines aren't supposed to talk to their devices. Usbcore goes so far as to disable all endpoints in an interface (other than ep0) before calling disconnect(). > > Once a driver's disconnect() is called, the driver isn't supposed to > > communicate with the device any more. By a quirk of the > > implementation we don't enforce this restriction for endpoint 0, which > > is all the hub driver needs for disabling all the ports. Relying on > > such quirks generally isn't a good idea, although this could > > reasonably be considered a special case. > > If hub disconnect() acts as I described above, what would use ep0 > later on? Sorry, I don't follow your question. If hub disconnect() acts as you described above then it will violate the general principles we have laid down for drivers' disconnect() routines, by accessing its device. > > Of course, we can't disable the ports if the hub is suspended. I > > No, but powering off the hub itself is usually an option. Except > for some root hubs; those still don't fit in as smoothly as one > might prefer. Or hubs with ganged power-distribution systems. Furthermore it's not so easy to power-off a hub if its parent is also suspended. > Ignoring the fault cases for the moment, I certainly agree that > config changes (== change config or altsetting, driver bind) > should only happen to devices that are configured and not suspended. Altsetting changes are okay; they will simply fail without affecting anything. But config/binding changes will cause irreversible effects before they fail. > But disconnect/poweroff is a different case; we already know that > driver disconnect() must work with dead devices, so unbind() > ought to work for suspended devices. Then we're stuck with the problem of unbound interfaces that haven't been placed back in altsetting 0 because their device was suspended at the time of the unbinding. Should we try to select altsetting 0 for these interfaces when the device resumes? Or the next time the interface is probed? > > Errors of the first two sorts are best dealt with by resetting the > > hub. Should the user be given a chance to do something first? And if > > so, what could the user do? Unplugging the hub seems to be the only > > course of action, and that's even more drastic than resetting. > > We don't currently have a "let the user do something" mechanism. > Which sort of renders the question moot for now ... though I agree > it'd be good to report some sort of event that userspace tools > could pick up. Do you know how DBUS is handling that stuff now? I have no idea. I don't even know what DBUS is. > > It would be easy enough for usb_reset_device() to disconnect all the > > children when resetting a hub. Right now the code works the other way > > around: When the hub driver wants to reset a hub, it first disconnects > > the children and then calls usb_reset_device() (which will fail). > > Since device resets can arise from outside khubd (from usbfs, for > > instance), the order of function calls should be switched. > > I've had the same thought. That much at least is easily programmed. > > (A related matter is the question of what it should mean to reset a > > root hub. It's not entirely clear what an HCD would need to do or > > whether the existing HCDs support the necessary functionality.) > > I think the functionality is all there, with the reset/start/stop calls, > but not at the generic "usb_bus" level. My question is, exactly what does that functionality comprise? Doing the equivalent of stop, reset, start? > Now that more people are > starting to understand the requirements, it's probably time to start > looking at merging that "hcd" glue into the top level. Maybe call > it "usb_host", maybe still call it "usb_bus". I've been waiting for this to happen; I find this extra "glue" layer to be very confusing. The sooner the better, as far as I'm concerned. > > The remaining problem mentioned above is rapid repeated connect change > > events on a port, rather like init or inetd respawning a program too > > often. We can use the same approach they do, and stop handling > > How often have you seen such problems? I suspect overcurrent notifications > should be in the same category, too. Maybe it should, although that would involve nothing more than suppressing a log message. I've never seen such a problem, although I once saw a report of something that came very close. So perhaps we shouldn't worry about it? > Another option is to just power such troublesome ports off. There > should be a mechanism (not unlike "blinkenlights" deferred work) > for the hub driver to wake up and perform housekeeping, like see > if ports marked "trouble type 3" are behaving yet. That would be a necessary part of any such implementation. Unlike "blinkenlights" it wouldn't have to run in process context. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
