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>