|Xiaofan Chen||Apr 3, 2007 11:54 am|
|Hans Petter Selasky||Apr 3, 2007 12:26 pm|
|Xiaofan Chen||Apr 3, 2007 1:34 pm|
|Hans Petter Selasky||Apr 3, 2007 2:42 pm|
|Xiaofan Chen||Apr 3, 2007 11:55 pm|
|Hans Petter Selasky||Apr 4, 2007 7:37 am|
|Xiaofan Chen||Apr 4, 2007 11:34 am|
|Xiaofan Chen||Jul 4, 2007 5:32 pm|
|Hans Petter Selasky||Jul 5, 2007 3:24 pm|
|Xiaofan Chen||Jul 8, 2007 12:25 am|
|M. Warner Losh||Jul 8, 2007 5:11 am|
|Xiaofan Chen||Jul 8, 2007 1:16 pm|
|Xiaofan Chen||Jul 8, 2007 4:31 pm|
|M. Warner Losh||Jul 8, 2007 8:00 pm|
|Hans Petter Selasky||Jul 9, 2007 4:35 pm|
|Xiaofan Chen||Jul 10, 2007 1:27 am|
|Xiaofan Chen||Jul 13, 2007 10:32 pm|
|Hans Petter Selasky||Jul 15, 2007 9:18 am|
|Xiaofan Chen||Jul 16, 2007 3:44 pm|
|Hans Petter Selasky||Jul 17, 2007 5:55 am|
|Xiaofan Chen||Aug 11, 2007 4:45 am|
|Xiaofan Chen||Sep 22, 2007 3:47 am|
|Subject:||libusb usb_interrupt_read hangs under FreeBSD|
|From:||M. Warner Losh (im...@bsdimp.com)|
|Date:||Jul 8, 2007 8:00:50 pm|
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.