> Many USB device drivers follow a design pattern that is typified by
> usb-skeleton. The driver has a per-device private data structure which
> includes an in-use semaphore and a refcount (or open_count). The
> semaphore serves to prevent the disconnect() routine from running while
> the driver is actively using the device. The refcount serves the usual
> purpose of preventing deallocation of the private structure until nothing
> is using it any more.
>
> With the new changes, another pattern might work better. In particular,
> there's no need for the private data structure to include an in-use
> semaphore since usbdev->serialize (read-locked) would do just as well.
That is an obvious layering violation. Drivers should not use a core
semaphore unless they have an unavoidable need (like ifnum conversion)
Holding such a lock should be as short and infrequent as possible.
> But in fact, the whole idea of using a semaphore to block disconnect() may
> be unnecessary.
>
> 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.
> The core is now (or soon will be) sufficiently well protected that this
> requirement is no longer needed. When disconnect() is called,
> usbdev->state will already have been set to USB_STATE_NOTATTACHED so no
> new URBs will be accepted, and all URBs in flight will have been unlinked.
That is wrong. Disconnect() need not be triggered by a physical unplugging.
You can unlink all URBs in flight, but you cannot reliably block new
submissions, unless you are willing to do pseudo-RCU.
> All the driver really needs to do is make sure that the struct usb_device
> isn't deallocated until it has finished cleaning up, and that can be
> handled with usb_get_dev()/usb_put_dev().
>
> This approach does have the disadvantage of complicating the driver's exit
It would enormously complicate the softdisconnect in the core.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
