Which points at the ohci driver not allowing usb_unlink_urb() to be called after the device is disconnected. David, is this true?
Certainly. disconnect() is in charge of doing such unlinks.
But we shouldn't oops if unlink() is called after disconnect(), right?
Just to make this more clear: the oops doesn't happen when we unlink
in destroy_scanner but somewhere in ohci which expects that unlink is
already called.
The right place for the unlink is in the disconnect() callback, yes.
Oopsing is undesirable, true, but is one of the consequences of not implementing disconnect() right. And it has the advantage of not facilitating the subtle falure modes coming from components having different notions of device (or interface) state.
Both 2.4 and 2.5 kerneldoc have said for some time that driver disconnect() must address "forcing all pending I/O requests to complete ..." so I guess I don't see why there should be any issue here. We know that handling config (or altsetting) changes, driver changing, and device resets correctly requires that. It's simple enough to do ... it's just got to be done, and we know the fix that the scanner driver needs.
- Dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
