On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
> >>>>> "Johan" == Johan Hovold <jo...@kernel.org> writes:
>
> [...]
>
> Johan> Ok, and you were using a terminal program such as minicom that
> Johan> properly configures the port for say 8-bit words?
>
> I was using GNU screen, which I don't specifically configure to be
> 8-bits, but I retried with minicom and specifically set a different byte
> size (non-8) and then set it back to 8, and saw the same 5-bit like
> behavior.
Ok, try sticking to minicom for any further tests just to be sure.
> Johan> [...] But if I configure the port for 5-bit words, I get the
> Johan> exact sequence you describe (i.e. the three most-significant bits
> Johan> are masked out).
>
> Johan> So my guess is that either you are not configuring the port
> Johan> correctly (and are using the default settings), or the driver
> Johan> fails to configure the port (and you are also stuck with the
> Johan> default settings).
>
> Johan> This may be a bit of long shot (or maybe not) but could you try
> Johan> the below patch on top of usb-next as well? [...]
>
> Your patch seems to have fixed it! Yay!
Interesting. I dug through the archives and found a report from Eddi De
Pieri which seems to have hit the same issue:
https://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
The weird part is I appear to have the same device, and it works fine
without that change.
Could you try and just commenting out that register write in a mainline
kernel (or my usb-linus branch) to make sure the changes in -next did
not cause the issues you still see when connected to a pl2303.
Are you using minicom on both ends with 115200 8N1 which appears to
work reliably, by the way?
> Johan> What is the lsusb -v output for you device? And what chip version
> Johan> is reported when connect the device if you enable dynamic
> Johan> debugging on usb-next (e.g. use "modprobe ch341 dyndbg==p").
>
> # lsusb -v -d 1a86:7523
>
> Bus 006 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 8
> idVendor 0x1a86 QinHeng Electronics
> idProduct 0x7523 HL-340 USB-Serial adapter
> bcdDevice 2.54
> iManufacturer 0
> iProduct 2 USB2.0-Ser!
The descriptors of my CH340G match apart from here where mine has
iProduct 2 USB2.0-Serial
> dmesg shows this after reloading the ch341 module after rmmod/modprobe
> as above:
>
> [ 812.709627] usbcore: registered new interface driver ch341
> [ 812.709643] usbserial: USB Serial support registered for ch341-uart
> [ 824.444092] usb 6-2: new full-speed USB device number 4 using uhci_hcd
> [ 824.622102] usb 6-2: New USB device found, idVendor=1a86, idProduct=7523
> [ 824.622107] usb 6-2: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [ 824.622111] usb 6-2: Product: USB2.0-Ser!
> [ 824.626324] ch341 6-2:1.0: ch341-uart converter detected
> [ 824.626421] usb 6-2: ch341_control_in(c0,5f,0000,0000,ffff8d7fb5e77e80,8)
> [ 824.628153] usb 6-2: Chip version: 0x30
Same version reported here too.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
