On Feb 1, 2008 11:17 PM, Alan Stern <[EMAIL PROTECTED]> 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.
So I will think this is a "protocol stall" for endpoint 0. Am I right? > 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? If my previous assumption is correct, I will think the Windows driver behavior can be said to be a bit strange since normally you do not need to clear halt for protocol stall. I will think the Linux USB behavior is even stranger. I know quite some USB devices which do not handle clear halt feature request nicely. Sorry if my understanding is wrong. I am always a bit confused by this halt/stall thingy. Last time I've a long discussion with the FreeBSD usb developers and I am not so convinced that they are dealing with it correctly (but the Microchip firmware is the main culprit). http://forum.microchip.com/tm.aspx?m=243771 Xiaofan - 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
