From owner-freebsd-usb@FreeBSD.ORG Tue Nov 20 07:13:42 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1A6E752 for ; Tue, 20 Nov 2012 07:13:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 29AEF8FC12 for ; Tue, 20 Nov 2012 07:13:41 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 347756475; Tue, 20 Nov 2012 08:13:39 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Subject: Re: [patch] fix uplcom(4) clear stall logic for PL2303HX Date: Tue, 20 Nov 2012 08:15:19 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20121120025722.GA3338@oddish> In-Reply-To: <20121120025722.GA3338@oddish> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201211200815.19192.hselasky@c2i.net> Cc: Mark Johnston X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 07:13:42 -0000 On Tuesday 20 November 2012 03:57:22 Mark Johnston wrote: > Hello all, > > I recently bought a PL-2303 USB to serial converter (VID 0x067b, DID > 0x2303) to use with an ARM board. When I start cu(1) and power on the > board no messages show up, and if I enter any input, cu exits without > printing anything and uplcom detaches and reinitializes itself. No error > messages are printed by the kernel - all I see is that uplcom(4) > disconnects and reattaches. > > After some debugging I found that when the USB stack sends a > ENDPOINT_HALT clear to the OUT bulk endpoint, the hw seems to respond > with an endpoint stalled error, and after that, the uplcom callbacks are > called with error set to USB_ERROR_CANCELLED. I looked at the Linux > driver for this device and found the following code in pl2303.c: > > if (priv->type != HX) { > usb_clear_halt(serial->dev, port->write_urb->pipe); > usb_clear_halt(serial->dev, port->read_urb->pipe); > } else { > /* reset upstream data pipes */ > pl2303_vendor_write(8, 0, serial); > pl2303_vendor_write(9, 0, serial); > } > > Unfortunately, I couldn't find any datasheets which indicate what these > vendor-specific commands mean. However I ended up with the patch below, > and now the device works perfectly. :) > In particular, it seems that we don't want to send a clear ENDPOINT_HALT > request to the HX variant of the device, which is what I have. > > I noticed that the device still seems to work if I omit the vendor > commands, and being a total USB newbie I thought I'd ask the following > questions: > > 1. What exactly is the purpose of clearing ENDPOINT_HALT when a > userspace program attaches to a device? Is it just to make sure that the > device fw is in some known good state before starting to transmit data? Hi, The purpose is to ensure that the so-called data toggle is reset to zero. If a packet is sent using the wrong data-toggle, it will simply get dropped. This is not so important for Serial devices, but for other device classes it is. If a USB device does not support clear-stall, it is not complying with the basics of the USB standards defined at usb.org, and I think it is not USB certified either. > > 2. uplcom(4) tries to clear any stalls after an error in its r/w and > intr callbacks. Is there some way I can trigger an error so that I can > test and fix that code too? > Does the device choke on clear-stall? You can test that simply by adding a sysctl to the code, which you set to make the code go to the error case upon transfer completion. I suggest you look at storage/umass.c and the reset states for an example on how to make a non-default asynchronous control transfer. When you have a patch I can commit it. --HPS