From owner-freebsd-usb@FreeBSD.ORG Tue Dec 28 19:54:39 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 8A7A316A4CE for ; Tue, 28 Dec 2004 19:54:39 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864DC43D45 for ; Tue, 28 Dec 2004 19:54:38 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id DC47C6AA04; Wed, 29 Dec 2004 06:54:36 +1100 (EST) Date: Wed, 29 Dec 2004 06:54:36 +1100 From: John Birrell To: ticso@cicely.de Message-ID: <20041228195436.GA61668@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org> <20041228025836.GA53223@freebsd3.cimlogic.com.au> <20041228152212.GM81585@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228152212.GM81585@cicely12.cicely.de> User-Agent: Mutt/1.4.2.1i 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 List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2004 19:54:39 -0000 On Tue, Dec 28, 2004 at 04:22:13PM +0100, Bernd Walter wrote: > 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. The quirk gets around the problem that FreeBSD turns the stall status of the control endpoint into an error which aborts any further processing. The string descriptors are returned normally by the device, except for the fact that it sets the stall bit on the control endpoint. (If the handling of the stall status is changed, the quirk wouldn't be necessary) > 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. The firmware in this device doesn't test the format. It unconditionally stalls the control endpoint in many cases (like getting a device or configuration descriptor and requesting less bytes than the full descriptor; getting a string descriptor; getting configuration; getting status). > Maybe there are broken comments left, but a stalled control endpoint > doesn't require any special handling other than taken this a an error. In usbd_do_request_flags_pipe() there is code that detects a stalled control endpoint and then tries to clear the stall. In the case of the devices I have, this code just fails because it gets a stall error too. The FreeBSD code *never* takes into account that the control endpoint stall will be cleared with the next setup packet. I think that a control endpoint transfer should not return USBD_STALLED to the caller unless the length received is less than that requested and ~SHORT_TRANSER_OK. A stall on the control endpoint should only be an error if the controller has a problem with the protocol (i.e. it is a protocol stall, not a device stall); -- John Birrell