Thanks for replying David. > > > When a driver gets a disconnect(interface) call, it must stop using > > > all those references ... though it's just barely OK to drop such > > > a reference (with the also-not-exported usb_put_intf!) after that > > > disconnect() returns. > > > > I know this has always been your position (don't do anything after > > disconnect) - but then what's the point of reference counting? > > Let me flip that around then: if what I said isn't true, then > what would be the point of the disconnect() method? How would > you be expecting drivers to notice and respond to physical device > unplug? Or be unbound from an interface, so that some other driver > could then be bind to it?
Maybe I misunderstood you. I took your "must stop using all those references" to mean: if you use them *any* time after the disconnect call returns, then you may die a horrible death (Oops etc). It sounds like you meant: you must stop using them *some* time after the disconnect (the disconnect call telling you that it's time to start shutting things down). > > I thought Greg's vision of how things should be was: as long as you > > have a reference to an interface, then it is usable (in the sense > > that things will not explode if you try to use it), though most > > operations will fail after disconnect (eg: sending an urb). Has > > that gone down the tube? > > But does any of that disagree with "must stop using the references"? > > Not that I can see. I said "barely OK"; you used different words > that amount to the same thing (in practical terms) ... except in > the case where the driver bound to an interface gets _changed_ without > any physical disconnect (or config change event). It's the physical > disconnect that would cause urb submission to fail. Well, "it's just barely OK to drop such a reference [] after that disconnect() returns" sounded like you were saying that it could be fatal to do anything more complicated than dropping the reference. By fatal, I mean an Oops or something of that ilk. I don't mean: you get -ENODEV. So it's OK to submit urbs and all that after disconnect (the submission failing of course)? > From my perspective you're taking a simple, clear, and strong statement > about how drivers should work and focusing on corner cases ... which > should behave sanely of course, given a physical disconnect, but that > sort of misses the point. That point being: on disconnect(), just > stop using the interface ASAP. ASAP is fine by me. It gives you some slack in your locking, which a strict "at once" doesn't. I thought you meant "stop using the interface at once". All the best, Duncan. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
