Design patterns for USB drivers
... There has been a requirement that after a driver's disconnect() routine returns, the driver will not try to access the device at all -- all URBs must be unlinked and the struct usb_device may be deallocated at any time.
I'd describe the requirement as: the disconnect() routine must wait for all URBs to complete, and prevent issuing new ones. Same as on 2.4 kernels, where too many oopses came from drivers that didn't do that.
2.6 is a lot more aggressive at forcing the completions at unplug time even in the face of drivers that don't meet that requirement. That has the positive effect of making unplug lots more robust; and the negative effect of making those driver bugs a lot harder to find.
No, that is not a requirement at all. All of the usb-serial devices violate this "requirement" today. It is perfectly legal to try to access a usb device structure after disconnect() is called. That's what the reference count is there in the structure for.
Not all kinds of access are legit though. For example, using that interface's driver_data isn't legit, and neither is submitting new requests after a return from disconnect() ... because some other driver could now be bound to that device. Dropping a refcount can certainly be legit (when the "put" matches a previous "get").
So just grab a reference when you are first probed() and then only give it back when you are completely done with the device (after both disconnect() and your release() function is done.) Then the device will be automatically cleaned up and everything is fine.
Doesn't the driver model automatically grab a reference on behalf of your driver when it's bound to that interface though? And release it when the driver is unbound/disconnected from it? It won't hurt to grab an explicit refcount ... but I think most 2.4 and 2.6 code is safe even when it relies on that implicit one.
The usb core already can handle us trying to submit urbs against a usb device that has long gone away, let's not break that functionality.
When disconnect() was called because the device was unplugged, you're right that the submit will fail. (Modulo bugs in the unplug path, most of which now seem to be gone.) But that's not the only reason it's called.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
