... hold a reference to the usb_device maybe long after the device has been disconnected. This is supposed to be OK, but from your
... no, that's not supposed to be OK. Returning from disconnect() means that a device driver is no longer referencing the interface the driver bound to, or ep0.
Well, I thought Greg wanted it to be OK :) Anyway, I don't use the device after disconnect except to take the semaphore (dev->serialize), check for disconnection (dev->state), and of course to execute a usb_put_dev. Surely this usage should be OK?
Why do you even need that much though? You're not allowed to be USING the device any more; that's the sense in which I was using "reference". Refcounting is orthogonal, except in the sense that to use without owning/borrowing a refcount will likely cause oopsing someday.
As long as your disconnect routine doesn't do usb_put_dev, so that it
There's an implicit usb_get_dev() associated with probe(), and an implicit usb_put_dev() associated with disconnect(). If you're going to add an explicit put(), you need to also add an explicit get(). Few drivers do; most rely on the implicit refcounts.
But if you keep an extra reference to the device, you'd need some way to get rid of it.
Yes, "usbfs" is wierd in lots of ways ... it's got references associated with several distinct roles, including implicitly associated with device creation, and so I'd suspect it doesn't keep them all straight.
Plus, using the claim/release binding model (in its current state) opens it up to a different family of bugs ... since that doesn't hook up properly to the driver model yet, and making it do so is non-trivial.
maintains its reference, I don't see a problem. But why do you want to check dev->state later on? Once your disconnect routine has returned, you should be totally through with the device. You should no longer care whether it's attached or not.
And of course, remember that there are valid reasons for your disconnect routine to be called even when the device remains attached. (rmmod is a good example.)
And adding special case logic for rmmod paths isn't a good thing; better just to implement disconnect() as I described.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
