On Sat, 10 Jan 2004, Duncan Sands wrote: > 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!
In fact this asymmetry is present down in the driver model code: device_bind_driver() doesn't call probe() whereas device_release_driver() does call remove(). Not that this helps any. You may simply have to face the fact that manually claiming an interface means that its remove() function may or may not be called, depending on factors beyond your control. In such a situation, you should arrange things so that remove() does nothing. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
