Upcoming changes
The halted[] member of struct usb_device is going to change to refuse[]. I posted another message about this a couple of weeks ago and nobody has responded, so I guess that's okay. Not surprising, since this feature is pretty much unused.
I did however recently run into a device firmware failure mode that was much worsened by having the host cache false "halted" endpoint state. Getting rid of "halted" will be good!
Adding refuse[] seems like a different issue to me; also likely good, to help make sure usbcore can shut things down properly.
Now a more interesting item, not yet entirely certain:
struct usb_device->serialize will become a read-write semaphore.
This is probably the right thing. Do we need it soon though?
We're still stabilizing that part of usbcore. It wasn't clear to me that anything currently under discussion _needed_ this particular change, especially as we shift responsibility for grabbing that lock higher in the stack. I'd kind of like to avoid changing locking models along with those other updates.
The serialize semaphore protects against major changes, things that would involve binding/unbinding drivers or altering the device's physical state. In particular, the following routines will require the caller to hold the semaphore (or, in the new version, to have a write-lock):
usb_driver_claim_interface, usb_driver_release_interface, usb_disconnect, usb_new_device, usb_disable_device, usb_reset_configuration, usb_set_configuration, usb_reset_device
Also, a driver is guaranteed that the semaphore will be held when its probe() and disconnect() routines are called.
That is, device drivers see no differences yet ... but usbcore-internal interfaces are starting to change so that callers grab that lock, which is helping improve enumeration and reset processing (also usbfs).
In general, a driver can acquire the serialize semaphore whenever it wants to block one of the functions above temporarily. A good example would be when calling usb_ifnum_to_if(); that function scans the interfaces in the current configuration and the results would be meaningless if the configuration unexpectedly changed.
Alternatively, just rely on the fact that from the instant your driver is probe()ed for an interface, you can rely on the fact that it'll be valid until that driver (a) fails probing, or (b) returns from disconnect.
That's effectively a readlock policy. The only device driver it fails for would be usbfs ... since it doesn't use "front-door" access to the device tree, from probe(). And it's how drivers already expect things to work. (These changes _should_ be internal to usbcore!)
Only drivers committing sins like holding on to interface handles after disconnect() would even have to think about that lock ... and that means usbfs will, since it's got to scan interfaces without probe() being used.
- Dave
------------------------------------------------------- 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
