On Wed, 15 Sep 2010, Toby Gray wrote: > 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. "Better than doing nothing" pretty much sums it up. If you can't reset the device then you're stuck, one way or another. > 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. Not so. I have logs taken using hosts running Windows 2000, Windows XP, and Windows Vista, all containing TEST UNIT READY commands. > 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? The TEST UNIT READY commands get generated in a few different spots. Changing them would be harder than adding a simple flag to usb-storage. 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
