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.
Right, though you could disconnect() in that case ... it just wouldn't be the driver model doing that for you. It might be more consistent to guarantee a disconnect() call in both cases.
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.
Well, ones that got as far as device_add() at any rate!
When device_add() is called, it either finishes the usb_driver_claim_interface() work or uses probe() to select a driver. In either case, that driver will get a disconnect() call, courtesy of the driver model core.
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!
If usbcore guaranteed device_add() were called for interfaces in numeric order, the behavior would be predictable (no device-specific oddness) even in cases of drivers doing unfriendly things like that!!
For now I'd rather avoid making such changes, since I think that scenario only happens with badly behaved drivers:
Alan Stern wrote:
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.
Most factors are under control of the driver ... if they make their first probe() claim the _entire_ group of associated interfaces. That's what today's multi-interface drivers are doing.
(And if usbcore guarantees no drivers get disconnected before all interfaces get their device_add calls.)
It's the whole notion of a "two-phase probe" which creates the real confusion here ... it creates unnecessary failure modes. And that notion would come from a device driver, not usbcore.
- Dave
------------------------------------------------------- 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
