Duncan Sands wrote:
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:

Unfortunately that means remove() calls can't rely on the driver model state being set up sanely ... so things like dev_dbg() will oops, and surely more.

If the driver model core were to handle this, a better
way would be expand the "should I disconnect" test,
something like I show below.  Greg, Pat -- comments?

Also, see the update to your "remove usb_interface.driver"
patch I'm about to post.

- Dave


 {
        struct device_driver * drv = dev->driver;
        if (drv) {

^^^^^^^^


if (drv && !list_empty(&dev->driver_list)) {

                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);
        }
 }





------------------------------------------------------- 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

Reply via email to