> 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?
> 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?
> > > On the whole, it might be better to add a new mutex to struct usb_device
> > > to provide this sort of driver-level serialization rather than overload
> > > the existing mutex, which is meant to serialize actions by usbcore.
> >
> > But we should guard against actions by or through usbcore, too.
> > If I understand the problem correctly ep 0 must not be touched within
> > this window, no matter what.
>
> 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?
Regards
Oliver
-------------------------------------------------------
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
