On Wed, 28 May 2003, David Brownell wrote:
Right now there's one great big usb_new_device() routine that mixes up two very different stages
- set address, fetch device and config descriptors
- set configuration, update sysfs
The "update sysfs" should be part of usb_set_configuration(), clearly ... including setting to config 0, which should be similar to "disconnect device" logic except that the device, and ep0, state remains (but no sysfs interface state).
usb_set_configuration() involves two parts. First shut down the current config (skip if the old config is 0). Then install the new one (skip if the new config is 0). The second part should be shared with the updated version of usb_new_device(), the first part with the updated version of usb_disconnect().
I don't think the code should be duplicated into usb_new_device(); there should just be one routine. After all, when that routine is called from usb_new_device(), the current config will already be zero, so the first part will be skipped...
And <linux/workqueue.h> can be used to make keventd do things in parallel, so that misbehavior through one port can't break the others. Dedicated thread not necessary.
That's true. But on the other hand, if the actions being requested are
things that khubd is doing anyway, it hardly seems necessary to go to a
different thread. Also, khubd is _already_ a big single point of failure.
That was the notion: get rid of it. A lot of the problems with the current enumeration logic come from how it's all so monolithic. And khubd is a part of that.
What do you propose? Put most of the usb_hub_port_connect_change() code into a work queue that can run independently of khubd?
I suspect a per-hub "struct work_struct" would suffice, though it's TBD exactly what work would be done there.
This is a bit confusing... Hub status interrupt data only indicates that a port has undergone a status change. It doesn't say what the cause of the change was; for that khubd has to make a port status request. So there doesn't seem to be any way to carry out this suggestion.
Wrong detail... :) We're still flagging NOTATTACHED pretty late, so we get more false error reports than we need. The instant we know a port is gone, the hub driver can mark every child of that port (other hubs too!) NOTATTACHED even if it has to take its own sweet time to disconnect all the drivers from some child of that port.
Well, yes. That could be done right now, independently of all the other changes discussed here.
Yes -- a lot of the re-org parts can be independent.
Your reply did not address the main point of my previous post, which was the implications of having to serialize the operations for each individual device. There are lots of steps involved here:
Reset the port, Set the device address, Download the descriptors,
You mean "read" the descriptors ... in the typical case, downloading firmware to the device would include those descriptors.
Select a configuration, Set the configuration, Set the interfaces, Create sysfs entries for the interfaces, Delete sysfs entries, ...
plus plenty of little ones I left out. What's the best way to arrange that these things only happen one at a time for each device (one at a time per bus for some of them)? How do we do that and still permit a driver to request a configuration change, a device reset, or a re-enumeration?
I had already answered that: a per-bus lock for all the "device zero" operations (port reset through SET_ADDRESS), a per-device lock for setting the config and (same operation, usb_set_configuration) creating/destroying sysfs entries.
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
