From owner-freebsd-usb@FreeBSD.ORG Tue Dec 28 15:23:29 2004 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 244FD16A4CE for ; Tue, 28 Dec 2004 15:23:29 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B59C43D48 for ; Tue, 28 Dec 2004 15:23:28 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) iBSFN8P8057268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 28 Dec 2004 16:23:12 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id iBSFMGUU031940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Dec 2004 16:22:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id iBSFMGMb091380; Tue, 28 Dec 2004 16:22:16 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id iBSFMEo1091379; Tue, 28 Dec 2004 16:22:14 +0100 (CET) (envelope-from ticso) Date: Tue, 28 Dec 2004 16:22:13 +0100 From: Bernd Walter To: John Birrell Message-ID: <20041228152212.GM81585@cicely12.cicely.de> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org> <20041228025836.GA53223@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228025836.GA53223@freebsd3.cimlogic.com.au> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: usb@freebsd.org cc: Julian Elischer Subject: Re: USB problems X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 15:23:29 -0000 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