On Sat, Jan 09, 2021 at 08:26:26AM -0600, Joe Abbott wrote: > Hi Johan, > > > Please keep the USB list on CC. > I'm sorry, I don't know what you mean. You're only replying to me instead of replying to "all" so that the USB mailing list is CCed. We don't do kernel development in private so please make sure that your mails do not drop the list from CC. I've added linux-usb@xxxxxxxxxxxxxxx back on CC in my replies. > Here's dmesg after debug turned on and 'stty 110 cs7 parenb evenp -F > /dev/ttyUSB0': > [ 315.112142] pl2303 ttyUSB0: pl2303_set_control_lines - 03 > [ 315.115032] pl2303 ttyUSB0: pl2303_get_line_request - 80 25 00 00 00 00 08 > [ 315.115038] pl2303 ttyUSB0: data bits = 7 > [ 315.115041] pl2303 ttyUSB0: baud requested = 110 > [ 315.115045] pl2303 ttyUSB0: baud set = 110 > [ 315.115048] pl2303 ttyUSB0: stop bits = 1 > [ 315.115051] pl2303 ttyUSB0: parity = even > [ 315.116032] pl2303 ttyUSB0: pl2303_set_line_request - d5 0e 00 80 00 02 07 So as expected, your 5.0 Mint kernel behaves just like mainline: pl2303_set_line_request - d5 0e 00 80 00 02 07 > [ 315.116037] pl2303 6-1:1.0: pl2303_vendor_write - [0000] = 00 > > I have some windows wireshark usb captures for 110 and 9600 taken > while using putty. > I don't know how to interpret them. What is the best way to send them to you? Look for the set-line-request control request: bmRequestType 0x21 bRequest 0x20 (SET_LINE_REQUEST) wValue 0 wIndex 0 wLength 7 the data stage should contain the corresponding 7 bytes of request data for 110/cs7/parenb: d5 0e 00 80 00 02 07 where the first four bytes encodes the baud rate (either directly or as for 110 baud using divisors, see the code for details). I'm afraid I don't have time to be reverse-engineering this myself, but if you manage to find a difference in how the Windows driver configures your device we may be able to figure out how to get 110 baud working. Johan
