Date: Tue, 28 Dec 2004 16:22:13 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: John Birrell <jb@cimlogic.com.au> Cc: Julian Elischer <julian@elischer.org> Subject: Re: USB problems Message-ID: <20041228152212.GM81585@cicely12.cicely.de> In-Reply-To: <20041228025836.GA53223@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org> <20041228025836.GA53223@freebsd3.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 28, 2004 at 01:58:36PM +1100, John Birrell wrote: > On Mon, Dec 27, 2004 at 06:34:39PM -0800, Julian Elischer wrote: > > can you be a bi tmore explicit abuot what you mena by "stalls the > > control endpoint at > > every opportunity". > > > > The linux libusb has code in its' timeout code that "unstalls" > > endpoints if they timeout. I p[resume becasue they have seen this as > > a common reason for timeouts. FreeBSD issues teh same command on > > endpoint open.. try closing and reopenning the endpoint. > > The stall I'm referring to is a bit in the ISP1581 controller. According to > the USB spec, a device sets the stall bit if it can't do something it is > asked to do. > > In the case of this Philips device, it sends a descriptor (for instance) > and then sets the stall bit on the control endpoint for seemingly no good > reason. > > If you ask for device status, the firware sends it, then stalls the control > endpoint. > > I have to set the NO_STRINGS quirk to stop FreeBSD from ignoring th > device simply because it stalls the control endpoint after sending a > string descriptor. Why is the quirk required? OK - you get a stall on control endpoint, but this shouldn't harm anything, as stalls on control enpoints are automatically cleared on the next setup phase and the Philips controllers do that on their own. If you get in trouble then the firmware on the device does more wrong than just stalling the endpoint. > > hmm I'll have to look at the spec to see if a stall status can > > come back with data? > > My reading of the spec is that, yes it can. In 8.5.3 they refer to 'setup', > 'data' and 'status' stages of a control transfer. You can get a stall later if the case isn't known at request time. IIRC some USB2.0 firmware stall the control enpoint after transfering legal data if they have been asked in an USB1.1 format. I think we had this a while back for high speed hubs. > > There are two 'stalls'.. the endpoint stalls, and the local status > > word reflects that. (at least in EHCI), so you'd need to clear both.. > > one with a write and teh other with a memory write.. > > Are you referring to the 'control' endpoint? The FreeBSD code seems to > infer that the control endpoint shouldn't stall. Maybe there are broken comments left, but a stalled control endpoint doesn't require any special handling other than taken this a an error. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228152212.GM81585>