Alan Stern wrote:
I want to propose a reorganization of the way the USB core handles device
resets, configuration changes, connects, and disconnects.  The motivation
for this is to fix a number of weaknesses in the way device resets and
configuration changes are currently being handled.  A good deal of
functionality is lacking, and adding it will require either duplicating or
sharing code with the connect/disconnect pathways.

Yes, there are problems there. I think the changes you're talking about can now be done with only usbcore changes: no more changes at the HCD level should be needed.


If something goes wrong during a device reset, the device won't be
available under either its old incarnation or its new one.  This has to be
treated as though a disconnect occurred.  Furthermore, it's conceivable
that some aspect of the device has changed, so that following the reset it
appears to be a different, new device.  (I suppose a firmware download
might have this effect.)  This needs to be treated as a disconnect
followed by a connect, i.e., unbind the old drivers and reprobe.

So sysfs firmware support might need to hook in there too! ... but it can't realistically do so until some of the cleanups you mention have been achieved.

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).

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.

- 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

Reply via email to