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.
Here are the weaknesses I want to fix. Oliver Neukum has pointed out that the error handling in usb_physical_reset_device() is bad; under some circumstances it may leave a device in the DEFAULT state (address still set to 0) active on the bus. But that's just the start. 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. Much the same is true for a configuration change. Interfaces only exist under a particular configuration; when the config is changed all the old interfaces go away and new ones appear. That means the core must destroy the old driver-model interface device entries and create new ones. This is not currently being done. Furthermore, both the procedures above have serialization requirements. Consider a disconnect that is recognized during an attempted device reset. Normally the reset will have been requested by a device driver, which may very well have acquired some sort of lock on its private per-device data. When the disconnect is discovered, the driver's disconnect() routine will be invoked. It will also need to acquire the private data lock -- deadlock. Having the driver release the lock while the reset takes place isn't much better, because then the driver has to deal with the possibility that the device has gone away when the reset call returns. I don't know about any other drivers, but in usb-storage that's a pretty iffy situation to be in. And this isn't a purely theoretical scenario; in fact it's exactly what is expected to happen if a USB mass storage device is unplugged while actively in use. 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. Then everything is automatically serialized. Problems involving locking and such will go away, because the thread requesting the reset will be different from the thread carrying it out. Of course, doing this would require changing the way khubd queues its requests. Configuration changes might ultimately best be handled the same way. I'm sure there are plenty of other aspects to this I haven't thought of yet. Before doing any programming, I want to stimulate some discussion and hear other people's views. Thanks, Alan Stern ------------------------------------------------------- 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
