On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote: > >>>>> "Johan" == Johan Hovold <johan@xxxxxxxxxx> 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_eGpii0h8HXxOkLjnhhfPw@xxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
