If you need to have disconnect() called in all cases, feel free to get rid of usb_interface.driver ...
Hi Dave, the obvious thing to do (once intf->driver is thrown away) is to call device_release_driver in usb_driver_release_interface.
The usb_driver_release_interface() call could reasonably become just an inline function (without those null checks) doing exactly that.
The converse change is inlining usb_driver_claim_interface() so it calls device_bind_driver() and sets the driver data.
However this means that disconnect will be called. That is fine for usbfs, but it seems to me that it is no good for usbnet... Comments?
If the cdc_unbind() problem had assumptions about whether the control interface disconnects before the data interface, we should have heard problem reports long ago! When one of them gets disconnected, the other one is released; there are cdc-ether devices with both descriptor orders.
Drivers without code like that can be easily patched, even before usb_interface.driver is removed.
- Dave
Ciao,
Duncan.
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
