On Wed, Sep 15, 2010 at 7:57 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > Just curious - would it be better to instead update the code the way Toby has done: try a class-specific reset first, and only if that fails then try a port reset? Is there a problem with this that I'm not seeing? - Anand -- 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
