Reset and config changes are inherently ugly because they are a break in a model of interfaces by being operations on devices. Firmware downloading belongs into the same category.
Altsetting changes don't break it, but I don't know of any particular issues there any more either.
Someone should looked at how that sysfs firmware stuff should play with USB!
There are also potential problems involving other connect/disconnect processing on the device during a reset. The best way to solve all these difficulties is to arrange for all device resets to be carried out by the khubd thread.
I'm not sure I'd agree with that. I already find khubd too fragile, mostly because it's a single point-of-failure and things can easily go strange. So I'd rather not create more faults that would wedge all of USB, starting with khubd (wedging rmmod, so reboot is needed).
The cat is out of the bag. Usbfs and module load/unload already take things out of khubd. Solving all that with IPC is unelegant. We'd be better off with using a big semaphore for each bus.
Why would more than "address zero" state management need to be serialized across the whole bus? As soon as the device gets into the ADDRESS state, there's no need to even lock out other ports in that hub before proceeding with configuration.
Much of what khubd does could reasonably be done in the callback for hub status change, or in parallel so state transition bugs affecting a given hub port won't lock up all hubs and ports.
Running in task context makes a lot of things much easier.
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.
While things like marking devices as NOTATTACHED right when the hub status interrupt data reports it "gone" would cut down on false error reports ... vs waiting not only for khubd to be scheduled, but also to get around to handling that end its queue ... ;)
- Dave
------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
