Date: Sun, 8 Jul 2007 12:31:41 -0400 From: "Xiaofan Chen" <xiaofanc@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD Message-ID: <a276da400707080931h1808f506tc142b94e3ed1fa60@mail.gmail.com> In-Reply-To: <a276da400707080616y4bd8950k470355db92c83077@mail.gmail.com> References: <a276da400707041005k636319bax582c018c46da00ef@mail.gmail.com> <200707051724.30175.hselasky@c2i.net> <a276da400707071725x2b2b8ab3ife6c5459d06042bd@mail.gmail.com> <20070707.231136.-593229846.imp@bsdimp.com> <a276da400707080616y4bd8950k470355db92c83077@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/8/07, Xiaofan Chen <xiaofanc@gmail.com> wrote: > On 7/8/07, M. Warner Losh <imp@bsdimp.com> wrote: > > In message: <a276da400707071725x2b2b8ab3ife6c5459d06042bd@mail.gmail.com> > > "Xiaofan Chen" <xiaofanc@gmail.com> writes: > > : On 7/5/07, Hans Petter Selasky <hselasky@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a276da400707080931h1808f506tc142b94e3ed1fa60>