[patch] fix uplcom(4) clear stall logic for PL2303HX
Hans Petter Selasky
hselasky at c2i.net
Tue Nov 20 07:13:42 UTC 2012
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
More information about the freebsd-usb
mailing list