libusb usb_interrupt_read hangs under FreeBSD

[Xiaofan Chen]

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.

Am I right?