On Fri, 1 Feb 2008, Matthew Dharm wrote: > > > Do we really need another quirk? If the 'popular' OS does it, it's likely > > > safe to do for all deveices when GetMaxLUN fails... > > > > You missed the point. Windows does _not_ do it -- i.e., does not clear > > a halt on either bulk endpoint. Linux does so only because somebody > > (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed > > out that the ZIP-100 drive needs it. > > > > The clear-halt for endpoint 0 probably isn't needed by anything; I > > don't know why Windows does it. > > Anything except this device, that is. I thought we had traces of Windows > issuing a clear-halt to endpoint 0 after a failed GetMaxLUN. Or did I read > the thread wrong?
Here's the precise situation in a nutshell. Robert has provided traces for his mp3 player showing the following: Linux (uncustomized): Get-Max-LUN => STALL clear-halt(bulk-in ep) clear-halt(bulk-out ep) INQUIRY => failure Windows: Loop 3 times { Get-Max-LUN => STALL clear-halt(ep0) } INQUIRY => success Linux (customized usb-storage -- no trace posted, just the final result): Get-Max-LUN => STALL clear-halt(ep0) INQUIRY => success I'm speculating that the device doesn't need the clear-halt for ep0 at all; Robert should be able to check whether that's true or not. It seems clear that the clear-halts for the bulk endpoints are causing problems. As Pete mentioned, the only devices which do seem to need the clear-halts on the bulk endpoints are some really old ZIP-100 drives with outdated firmware. As I see it, we could either stop supporting them altogether or else add a quirk indicating that the bulk endpoints need to be cleared following a Get-Max-LUN STALL (US_FL_CLEAR_BULK_EPS_AFTER_GET_MAX_LUN_STALL ?!). Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html