From owner-freebsd-usb@FreeBSD.ORG Sun Jul 3 00:25:53 2005 Return-Path: X-Original-To: usb@freebsd.org 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 8DF8716A41C for ; Sun, 3 Jul 2005 00:25:53 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BAC344287 for ; Sun, 3 Jul 2005 00:16:49 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id A772561246; Sat, 2 Jul 2005 17:16:47 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 1503E5C9D2 for ; Tue, 28 Dec 2004 05:38:26 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id CAF94569C5; Tue, 28 Dec 2004 13:35:45 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0A7A416A601; Tue, 28 Dec 2004 13:35:02 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13BBF16A4CE; Tue, 28 Dec 2004 02:58: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 BEDDF43D49; Tue, 28 Dec 2004 02:58:37 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 7018E6AA01; Tue, 28 Dec 2004 13:58:36 +1100 (EST) From: John Birrell To: Julian Elischer Message-ID: <20041228025836.GA53223@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D0C63F.3000702@elischer.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 28 Dec 2004 13:34:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Level: Cc: usb@freebsd.org Subject: Re: USB problems X-BeenThere: freebsd-usb@freebsd.org List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:25:53 -0000 X-Original-Date: Tue, 28 Dec 2004 13:58:36 +1100 X-List-Received-Date: Sun, 03 Jul 2005 00:25:53 -0000 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. > 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. > 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. > > if (nstatus & UHCI_TD_ACTIVE) > > break; > > > >> in uhci_idone() to the bottom of the loop, it returns the actlen > > properly (I think). At least I can get the data from the device despite > > the stall. > > can it then proceed? Yes, it can. I talk to the device with that change. I'm just not sure whether it makes sense. > I'm trying to address that issue right now.. > If we can't bring netBSD withus in some architectural changes than at > some stage we'll have to go it ourselves. Which I'd rather not do.. > but they are hard to contact.. (probably also short of time) No doubt. > >I'd love to get rid of the attach_args structure and just pass a > >usbd_device_handle into the drivers, with struct usbd_device containing > >a couple of extra variables for use during matching. > > sure.. there are a number of architectural changes "in the wings" > that I'd like ot thrash out with the NetBSD guys but I have found > it hard to find a forum to communicate with tehm on.. > the suggestion "send a NetBSD PR" is the best I've got back so far.. > Though they have seemed friendly enough. Who from NetBSD? If it's one of the 'elephants' (with long memories and who hold a grudge), they might react badly to my name. 8-) [ BTW, I just noticed there is a freebsd-usb list. I must have missed the announcement. ] -- John Birrell _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"