On Sun, 30 May 2004, Oliver Neukum wrote: > > > You're right; I over-reacted. However, there is a 6-second delay in the > > device reset code (you remember, it's the call to msleep() that I asked > > not to have applied). That won't be cut short by any failed transaction. > > Do we care? Is 6 seconds delay fatal?
It's not fatal, but it's not good either. We ought to be able to avoid the whole issue simply by not locking the device during resets. > > So to make this work, your original complaint will have to be rescinded -- > > the serialize semaphore must _not_ be held during the device reset call > > made in invoke_transport. Actually that's okay, since the reset is an > > ep0 control request, not a regular SCSI command. > > But it's not a regular command. Are you sure all devices can deal with this? You mean, can all devices deal with receiving some random request on ep0 either just before or just after a reset request? Probably yes. If the extraneous request comes before the reset and the device is too messed up then it simply won't respond. If it comes after the reset and the device is _still_ messed up, again it won't respond. In each case we're no worse off than if the outside request didn't occur at all. If the device _isn't_ messed up then the outside request and the reset request can't interfere with each other, because they both go to ep0 and hence are automatically serialized. The only problem we need to guard against is an outside request on ep0 arriving during a regular SCSI command -- so we only need to lock the device while sending regular commands. > > Granted that's so, it doesn't mean we need to use ->serialize. And if we > > do, the parts of usbcore that could send messages to ep0 (probably just > > the usbfs and sysfs routines) will have to be changed to lock the device. > > Yes they would. But what else to take? Another lock? What for if this is not > specific to usbfs? I guess there's no real harm in reusing ->serialize for this purpose. (After all, I'm going to do the same sort of thing with the hub driver, replacing its private semaphore with ->serialize.) So long as the lock is held only during regular commands and not during resets there shouldn't be a problem. Alan Stern P.S.: Vojtech, part of the patch you submitted is already out-of-date! devio.c has already been changed to lock the device during any nontrivial operation. So all that needs to be added are the locks in usb-storage. ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
