Having usb_driver_release_interface call disconnect runs the risk of
infinite disconnect loops if the disconnect() method calls
usb_driver_release_interface.
I've been dealing with this by patching device drivers, but it would be better if the
core took care if it. Since usb_driver_release_interface is just device_release_driver
in disguise, maybe it is best if device_release_driver takes care of it. After all,
shouldn't device_release_driver protect itself against the remove() method calling
device_release_driver, causing an infinite loop? How about this:
--- gregkh-2.6/drivers/base/bus.c.orig 2004-01-22 10:05:34.000000000 +0100
+++ gregkh-2.6/drivers/base/bus.c 2004-01-22 10:06:38.000000000 +0100
@@ -364,12 +364,12 @@
{
struct device_driver * drv = dev->driver;
if (drv) {
+ dev->driver = NULL;
sysfs_remove_link(&drv->kobj,kobject_name(&dev->kobj));
list_del_init(&dev->driver_list);
device_detach_shutdown(dev);
if (drv->remove)
drv->remove(dev);
- dev->driver = NULL;
}
}
On Saturday 10 January 2004 00:50, Duncan Sands wrote:
> On Friday 09 January 2004 02:10, David Brownell wrote:
> > Duncan Sands wrote:
> > > Thanks a lot. This is extremely problematic then: in
> > > usb_set_configuration, an interface's device structure will not be
> > > completely initialized until we do device_add (&intf->dev);
> > > ...
> > > What to do?
> >
> > Hmm, good catch! Looks to me like usb_driver_claim_interface() will
> > need to check whether the device has been added yet. Something like
> > this should do it:
> >
> > intf->dev.driver = &driver->driver;
> > intf->dev.driver_data = priv;
> > if (!list_empty (&intf->dev.bus_list))
> > device_bind_driver (&intf->dev);
> >
> > Then let usb_set_configuration() do the device_add(), which will
> > automatically device_bind_driver() when dev->driver is set. (And
> > will probe() otherwise.)
>
> Hi Dave, I guess the same check is needed in usb_driver_release_interface,
> in case someone claims and releases an interface before it has been
> device_add()ed. This leads to the following behaviour though: if in your
> probe() method you claim and release another interface that has been
> device_add()ed, then disconnect() is called on it; but if you claim and
> release an interface that has not yet been device_add()ed, then disconnect
> is not called. Some might say this is inconsistent, but I think it is OK:
> it can be interpreted as: disconnect() will only be called on interfaces
> that have been probe()ed. On the other hand, there is the following
> variation: suppose interface 0 claims interface 1 when interface 0 is
> probe()ed. When interface 1 is device_add()ed then it is not probe()ed
> because it was claimed. Suppose now interface 2 releases interface 1 when
> interface 2 is probe()ed. Then disconnect will be called on interface 1,
> even though its probe method was not called. Oh well!
>
> Duncan.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
