On 14/09/2010 20:18, Alan Stern wrote:
On Tue, 14 Sep 2010, Toby Gray wrote:
...
My question therefore is if it is necessary to always reset the USB
device when a usb-storage command times out?
It is pretty much the only choice. There is a class-specific reset but
it almost never works (probably because Windows doesn't use it).
Ok, I thought it would probably be the case. I've just found the part of
the USB MSC CBI specification which talks about trying a Command Block
Reset before a Port Reset.
...
The class-specific reset is implemented by us->transport_reset(us) in
the usb-storage driver.
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.
I've tried exchanging the two resets, so that it attempts a
class-specific reset first and only tries to reset the port if that
fails, and it seems to fix the issue so that both Barry and usb-storage
continue to work correctly.
...
Perhaps a better question is why the Blackberry fails to respond to the
TEST UNIT READY command in the first place.
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?
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
