On Fri, 1 Feb 2008, Matthew Dharm wrote: > On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > > On Thu, 31 Jan 2008, David Brownell wrote: > > > > > On Thursday 31 January 2008, Alan Stern wrote: > > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > > trace and that's what happened under Linux). This was in response to > > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > > are permitted not to support that request if they have only one LUN. > > > > Right now usb-storage responds to this stall by clearing the halt > > feature from the bulk-in and bulk-out endpoints, not because the spec > > says to do so but because one ancient device (a ZIP-100) requires it. > > Now it looks as though we've found a device which can't handle it. > > Time for another quirk? > > 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. 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
