Date: Sun, 08 Jul 2007 13:59:40 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: xiaofanc@gmail.com Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD Message-ID: <20070708.135940.1102529026.imp@bsdimp.com> In-Reply-To: <a276da400707080931h1808f506tc142b94e3ed1fa60@mail.gmail.com> References: <20070707.231136.-593229846.imp@bsdimp.com> <a276da400707080616y4bd8950k470355db92c83077@mail.gmail.com> <a276da400707080931h1808f506tc142b94e3ed1fa60@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <a276da400707080931h1808f506tc142b94e3ed1fa60@mail.gmail.com> "Xiaofan Chen" <xiaofanc@gmail.com> writes: : 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070708.135940.1102529026.imp>