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

Reply via email to