On Wed, 15 Sep 2010, Toby Gray wrote: > 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. Because the class-specific reset almost never works and because Windows doesn't use it. As I mentioned in the previous email. > 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? 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. Alan Stern -- 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
