Date: Tue, 20 Nov 2012 08:15:19 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@freebsd.org Cc: Mark Johnston <markjdb@gmail.com> Subject: Re: [patch] fix uplcom(4) clear stall logic for PL2303HX Message-ID: <201211200815.19192.hselasky@c2i.net> In-Reply-To: <20121120025722.GA3338@oddish> References: <20121120025722.GA3338@oddish>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211200815.19192.hselasky>