My last patch for usbcore concerns usb_device_remove() in usb.c. The most annoying things about it is its name. The routine doesn't remove USB devices; it disconnects drivers from interfaces. So I renamed it usb_remove_driver(). Luckily it's not used in many places.
I think the name "usb_unbind_interface" is clearest about the responsibility of that routine.
The real problem is that it calls nuke_urbs() for the device containing
the interface it's given. That is clearly a mistake, since nuke_urbs() gets rid of all URBs for the device, not just the one interface. I wrote
another helper function, disable_interface(), which does the same thing as
nuke_urbs() but only for endpoints belonging to a single interface.
Right, I noticed that -- a bugfix is clearly needed....
The other half of the problem comes after the driver has been disconnected. The endpoints will remain disabled, so the next driver that tries to bind the interface is out of luck! I added enable_interface(), which undoes the effects of disable_interface().
I'd rather see this done a bit differently. One issue being device state, lingering between drivers. We normally guarantee that it's been reset before drivers get bound ... but when you do it this way, you prevent that. The device could be in the middle of some operation, waiting for the driver to do something.
A cleaner solution would be calling usb_set_interface() to restore the default altsetting, instead of nuke_urbs(). And remove that special logic now found in usb_set_interface(), for the "there's only one altsetting" case ... if the actual SET_INTERFACE gives a protocol stall, just clear each endpoint's halt status manually.
That solution would address several problems at once:
- Kill the (correct) urbs on driver rmmod, the way that one bit of new code should have been working;
- Fix the bugs folk have reported where that special logic makes some correctly-functioning devices misbhehave, since it won't reset the endpoints implicitly via SET_INTERFACE unless there's more than one altsetting (and reports success, as if it did);
- Fix the problem some folk have with that logic for conformant devices that don't handle SET_INTERFACE, but could achieve the right result by clearing each endpoint's HALT status;
- Make sure the next driver bound to that interface always has a clean slate, with no half-completed operations that it'd need to abort or recover from.
So while this is a good bug to fix, I don't really like this particular fix because of those related issues.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
