From owner-freebsd-usb@FreeBSD.ORG Thu May 5 06:41:18 2011 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F4BE106564A for ; Thu, 5 May 2011 06:41:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id D351A8FC15 for ; Thu, 5 May 2011 06:41:17 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=0KkIQGagYCvnrzE3Z2Lmid87OPdbX6VLcZYwAuLMZ50= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=Qcgr9xoES4kA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=0B4qurVIhTwzfbRPdUMA:9 a=Tv8Ar3qBBjMFTapjfiEA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 122928953; Thu, 05 May 2011 08:41:15 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Thu, 5 May 2011 08:40:07 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105050840.07361.hselasky@c2i.net> Cc: Trevor Blackwell Subject: Re: Clearing stalls: usbd_xfer_set_stall vs usbd_do_clear_stall_callback X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:41:18 -0000 On Thursday 05 May 2011 03:16:14 Trevor Blackwell wrote: > We have a system that experiences occasional stalls due to ESD strikes in > the cable between the host & hub. So I've been extensively testing the > clear stall logic. > Hi, > It's done two different ways in the standard drivers. In if_cdce it's: > > if (error != USB_ERR_CANCELLED) { > usbd_xfer_set_stall(xfer); In this case you need to either set the number of frames equal to zero, or setup a valid data chain! > usbd_transfer_submit(xfer); > } > > In the midi part of uaudio it's done by setting up special control > transfers and keeping state in the driver: > > if (error != USB_ERR_CANCELLED) { > /* try to clear stall first */ > chan->flags |= UMIDI_FLAG_READ_STALL; > usbd_transfer_start(chan->xfer[3]); > } > ... > static void > umidi_read_clear_stall_callback(struct usb_xfer *xfer, usb_error_t error) > { > struct umidi_chan *chan = usbd_xfer_softc(xfer); > struct usb_xfer *xfer_other = chan->xfer[1]; > > if (usbd_clear_stall_callback(xfer, xfer_other)) { > DPRINTF("stall cleared\n"); > chan->flags &= ~UMIDI_FLAG_READ_STALL; > usbd_transfer_start(xfer_other); > } > } This way is depreciated, and has been changed into the above method which should work exactly the same. > > The first sure is simpler, but it doesn't seem to work. Stalls never get > cleared. Tracing through the code, it's not clear how the clear stall > request is supposed to get filled in. I can see that usb_xfer_set_stall > ultimately leads to a call to usbd_clear_stall_proc, but I can't find where > udev->ctrl_xfer[1] gets set up with the right endpoint values. Look in usb_device.c and the function: usb_do_clear_stall_callback() The way it works, is that this function scans the USB device for stalled endpoints, and then clear one and one of them in turn. --HPS