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
