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