In message: <a276...@mail.gmail.com> "Xiaofan Chen" <xiao...@gmail.com> writes: : On 7/8/07, Xiaofan Chen <xiao...@gmail.com> wrote: : > On 7/8/07, M. Warner Losh <im...@bsdimp.com> wrote: : > > In message: <a276...@mail.gmail.com> : > > "Xiaofan Chen" <xiao...@gmail.com> writes: : > > : On 7/5/07, Hans Petter Selasky <hsel...@c2i.net> wrote: : > > : > > > > The chip does not handle a clear-stall request on the control
pipe to : > > : > > > > clear-stall on the interrupt pipe. The result is that the
interrupt : > > : > > > > pipe stops, or at least all buffers are cleared. : > > : > > > > : > > : : > > : The following is part of the usb firmware from Micrcohip. : > > : > > I never learned the details, but a client of mine was able to get : > > fixes from Microchip for their product. The exact problem was that : > > endpoint stall clearing didn't work for these devices and it was a : > > firmware bug. : > > : > : > Thanks a lot for the info. : > : > I ran the old USBCheck Version 5.10 with PICKit 2 and find out that it is : > true that PICKit 2 failed to respond to a clear STALL feature request for : > endpoint 0 (IN and OUT) even though it successfuly responded to the : > clear STALL request for endpoint 1 (IN and OUT). So I think this is a : > potential bug with the Microchip USB firmware framework. : > : > According to a reply from Microchip Forum: : > "There is a slight ambiguity in the USB spec concerning 'clear stall
feature'. : > Endpoint 0 canot stall a request, so a request to unstall endpoint 0 is : > completely redundant. I recall that the required response is not clearly : > defined. Personally, I just accept the request and acknowledge it, but there : > is no real action to be taken. I guess other software writers have chosen a : > different path." : > : > Why FreeBSD sends out the clear stall feature request for PICKit 2? : > : : The following is the reply from Microchip Forum poster Pacer. : : "The Setup transaction cannot be stalled. However to indicate that the device : doesn't understand the request it may stall the data or status stage of a : control transfer. This is a 'protocol' stall, unique to control pipes, : so doesn't : need to be unstalled with a 'clear feature'. " : : Therefore it must be a 'protocol stall' and FreeBSD does not need to : send a clear feature request for the endpoint 0 to PICkit 2.

I need to look it up, but I believe that a clear endpoint stall also resets the toggle, and that was the bug that was tracked down.

: Am I right?

I'm not sure.

Remind me when is this clear endpoint stall sent? In 7.x we don't send one on pipe open unless the device is quirked to require one. On RELENG_6, at least as of today, we never send one on the open.

Warner