On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote:
I hereby invite comments from other USB developers...
We are discussing the possibility of adding a semaphore to struct usb_device. This semaphore would be acquired by usbfs (and maybe other parts of usbcore too) before sending URBs to the device. Drivers could grab the semaphore whenever they need to carry out a sequence of operations free of interference from other processes.
Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set, usbcore would reject urbs with -EAGAIN ... from all contexts, including the many that can't acquire semaphores!
Usb-storage in particular needs this, because a number of storage devices can't handle ordinary USB requests (like GET_DESCRIPTOR) while processing a SCSI command. It's not clear whether or not this is in violation of the USB spec, but that's the way they are. Hotplug scripts in particular can generate usbfs activity that interferes with the devices' operation.
This isn't quite correct -- I believe (and the folks on the USB-IF that I've spoken to all agree) that this is a clear spec violation. But, violation or not, there are a lot of devices like this.
Which sounds to me like this might be an example of quirk handling that ought to land in usbcore (rather than usb-storage). A first!
For example, enumeration would detect one of those devices, and set some per-device bitflag. URB submission would test that flag. If clear, everything would be normal. Otherwise, the submit path would fail unless it could (atomically) set BUSY. It'd be cleared on giveback(), for all new-style HCDs.
I would propose, as a general rule, that drivers grab this semaphore whenever they are attempting to execute a series of URBs that is best viewed as a "transaction", as that is really the type of firmware that will likely show this bug. The usb-storage driver often has to use 3 URBs in a "transaction" (command/data/status).
That is, you think the handling of this quirk should be in the device drivers rather than usbcore ... even though that'd mean any calls that don't go through expected call path ("front door") would be able to bypass the handling? That could make sense, especially if there are really not many such devices (or they're all usb-storage, etc).
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
