On Wednesday 06 April 2005 10:28 am, Duncan Sands wrote: > Hi 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? > 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. 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. > Or is it rather that it never came up > the tube in the first place? The USB-specific interface refcounting calls never got exported, but it's not clear to me why they'd be needed given that the driver model itself exports refcounting for their devices. No driver has yet needed them, either. Same thing with PCI etc. Device memory doesn't go away until after the last refcount is dropped, but when the driver remove() is called, the driver should reverse all effects of probe(). If the device is still there (or in the USB case, the interface), then another driver may immediately be bound to it. > > The way to get a proper reference to an interface is from probe(), > > normally as the parameter but also possibly by groveling around > > in the active config and finding one to usb_driver_claim_interface(). > > I'd not rely on any other method of getting an interface reference, > > though I trust usbfs gets the locking right now. > > > > Then on disconnect() clean up, nulling out the old pointers and > > either just stopping all use of the interface passed in the > > disconnect() call or calling usb_driver_release_interface(). > > So once again: if this is the case, what is reference counting for? To make sure things behave sanely (no oopsing) in the gap between when your driver gets a disconnect() and when it finally finishes acting on that call, given physical disconnect. Just as in any other use of device reference counting in Linux. That doesn't change the semantics of disconnect() though. It still means "stop using this ASAP"; and when the driver returns from that call, usbcore is still able to unbind that driver from the interface. - Dave ------------------------------------------------------- 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_ide95&alloc_id396&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
