libusb usb_interrupt_read hangs under FreeBSD

[M. Warner Losh]

In message: <a276da400707080931h1808f506tc142b94e3ed1fa60 at mail.gmail.com>
            "Xiaofan Chen" <xiaofanc at gmail.com> writes:
: On 7/8/07, Xiaofan Chen <xiaofanc at gmail.com> wrote:
: > On 7/8/07, M. Warner Losh <imp at bsdimp.com> wrote:
: > > In message: <a276da400707071725x2b2b8ab3ife6c5459d06042bd at mail.gmail.com>
: > >            "Xiaofan Chen" <xiaofanc at gmail.com> writes:
: > > : On 7/5/07, Hans Petter Selasky <hselasky at 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