[ +CC: Adain, Grigori, Karl ]
On Wed, Dec 07, 2016 at 05:51:33PM -0800, Russell Senior wrote:
> >>>>> "Johan" == Johan Hovold <johan@xxxxxxxxxx> writes:
>
> >> I attach the tty's with GNU screen (but I have also tried microcom
> >> and minicom with the same results). This was my first experience
> >> with or even awareness of ch341. I have much more experience with
> >> pl2303 and somewhat less with ftdi. With these ch341, when I type in
> >> an 'a' on one terminal, I get 0x01 out the other terminal. If I type
> >> in a 'b', I get an 0x02, etc, on up to 'z' yielding 0x1a.
> >>
> >> I found your name/contact in the git commits.
> >>
> >> Any idea what is going on?
>
> Johan> Sounds like it could be related to an incorrect line setting
> Johan> (e.g. the devices are using 5-bit words). Some changes just went
> Johan> in that add support for changing this. Could you try building a
> Johan> kernel based on the usb-next branch of:
>
> Johan> git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
>
> Johan> and see if that works better?
>
> I built usb-next (3c3dd1e) and saw the same behavior. Loopback
> (connecting RX and TX) worked on pl2303-based usb-serial adapter (with
> PC levels, not TTL), and did not ('a' -> 0x01, 'b' -> 0x02, etc) with
> ch341-based usb-serial adapter (again with PC levels, measured MIN/MAX
> voltages with a DVM and saw, about -7V/+7V).
Ok, and you were using a terminal program such as minicom that properly
configures the port for say 8-bit words?
> I still suspect shoddy hardware. It would be nice to hear someone else
> with the ch341-based hardware to say it works for them.
I have a CH341 adapter (TTL) that works fine with usb-next (and
current mainline for that matter) and minicom in a loopback setup.
But if I configure the port for 5-bit words, I get the exact sequence
you describe (i.e. the three most-significant bits are masked out).
So my guess is that either you are not configuring the port correctly
(and are using the default settings), or the driver fails to configure
the port (and you are also stuck with the default settings).
This may be a bit of long shot (or maybe not) but could you try the
below patch on top of usb-next as well? Remember that this driver is the
result of reverse-engineering and we are only recently adding some more
structure to make sense of code that's been sitting there for quite some
time. One recently proposed changed modified what appears to be the
initial line-control settings from 5 to 8 bits. This should have no
effect as the settings are again updated at open, but perhaps your
device is quirky (and we have gotten reports about some other ch341 not
working with the mainline driver).
What is the lsusb -v output for you device? And what chip version is
reported when connect the device if you enable dynamic debugging on
usb-next (e.g. use "modprobe ch341 dyndbg==p").
Thanks,
Johan
>From c7d342f9dd2a0c330077e5a8c42045baaff1e281 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@xxxxxxxxxx>
Date: Thu, 8 Dec 2016 10:26:26 +0100
Subject: [PATCH] USB: serial: ch341: change initial LCR settings
Change the initial LCR setting to 8N1 and enable rx and tx.
This should have not effect as the LCR is again later updated at open,
but let's try anyway since we have gotten reports about ch341-devices
that appear to be stuck with 5-bit words.
Not-Yet-Signed-off-by: Johan Hovold <johan@xxxxxxxxxx>
---
drivers/usb/serial/ch341.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index 2597b83a8ae2..3b53188f0a12 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -223,7 +223,7 @@ static int ch341_configure(struct usb_device *dev, struct ch341_private *priv)
if (r < 0)
goto out;
- r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x2518, 0x0050);
+ r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x2518, 0x00c3);
if (r < 0)
goto out;
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
