> > 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.
Why drop the checks? It is not a fast path.
> The converse change is inlining usb_driver_claim_interface()
> so it calls device_bind_driver() and sets the driver data.
Of course.
> > 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.
I'm talking about code like this (in cdc_bind, called from probe):
status = usb_driver_claim_interface (&usbnet_driver, info->data, dev);
if (status < 0)
return status;
status = get_endpoints (dev, info->data);
if (status < 0) {
usb_driver_release_interface (&usbnet_driver, info->data); <== HERE
return status;
}
do you really want disconnect to be called from the middle of a probe
routine?
Or how about this:
static void usbnet_disconnect (struct usb_interface *intf)
{
struct usbnet *dev;
struct usb_device *xdev;
dev = usb_get_intfdata(intf);
usb_set_intfdata(intf, NULL);
if (!dev)
return;
xdev = interface_to_usbdev (intf);
devinfo (dev, "unregister usbnet usb-%s-%s, %s",
xdev->bus->bus_name, xdev->devpath,
dev->driver_info->description);
unregister_netdev (dev->net);
/* we don't hold rtnl here ... */
flush_scheduled_work ();
if (dev->driver_info->unbind)
dev->driver_info->unbind (dev, intf); <== HERE
This may call usb_driver_release_interface on a different
interface, which will immediately call back into usbnet_disconnect
on another interface. Is it OK to call unregister_netdev twice on
the same device?
Or how about:
usb_audio_disconnect calls snd_usb_audio_disconnect which
calls usb_driver_release_interface which calls usb_audio_disconnect
... and so on forever.
In short, out of the three users of this stuff, it looks to me like
two would break if this change is made (usbfs would be OK).
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
