On Mon, 19 Jan 2004, David Brownell wrote: > Random notion: each device could have a work_struct used to change > its configuration, deconfigure it, etc. Easy to have those work > in parallel. Not clear how hubs might use that mechanism.
It's not clear to me either, but I will leave the hub driver in a form that makes it clear where the natural parallelization points are. On Mon, 19 Jan 2004, David Brownell wrote: > > I wanted to ask about that. How long should we wait between turning on > > power to different ports? There's a minimum delay before the port is > > usable, but that's not the same thing. > > The USB 2.0 spec might have some advice there. > > By "smarter" I meant something like: > > in hub_probe() > - for each port on the hub: > * power it up > * if there's no device there, continue next port > * debounce and let power stabilize > * hub_port_init() > * add device to a new device queue > > in khubd (later) > - for each device in the new device queue > * usb_new_device() to configure > > And eventually, the config selection code should be noticing > cases like "hub can't supply that much power", and flagging > that error (syslogging, blinking hub led, etc). > > Wouldn't that "khubd (later)" queue work out well in the "morphs" > path through usb_reset_device()? Though maybe registering the > device in sysfs should be taken out of usb_new_device(). Yes, the same code could be used. And yes, the sysfs and usbfs parts would need to be moved. Even more refactoring will be needed. For instance, when preparing to reset a device we probably want to disable all its endpoints. After all, there's no reason to be sending messages to a device that's being reset; at best nothing would happen and more likely they would provoke USB protocol errors. But we don't want to unregister the interfaces, at least not until we find out that the device has "morphed". This suggests separating out the part of usb_disable_device() that removes the interfaces. Likewise, in usb_driver_release_interface() we want to disable the endpoints before calling disconnect, but we don't want to unregister the interface. For that matter, the code that unregisters interfaces really ought to check first that the interfaces really have been registered. I can imagine that a device might be unplugged before all its interfaces are registered. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
