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?


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.

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to