On 15/09/2010 15:27, Alan Stern wrote:
On Wed, 15 Sep 2010, Toby Gray wrote:
...
Thanks for pointing me towards that. Is there any reason why
usb_stor_invoke_transport tries to reset the port before trying the
class-specific reset method? Other than the extra 5 second wait on every
timeout while it tries to send the Command Block Reset.
Because the class-specific reset almost never works and because Windows
doesn't use it. As I mentioned in the previous email.
Sorry, I didn't explain my question very well. My question probably
should have been: as the class-specific reset almost never works, is the
only reason to attempt it after a port reset has failed is because it's
better than doing nothing? You're most recent response to Anand Gadiyar
has answer this though.
...
Recent BlackBerry devices don't show this hang so I've been working on
the assumption that it's a firmware issue on some older BlackBerry
devices. This being the case would this possibly be a new unusual device
feature flag to add to usb_usual.h for some BlackBerry devices?
Yes, you could do that. But the flag should merely indicate which type
of reset to try first; it shouldn't be connected with BlackBerrys
specifically. After all, other types of devices might need the flag
too.
Agreed, I wasn't planning on having the flag connected to BlackBerrys in
anyway (other than an entry assigning that flag to BlackBerry devices in
unusual_devs.h).
Coming back to the point you made in your original reply about why the
BlackBerry fails to respond to TEST UNIT READY, it appears to be that on
Windows, TEST UNIT READY queries are never sent to the device. Windows
seems to use READ FORMAT CAPACITY followed by REQUEST SENSE to determine
if media is present, but I'm going to have a look at this in more detail.
Assuming that is what Windows does, would a better solution be to add a
flag for faking TEST UNIT READY commands as a READ FORMAT CAPACITY
followed by REQUEST SENSE (or however Windows seems to do it)? Or would
you say that having a flag for trying class-specific reset first is a
better solution?
Regards,
Toby
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
