Date: Tue, 28 Dec 2004 13:58:36 +1100 From: John Birrell <jb@cimlogic.com.au> To: Julian Elischer <julian@elischer.org> Cc: usb@freebsd.org Subject: Re: USB problems Message-ID: <20041228025836.GA53223@freebsd3.cimlogic.com.au> In-Reply-To: <41D0C63F.3000702@elischer.org> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <41D0C63F.3000702@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228025836.GA53223>