Alan Stern wrote:
On Tue, 9 Aug 2005, Stefan Richter wrote:
...
Retries (in the error handler) will not help with error recovery either.
...
Are you referring to the "try again" part I wrote above? That has nothing to do with disconnects.
OK, I confused that.
A more general thought: It appears from the example you explained that maybe the USB highlevel carries too much of a burden to watch out for concurrency.
...
I'm not sure I understand your comment. Are you saying that the job I outlined above -- trying to acquire the device semaphore while checking for possible disconnects -- should be part of the USB core instead of the high-level USB device driver?
That's what I meant. (Two different things actually: Knowing that one cannot reset a port after disconnection started, and having to down a semaphore.) But again: I don't know If this is actually desirable and feasible.
It already is in the core. If you're interested, read drivers/usb/core/usb.c:usb_lock_device_for_reset().
I was actually browsing the usb/storage/scsiglue.c, but only old code at lxr.linux.no, 2.6.11 in fact. Sorry, I see now that this is way too old to look at. However the scsiglue.c's device_reset and bus_reset in Linus' tree are still using down(). -- Stefan Richter -=====-=-=-= =--- -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
