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.

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

Reply via email to