Greg KH wrote:
On Thu, Apr 15, 2004 at 10:10:00AM -0400, Alan Stern wrote:

Greg:

I just noticed your new usb_get/put_intf() functions. Creating them is a tacit admission that drivers will need to continue using interfaces after their disconnect() routine has returned. Is this wise?

Sysfs may hold references; it's not just (or mostly) drivers ...


The current assumption in usbcore is that when disconnect() returns the driver will have relinquished its interface and no URBs will be active. The core is then free to bind another driver to that interface. If the old driver is still using the interface, it's liable to cause problems.


Yes, but we can't guarantee that the driver is done with the device, or
the interface after disconnect() is over.  And we don't want to do that
either, otherwise it makes the driver's lives a big pain.

That doesn't seem quite right. Here's what I thought the (new) story was going to be:

 - Most drivers rely on the implicit claim that came from probe() success,
   which is implicitly released when the disconnect() returns.  So those
   drivers have a simple rule:  they can't have (or use) any pointers to
   that interface after disconnect() returns.

 - After disconnect(), the driver could keep an interface reference
   IF (!!) it explicitly refcounting it ... which wasn't possible
   before this patch, though device refcounting could until recently
   be a proxy for it.

And the current story for trying to talk to the device after disconnect()
wouldn't change:  it's not allowed.  Although when disconnect() happens
because of physical device disconnect (instead of config change, or
other disconnect/rebind cases), such requests can/do fail cleanly.


So, if you really want to give an interface to another driver, we need
to just unregister it and create a new one.  That way it will all "just
work" properly.

Yes ... but that if the first driver were still allowed to talk to the device after disconnect() returns, then it couldn't work "properly". Anything it did could easily stomp all over the second driver's work.


The reason I created those functions is we never completed the usb
device -> usb interface conversion fully during 2.5.  Drivers should not
care at all about struct usb_device, which is not quite true today (we
still need it for initializing urbs, but that's it.)  Also, with your
upcoming changes for making the interfaces individual structures,
drivers can grab a reference to the interface instead of grabbing the
reference to the device (like they do today.)

When development starts on 2.7, one possibility would be to submit urbs directly to endpoints. Endpoints are logical children of the interfaces, as well as the real targets of the urbs, so they could be cleanly disabled as part of interface disconnect() processing.

- Dave





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to