cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)

(Sorry if this is a double-post. Previous message appears to have dissapeared or been rejected in transit. )

This is a report of the bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=1965527. I was asked to post the bisection results by Hans de Goede. Here is the bug information for reference:

1. Please describe the problem:

For my development work, I use several ESP32 boards from Espressif. On Fedora, these modules are plugged as USB serial devices, managed via the cp210x module, and show under /dev/ttyUSB0 .

On Fedora 34, up until kernel-5.11.21-300.fc34.x86_64, this setup worked correctly.

Under recently-released kernels kernel-5.12.5-300.fc34.x86_64 and kernel-5.12.6-300.fc34.x86_64, this setup is now broken. When I plug the board, the module loads as usual and shows up under /dev/ttyUSB0. However, *any* attempt to read or write to the port fails. For example, using miniterm.py from python3-pyserial-3.4-10.fc34.noarch:

Traceback (most recent call last):
File "/usr/bin/miniterm.py", line 976, in <module>

     main()

File "/usr/bin/miniterm.py", line 932, in main
serial_instance.open()
File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 288, in open
self._update_rts_state()
File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 627, in _update_rts_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

At the same time, the following appears in the system logs:

may 27 16:04:55 karlalex-asus kernel: usb 1-10: new full-speed USB device number 6 using xhci_hcd
may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
may 27 16:04:55 karlalex-asus kernel: usb 1-10: Product: CP2102N USB to UART Bridge Controller
may 27 16:04:55 karlalex-asus kernel: usb 1-10: Manufacturer: Silicon Labs
may 27 16:04:55 karlalex-asus kernel: usb 1-10: SerialNumber: 18c0ecf00d0aea119fe0ae442473482f
may 27 16:04:55 karlalex-asus mtp-probe[3272]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
may 27 16:04:55 karlalex-asus mtp-probe[3272]: bus: 1, device: 6 was not an MTP device
may 27 16:04:55 karlalex-asus kernel: usbcore: registered new interface driver cp210x
may 27 16:04:55 karlalex-asus kernel: usbserial: USB Serial support registered for cp210x
may 27 16:04:55 karlalex-asus kernel: cp210x 1-10:1.0: cp210x converter detected
may 27 16:04:55 karlalex-asus kernel: usb 1-10: cp210x converter now attached to ttyUSB0
may 27 16:04:55 karlalex-asus mtp-probe[3287]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
may 27 16:04:55 karlalex-asus mtp-probe[3287]: bus: 1, device: 6 was not an MTP device
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus python3[3292]: detected unhandled Python exception in '/usr/bin/miniterm.py'
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus abrt-server[3293]: Deleting problem directory Python3-2021-05-27-16:04:56-3292 (dup of Python3-2021-05-27-14:26:21-17653) may 27 16:04:56 karlalex-asus abrt-notification[3312]: [🡕] Process 17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError exception

The messages with "failed set request..." are abnormal.

Worked around by downgrading the kernel to any 5.11.x version. Tested with kernel-5.11.21-300.fc34.x86_64 and kernel-5.11.12-300.fc34.x86_64

Module cp210x from kernel 5.11 works without errors with ESP32 when compiled under 5.12.x after applying commit c5d1448fa353242635fa3e1fed6ab4558e0e7d9a (USB: serial: make remove callback return void) on top of it. This allows bisection without rebooting.

Bisection points me to this:

f61309d9c96a308465bec9d2e5206da265b075a0 is the first bad commit commit f61309d9c96a308465bec9d2e5206da265b075a0

Author: Johan Hovold <[email protected]  <mailto:[email protected]>>
Date:   Mon Jan 18 12:13:27 2021 +0100

USB: serial: cp210x: set IXOFF thresholds

At least CP2102 requires the XON/XOFF limits to be initialised in order for software input flow control (IXOFF) to work. Specifically, XOFF is never sent if the XOFF limit is left at its default value of zero.

Set the limits so that input is throttled when the FIFO free level drops below 128 bytes and restarted when the FIFO fill level drops below 128 bytes.

Note that the threshold values have been chosen so that they can be used also with CP2105 which has the smallest FIFO of the currently supported device types (288 byte for the SCI port). If needed the limits can be made device specific later.

Reviewed-by Greg Kroah-Hartman <[email protected] <mailto:[email protected]>>

Signed-off-by Johan Hovold <[email protected] <mailto:[email protected]>>

If I manually revert commit f61309d9c96a308465bec9d2e5206da265b075a0 from cp210x.c from 5.12.7, it works correctly. Further proof that this commit introduced the bug.

Quoted 90 lines · Alex Villacís Lasso

(Sorry if this is a double-post. Previous message appears to have dissapeared or been rejected in transit. )

This is a report of the bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=1965527. I was asked to post the bisection results by Hans de Goede. Here is the bug information for reference:

1. Please describe the problem:

For my development work, I use several ESP32 boards from Espressif. On Fedora, these modules are plugged as USB serial devices, managed via the cp210x module, and show under /dev/ttyUSB0 .

On Fedora 34, up until kernel-5.11.21-300.fc34.x86_64, this setup worked correctly.

Under recently-released kernels kernel-5.12.5-300.fc34.x86_64 and kernel-5.12.6-300.fc34.x86_64, this setup is now broken. When I plug the board, the module loads as usual and shows up under /dev/ttyUSB0. However, *any* attempt to read or write to the port fails. For example, using miniterm.py from python3-pyserial-3.4-10.fc34.noarch:

Traceback (most recent call last):
File "/usr/bin/miniterm.py", line 976, in <module>
main()
File "/usr/bin/miniterm.py", line 932, in main
serial_instance.open()
File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 288, in open
self._update_rts_state()
File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 627, in _update_rts_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

At the same time, the following appears in the system logs:

may 27 16:04:55 karlalex-asus kernel: usb 1-10: new full-speed USB device number 6 using xhci_hcd
may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
may 27 16:04:55 karlalex-asus kernel: usb 1-10: Product: CP2102N USB to UART Bridge Controller
may 27 16:04:55 karlalex-asus kernel: usb 1-10: Manufacturer: Silicon Labs
may 27 16:04:55 karlalex-asus kernel: usb 1-10: SerialNumber: 18c0ecf00d0aea119fe0ae442473482f
may 27 16:04:55 karlalex-asus mtp-probe[3272]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
may 27 16:04:55 karlalex-asus mtp-probe[3272]: bus: 1, device: 6 was not an MTP device
may 27 16:04:55 karlalex-asus kernel: usbcore: registered new interface driver cp210x
may 27 16:04:55 karlalex-asus kernel: usbserial: USB Serial support registered for cp210x
may 27 16:04:55 karlalex-asus kernel: cp210x 1-10:1.0: cp210x converter detected
may 27 16:04:55 karlalex-asus kernel: usb 1-10: cp210x converter now attached to ttyUSB0
may 27 16:04:55 karlalex-asus mtp-probe[3287]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
may 27 16:04:55 karlalex-asus mtp-probe[3287]: bus: 1, device: 6 was not an MTP device
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus python3[3292]: detected unhandled Python exception in '/usr/bin/miniterm.py'
may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
may 27 16:04:56 karlalex-asus abrt-server[3293]: Deleting problem directory Python3-2021-05-27-16:04:56-3292 (dup of Python3-2021-05-27-14:26:21-17653) may 27 16:04:56 karlalex-asus abrt-notification[3312]: [🡕] Process 17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError exception

The messages with "failed set request..." are abnormal.

Worked around by downgrading the kernel to any 5.11.x version. Tested with kernel-5.11.21-300.fc34.x86_64 and kernel-5.11.12-300.fc34.x86_64 Module cp210x from kernel 5.11 works without errors with ESP32 when compiled under 5.12.x after applying commit c5d1448fa353242635fa3e1fed6ab4558e0e7d9a (USB: serial: make remove callback return void) on top of it. This allows bisection without rebooting.

Bisection points me to this:

f61309d9c96a308465bec9d2e5206da265b075a0 is the first bad commit commit f61309d9c96a308465bec9d2e5206da265b075a0

Author: Johan Hovold <[email protected]  <mailto:[email protected]>>
Date:   Mon Jan 18 12:13:27 2021 +0100

USB: serial: cp210x: set IXOFF thresholds

At least CP2102 requires the XON/XOFF limits to be initialised in order for software input flow control (IXOFF) to work. Specifically, XOFF is never sent if the XOFF limit is left at its default value of zero.

Set the limits so that input is throttled when the FIFO free level drops below 128 bytes and restarted when the FIFO fill level drops below 128 bytes.

Note that the threshold values have been chosen so that they can be used also with CP2105 which has the smallest FIFO of the currently supported device types (288 byte for the SCI port). If needed the limits can be made device specific later.

Quoted 5 lines

Reviewed-by Greg Kroah-Hartman <[email protected] <mailto:[email protected]>>

Signed-off-by Johan Hovold <[email protected] <mailto:[email protected]>>

If I manually revert commit f61309d9c96a308465bec9d2e5206da265b075a0 from cp210x.c from 5.12.7, it works correctly. Further proof that this commit introduced the bug.

Thanks for the detailed report.

I got another report of this issue off-list a few days ago, but I haven't got any replies to my follow-up questions from that reporter yet.

I can't seem to reproduce the issue here and the other reporter only saw this for some CP2102N which seems to suggest that there's some interaction with the device configuration at play here too.

The symptoms appear to be consistent with the device still having hardware flow control enabled while the driver thinks it is disabled. The IXON/IXOFF limits are set in the same request and this might explain why things get out of sync, for example, if 128/128 limits are rejected by your device in its current configuration. But that's still to be determined.

First, can you enable dynamic debugging in the driver through debugfs:

         echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control

or when loading the module:

         modprobe cp210x dyndbg==p

and send me the logs from when connecting the device and running you terminal program.

After the terminal program fails, try just to issue a

cat /dev/ttyUSB0

press control-C and then include the logs for that too.

For completeness, also include the output of

stty -F /dev/ttyUSB0 -a

after re-connecting the device and before and after running the terminal program.

Johan

Here is the full result of the test I performed. First I installed the distro kernel update, kernel-5.12.8-300.fc34.x86_64, then rebooted. Anything with a date is the journalctl output. Everything else is console input and output. I have pasted the relevant journalctl messages immediately after the command or action that triggered them.

$ miniterm.py /dev/ttyUSB0 115200
Traceback (most recent call last):
   File "/usr/bin/miniterm.py", line 976, in <module>
     main()
   File "/usr/bin/miniterm.py", line 932, in main
     serial_instance.open()
   File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 
288, in open
     self._update_rts_state()
   File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 
627, in _update_rts_state
     fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

jun 01 09:23:43 karlalex-asus systemd[1665]: Started VTE child process 3306 launched by gnome-terminal-server process 2856.
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x40
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202

jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 01 09:23:55 karlalex-asus python3[3362]: detected unhandled Python exception in '/usr/bin/miniterm.py'
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

I note that the mere act of running stty -a on the device also triggers the error.

Quoted 37 lines · Alex Villacís Lasso

Here is the full result of the test I performed. First I installed the distro kernel update, kernel-5.12.8-300.fc34.x86_64, then rebooted. Anything with a date is the journalctl output. Everything else is console input and output. I have pasted the relevant journalctl messages immediately after the command or action that triggered them.

$ miniterm.py /dev/ttyUSB0 115200
Traceback (most recent call last):
    File "/usr/bin/miniterm.py", line 976, in <module>
      main()
    File "/usr/bin/miniterm.py", line 932, in main
      serial_instance.open()
    File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line
288, in open
      self._update_rts_state()
    File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line
627, in _update_rts_state
      fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

jun 01 09:23:43 karlalex-asus systemd[1665]: Started VTE child process 3306 launched by gnome-terminal-server process 2856.
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x40
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202

Quoted 8 lines

jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 01 09:23:55 karlalex-asus python3[3362]: detected unhandled Python exception in '/usr/bin/miniterm.py'
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:23:55 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

Thanks a lot for this.

Could you try applying the below patch, and with debugging enabled

1. plug the device in
2. start the terminal program

and then send me the logs?

This should show the current device settings which appear to have flow control enabled (which the driver fails to disable).

Quoted 2 lines

I note that the mere act of running stty -a on the device also triggers the error.

Yeah, you'll see this error on every open/close when the driver tries to assert/deassert RTS.

Johan

From 736c4c099591317d55a20da627db3b148d8d71ca Mon Sep 17 00:00:00 2001
From: Johan Hovold <[email protected]>
Date: Tue, 1 Jun 2021 17:29:01 +0200
Subject: [PATCH] USB: cp210x: add flow-control debugging

Signed-off-by Johan Hovold <[email protected]>

---
  drivers/usb/serial/cp210x.c | 6 ++++++
  1 file changed, 6 insertions(+)

drivers/usb/serial/cp210x.c +0 -0

index ee595d1bea0a..92382798b574 100644
@@ -1159,6 +1159,12 @@ static void cp210x_set_flow_control(struct tty_struct *tty,
  	ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
  	flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);

Quoted 9 lines · Johan Hovold

Could you try applying the below patch, and with debugging enabled

1. plug the device in
2. start the terminal program

and then send me the logs?

This should show the current device settings which appear to have flow control enabled (which the driver fails to disable).

$ miniterm.py /dev/ttyUSB0 115200
Traceback (most recent call last):
   File "/usr/bin/miniterm.py", line 976, in <module>
     main()
   File "/usr/bin/miniterm.py", line 932, in main
     serial_instance.open()
   File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 
288, in open
     self._update_rts_state()
   File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 
627, in _update_rts_state
     fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 0, xoff_limit = 0

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x40

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

Quoted 10 lines · Alex Villacís Lasso

Quoted 9 lines · Johan Hovold

Could you try applying the below patch, and with debugging enabled

1. plug the device in
2. start the terminal program

and then send me the logs?

This should show the current device settings which appear to have flow control enabled (which the driver fails to disable).

Thanks again for the log.

Quoted 14 lines

$ miniterm.py /dev/ttyUSB0 115200
Traceback (most recent call last):
    File "/usr/bin/miniterm.py", line 976, in <module>
      main()
    File "/usr/bin/miniterm.py", line 932, in main
      serial_instance.open()
    File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line
288, in open
      self._update_rts_state()
    File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line
627, in _update_rts_state
      fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe

Quoted 4 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00

So the default device settings are the same as for my device and hardware flow control is disabled.

Quoted 2 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 0, xoff_limit = 0

Defaults to zero here too.

Quoted 2 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01

Here IXON is enabled (default termios), but the IXOFF limits are also updated to 128/128.

Quoted 4 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

And the next SET_MHS (modem handshaking) request fails (for RTS, as can be seen below).

Quoted 4 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01

The requested settings appear to have taken effect.

Quoted 2 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128

And the limits have been updated.

Quoted 2 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x40

Here DTR and RTS are asserted, and flow control disabled.

Quoted 2 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101

DTR can still be changed.

Quoted 4 lines

jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

But RTS cannot be changed, just as if auto-RTS is enabled (even if it is not reported back).

This may be a little far-fetched but can you send me the logs (debugging again enabled) from when:

1. plugging the device in
2. stty -F /dev/ttyUSB0 ixon ixoff
3. stty -F /dev/ttyUSB0 crtscts -ixon -ixoff
4. cat /dev/ttyUSB0 # + CTRL-C

No need to run the terminal program.

If you could also apply the below debugging patch (on top of the previous one) which will dump some device settings during probe before doing the above that would be great.

Hopefully this will gives some more clues but otherwise I'll probably just leave the default IXOFF limits for CP2102N to fix the regression.

Johan

From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
From: Johan Hovold <[email protected]>
Date: Wed, 2 Jun 2021 16:23:21 +0200
Subject: [PATCH] USB: serial: cp210x: dump communication properties

---
  drivers/usb/serial/cp210x.c | 33 +++++++++++++++++++++++++++++++++
  1 file changed, 33 insertions(+)

drivers/usb/serial/cp210x.c +31 -0

index 89da00de9739..f5c9e21538f8 100644
@@ -1843,6 +1843,37 @@ static void cp210x_gpio_remove(struct usb_serial *serial)
 
  #endif
 
+static void cp210x_dump_props(struct usb_serial_port *port)
+{
+	struct usb_device *udev = port->serial->dev;
+	void *buf;
+	int ret;
+
+	buf = kzalloc(256, GFP_KERNEL);
+	if (!buf)
+		return;
+
+	ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+			CP210X_GET_PROPS, REQTYPE_INTERFACE_TO_HOST, 0,
+			cp210x_interface_num(port->serial), buf, 256,
+			USB_CTRL_GET_TIMEOUT);
+	if (ret < 52) {
+		dev_err(&port->dev, "failed to get props: %d\n", ret);
+		goto out;
+	}
+
+	dev_dbg(&port->dev, "wLength = %u\n", le16_to_cpup(buf));
+	dev_dbg(&port->dev, "ulMaxTxQueue = %u\n", le32_to_cpup(buf + 12));
+	dev_dbg(&port->dev, "ulMaxRxQueue = %u\n", le32_to_cpup(buf + 16));
+	dev_dbg(&port->dev, "ulProvSubType = %u\n", le32_to_cpup(buf + 24));
+	dev_dbg(&port->dev, "ulProvCapabilities = 0x%02x\n", le32_to_cpup(buf + 28));
+	dev_dbg(&port->dev, "ulSettableParams = 0x%02x\n", le32_to_cpup(buf + 32));
+	dev_dbg(&port->dev, "ulCurrentTx-Queue = %u\n", le32_to_cpup(buf + 44));
+	dev_dbg(&port->dev, "ulCurrentRx-Queue = %u\n", le32_to_cpup(buf + 48));
+out:
+	kfree(buf);
+}
+
  static int cp210x_port_probe(struct usb_serial_port *port)
  {
  	struct usb_serial *serial = port->serial;

Quoted 16 lines · Johan Hovold

This may be a little far-fetched but can you send me the logs (debugging again enabled) from when:

1. plugging the device in
2. stty -F /dev/ttyUSB0 ixon ixoff
3. stty -F /dev/ttyUSB0 crtscts -ixon -ixoff
4. cat /dev/ttyUSB0 # + CTRL-C

No need to run the terminal program.

If you could also apply the below debugging patch (on top of the previous one) which will dump some device settings during probe before doing the above that would be great.

Hopefully this will gives some more clues but otherwise I'll probably just leave the default IXOFF limits for CP2102N to fix the regression.

Quoted 4 lines

From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
From: Johan Hovold <[email protected]>
Date: Wed, 2 Jun 2021 16:23:21 +0200
Subject: [PATCH] USB: serial: cp210x: dump communication properties

Tests with *both* patches applied:

<device plugged in>

jun 02 10:44:29 karlalex-asus kernel: usb 1-9: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00

jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities = 0x13f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams = 0x7f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue = 640
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue = 640

$ stty -F /dev/ttyUSB0 ixon ixoff

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 0, xoff_limit = 0 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

$ stty -F /dev/ttyUSB0 crtscts -ixon -ixoff

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x09, flow = 0x80

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00

[ +CC: the Silabs team and David who reported the same issue ]

Quick summary: Some CP2102N devices cannot use SET_MHS when ulXonLimit and ulXoffLimit are set to 128/128 even when auto-RTS is disabled. Leaving the default limits at 0/0 seems to work.

Tung, Hung and Pho, do you have some idea of what might be going on here?

The full thread is here:

	https://lore.kernel.org/r/[email protected]	

Quoted 15 lines · Alex Villacís Lasso

Quoted 14 lines · Johan Hovold

This may be a little far-fetched but can you send me the logs (debugging again enabled) from when:

1. plugging the device in
2. stty -F /dev/ttyUSB0 ixon ixoff
3. stty -F /dev/ttyUSB0 crtscts -ixon -ixoff
4. cat /dev/ttyUSB0 # + CTRL-C

No need to run the terminal program.

If you could also apply the below debugging patch (on top of the previous one) which will dump some device settings during probe before doing the above that would be great.

Quoted 7 lines

Quoted 6 lines

Hopefully this will gives some more clues but otherwise I'll probably just leave the default IXOFF limits for CP2102N to fix the regression.
From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
From: Johan Hovold <[email protected]>
Date: Wed, 2 Jun 2021 16:23:21 +0200
Subject: [PATCH] USB: serial: cp210x: dump communication properties

Tests with *both* patches applied:

Thanks again for running the new tests.

Quoted 7 lines

<device plugged in>
jun 02 10:44:29 karlalex-asus kernel: usb 1-9: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1

Quoted 8 lines

jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities = 0x13f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams = 0x7f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue = 640
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue = 640

This all matches the CP2102N I've got here and which can set RTS just fine also with the IXOFF limits set (unlike your device).

Unless there's some other configuration setting causing it would seem your device firmware is just buggy (and bcdDevice was not updated when it was fixed, which seems unlikely).

Quoted 12 lines

$ stty -F /dev/ttyUSB0 ixon ixoff

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 0, xoff_limit = 0 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

Quoted 8 lines

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43

Here IXOFF is enabled.

Quoted 4 lines

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

And setting the IXOFF limits only when software flow control is enabled would not work either.

Quoted 12 lines

$ stty -F /dev/ttyUSB0 crtscts -ixon -ixoff

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

Quoted 8 lines

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x09, flow = 0x80

Here hardware flow control is enabled.

Quoted 2 lines

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00

And then RTS can still be changed using the SET_FLOW command.

I just ran a quick test here and and leaving the ixoff_limit at zero essentially breaks software flow control since XOFF will be sent when there are only 7 characters in the receive buffer.

Since software flow control support was only recently added, we may have to accept that for CP2102N to fix the regression, but I'd really like to understand why your devices behave the way they do first and see if there's some other way to work around this.

Hopefully Silabs can provide some insight.

Also, could you try setting those limits to some other values and see if the SET_MHS (request 0x7) errors go away?

Setting both to 513 is supposed to give us 192/64 according to the datasheet which would be good enough, for example. Seems to work as documented here (at least for XOFF).

Johan

Quoted 14 lines · Johan Hovold

I just ran a quick test here and and leaving the ixoff_limit at zero essentially breaks software flow control since XOFF will be sent when there are only 7 characters in the receive buffer.

Since software flow control support was only recently added, we may have to accept that for CP2102N to fix the regression, but I'd really like to understand why your devices behave the way they do first and see if there's some other way to work around this.

Hopefully Silabs can provide some insight.

Also, could you try setting those limits to some other values and see if the SET_MHS (request 0x7) errors go away?

Quoted 3 lines

Setting both to 513 is supposed to give us 192/64 according to the datasheet which would be good enough, for example. Seems to work as documented here (at least for XOFF).

I am starting to suspect that the root cause is that the 0x07 command (CP210X_SET_MHS macro in the code) is invalid to send, if the device has been previously programmed with nonzero ulXonLimit/ulXoffLimit. When the patch programs both limits back to 0, the command succeeds.

With this patch, the miniterm.py program sort of keeps running and shows output. Not a perfect patch by any means, since some failures still happen:

$ miniterm.py /dev/ttyUSB0 115200
<program waits for input>

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x00 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 0, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x01 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 0

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x01

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x01, flow = 0x40 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 0, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101

Quoted 16 lines · Alex Villacís Lasso

Quoted 14 lines · Johan Hovold

I just ran a quick test here and and leaving the ixoff_limit at zero essentially breaks software flow control since XOFF will be sent when there are only 7 characters in the receive buffer.

Since software flow control support was only recently added, we may have to accept that for CP2102N to fix the regression, but I'd really like to understand why your devices behave the way they do first and see if there's some other way to work around this.

Hopefully Silabs can provide some insight.

Also, could you try setting those limits to some other values and see if the SET_MHS (request 0x7) errors go away?

Quoted 8 lines

Quoted 3 lines

Setting both to 513 is supposed to give us 192/64 according to the datasheet which would be good enough, for example. Seems to work as documented here (at least for XOFF).

I am starting to suspect that the root cause is that the 0x07 command (CP210X_SET_MHS macro in the code) is invalid to send, if the device has been previously programmed with nonzero ulXonLimit/ulXoffLimit. When the patch programs both limits back to 0, the command succeeds.

Right, that's what the bisection and logs seem to suggest.

cp210x.c line 1207

Quoted 13 lines

I am attaching the patch I used, which is the combination of both debug patches, plus this change:

cp210x.c renamed from cp210x.c.orig-5.12.8 +2 -2

@@ -1195,11 +1201,14 @@
         else
                 flow_repl &= ~CP210X_SERIAL_AUTO_TRANSMIT;
 
-       flow_ctl.ulXonLimit = cpu_to_le32(128);
-       flow_ctl.ulXoffLimit = cpu_to_le32(128);
+       flow_ctl.ulXonLimit = (I_IXON(tty)) ? cpu_to_le32(128) : 
 cpu_to_le32(0);
+       flow_ctl.ulXoffLimit = (I_IXOFF(tty)) ? cpu_to_le32(128) : 
 cpu_to_le32(0);

These are both only needed when IXOFF (input flow control) is used (IXON is for output flow control and does not use these limits).

And the fact that they cause a mostly unrelated error when set still indicates a firmware bug. That doesn't mean it may be possible to work around it somehow of course.

Quoted 6 lines

With this patch, the miniterm.py program sort of keeps running and shows output. Not a perfect patch by any means, since some failures still happen:

$ miniterm.py /dev/ttyUSB0 115200
<program waits for input>

Quoted 10 lines

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x00 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 0, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x01 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 0

Another data point: just setting the XON limit is enough to trigger the bug.

Quoted 4 lines

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

As here SET_MHS fails.

Quoted 4 lines

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x01

Quoted 8 lines

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x01, flow = 0x40 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 0, xoff_limit = 0 jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101

And when XON is reset, settings RTS again works.

For completeness you could try setting only the XOFF limit and see if that alone is sufficient to trigger the issue.

But please also try hardcoding both limits to 513 as I mentioned above and see if that makes any difference.

[ +CC: the Silabs team and David who reported the same issue ]

Quick summary: Some CP2102N devices cannot use SET_MHS when ulXonLimit and ulXoffLimit are set to 128/128 even when auto-RTS is disabled. Leaving the default limits at 0/0 seems to work.

Tung, Hung and Pho, do you have some idea of what might be going on here?

The full thread is here:

        https://lore.kernel.org/r/[email protected]

Quoted 19 lines · Alex Villacís Lasso

Quoted 16 lines · Johan Hovold

This may be a little far-fetched but can you send me the logs (debugging again enabled) from when:

1. plugging the device in
2. stty -F /dev/ttyUSB0 ixon ixoff
3. stty -F /dev/ttyUSB0 crtscts -ixon -ixoff
4. cat /dev/ttyUSB0 # + CTRL-C

No need to run the terminal program.

If you could also apply the below debugging patch (on top of the previous one) which will dump some device settings during probe before doing the above that would be great.

Hopefully this will gives some more clues but otherwise I'll probably just leave the default IXOFF limits for CP2102N to fix the regression.

Quoted 6 lines

Quoted 4 lines

From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
From: Johan Hovold <[email protected]>
Date: Wed, 2 Jun 2021 16:23:21 +0200
Subject: [PATCH] USB: serial: cp210x: dump communication properties

Tests with *both* patches applied:

Thanks again for running the new tests.

Quoted 5 lines

<device plugged in>

jun 02 10:44:29 karlalex-asus kernel: usb 1-9: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00

Quoted 12 lines

jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1 jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities = 0x13f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams = 0x7f
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue = 640
jun 02 10:44:29 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue = 640

This all matches the CP2102N I've got here and which can set RTS just fine also with the IXOFF limits set (unlike your device).

Unless there's some other configuration setting causing it would seem your device firmware is just buggy (and bcdDevice was not updated when it was fixed, which seems unlikely).

Quoted 12 lines

$ stty -F /dev/ttyUSB0 ixon ixoff

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 0, xoff_limit = 0 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

Quoted 8 lines

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43

Here IXOFF is enabled.

Quoted 4 lines

jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 02 10:45:40 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32

And setting the IXOFF limits only when software flow control is enabled would not work either.

Quoted 12 lines

$ stty -F /dev/ttyUSB0 crtscts -ixon -ixoff

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x43 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303

Quoted 8 lines

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x03
jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128 jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x09, flow = 0x80

Here hardware flow control is enabled.

Quoted 2 lines

jun 02 10:46:41 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00

And then RTS can still be changed using the SET_FLOW command.

I just ran a quick test here and and leaving the ixoff_limit at zero essentially breaks software flow control since XOFF will be sent when there are only 7 characters in the receive buffer.

Since software flow control support was only recently added, we may have to accept that for CP2102N to fix the regression, but I'd really like to understand why your devices behave the way they do first and see if there's some other way to work around this.

Hopefully Silabs can provide some insight.

Also, could you try setting those limits to some other values and see if the SET_MHS (request 0x7) errors go away?

Setting both to 513 is supposed to give us 192/64 according to the datasheet which would be good enough, for example. Seems to work as documented here (at least for XOFF).

Johan

I'm not sure if this matters, but I have been told that the failing boards have CP2102N chips with"A01" firmware. I tried to install SIlicon Labs Simplicity Studio on Windows because I read that it would be able to identify the firmware version of the device, but I couldn't actually figure out how to find the information. If someone can tell me a way to get the firmware version, I can check to see if it's different between the device that does exhibit this failure and the one that doesn't.

Quoted 7 lines

This all matches the CP2102N I've got here and which can set RTS just fine also with the IXOFF limits set (unlike your device).

Unless there's some other configuration setting causing it would seem your device firmware is just buggy (and bcdDevice was not updated when it was fixed, which seems unlikely).

Quoted 8 lines · David Frey

I'm not sure if this matters, but I have been told that the failing boards have CP2102N chips with"A01" firmware. I tried to install SIlicon Labs Simplicity Studio on Windows because I read that it would be able to identify the firmware version of the device, but I couldn't actually figure out how to find the information. If someone can tell me a way to get the firmware version, I can check to see if it's different between the device that does exhibit this failure and the one that doesn't.

That is definitely worth pursuing. The A01 is apparently EOLed and there's a later A02 and possibly even A03:

	https://www.silabs.com/community/interface/knowledge-base.entry.html/2020/03/31/how_to_determinecp2102nrevisiona01vsa02-DCJI

That page refers to that vendor tool "Simplicity Studio" as well as a Windows library described by

	https://www.silabs.com/documents/public/application-notes/AN978-cp210x-usb-to-uart-api-specification.pdf

that can be used to read out the firmware version on CP2102N and CP2108 (three bytes). We just need to figure out which vendor request the library (and tool) uses and we could key off of this in the driver if this turns out to be related to the firmware revision.

Quoted 17 lines · Johan Hovold

Quoted 8 lines · David Frey

I'm not sure if this matters, but I have been told that the failing boards have CP2102N chips with"A01" firmware. I tried to install SIlicon Labs Simplicity Studio on Windows because I read that it would be able to identify the firmware version of the device, but I couldn't actually figure out how to find the information. If someone can tell me a way to get the firmware version, I can check to see if it's different between the device that does exhibit this failure and the one that doesn't.

That is definitely worth pursuing. The A01 is apparently EOLed and there's a later A02 and possibly even A03:

	https://www.silabs.com/community/interface/knowledge-base.entry.html/2020/03/31/how_to_determinecp2102nrevisiona01vsa02-DCJI

That page refers to that vendor tool "Simplicity Studio" as well as a Windows library described by

Quoted 6 lines

	https://www.silabs.com/documents/public/application-notes/AN978-cp210x-usb-to-uart-api-specification.pdf

that can be used to read out the firmware version on CP2102N and CP2108 (three bytes). We just need to figure out which vendor request the library (and tool) uses and we could key off of this in the driver if this turns out to be related to the firmware revision.

I modified the patch that added cp210x_dump_props() function, to dump the raw buffer received using the print_hex_dump() kernel function. For my device, I get this output:

jun 07 10:00:51 karlalex-asus kernel: cp210x propdata: 00000000: 42 00 00 01 01 00 00 00 00 00 00 00 80 02 00 00  B............... jun 07 10:00:51 karlalex-asus kernel: cp210x propdata: 00000010: 80 02 00 00 c0 c6 2d 10 01 00 00 00 3f 01 00 00  ......-.....?... jun 07 10:00:51 karlalex-asus kernel: cp210x propdata: 00000020: 7f 00 00 00 ff ff 07 10 0f 00 07 1f 80 02 00 00  ................ jun 07 10:00:51 karlalex-asus kernel: cp210x propdata: 00000030: 80 02 00 00 00 00 00 00 00 00 00 00 33 00 2e 00  ............3... jun 07 10:00:51 karlalex-asus kernel: cp210x propdata: 00000040: 30 00                                            0.
jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66 jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640 jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640 jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1 jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities = 0x13f
jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams = 0x7f
jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue = 640
jun 07 10:00:51 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue = 640

According to the datasheet at
https://www.silabs.com/documents/public/application-notes/AN571.pdf , the data at offset 60 should be an Unicode string containing the device vendor, with the last 3 characters denoting the version. The datasheet gives an example of "SILABS USB Vx.y". However, my actual output decodes to just "3.0". Is this enough for a blacklisting decision?

I found an errata for A01 on here, but no mention if this particular bug:

        https://www.silabs.com/documents/public/pcns/190315471-CP2102N-Product-Revision-with-Datasheet-and-Errata-Update.pdf

Quoted 5 lines · Johan Hovold

I found an errata for A01 on here, but no mention if this particular bug:

        https://www.silabs.com/documents/public/pcns/190315471-CP2102N-Product-Revision-with-Datasheet-and-Errata-Update.pdf

I believe this document has some more errata details:
https://www.silabs.com/documents/public/errata/cp2102n-errata.pdf'

Quoted 9 lines · David Frey

Quoted 5 lines · Johan Hovold

I found an errata for A01 on here, but no mention if this particular bug:

        https://www.silabs.com/documents/public/pcns/190315471-CP2102N-Product-Revision-with-Datasheet-and-Errata-Update.pdf

I believe this document has some more errata details:
https://www.silabs.com/documents/public/errata/cp2102n-errata.pdf'

Thanks for the link.

This seems to confirm that this is a known issue with A01 that was fixed in A02:

3.6 CP2102N_E104 – IO Exception in .NET Applications when Manually Controlling RTS

The CP2102N uses the incorrect byte of the SERIAL_HANDFLOW structure
(https://msdn.microsoft.com/en-us/library/windows/hard-
ware/jj680685(v=vs.85).aspx) to control the RTS signal. Instead of looking at the first byte of FlowReplace, the device is reading the first byte of the XonLimit and interpreting that as the first byte of FlowReplace.

Applications written in .NET set the Xon/Xoff limits to 160, equal to 0xA0, which the CP2102N interprets as hardware flow control, and so it returns an error when manually setting RTS.

Now we just need to figure out how to determine the firmware revision.

Johan

I made a bit of progress. I found that CP210xManufacturing.dll was bundled with Simplicity Studio and in the same folder as the DLL was inspect_usbxpress.exe. It looks like that tool is able to report the firmware version of the device. In the output below, the first run is against the device that I am able to program successfully on any kernel and that shows firmware 1.0.6. The second run is against a device that I can't program and it shows firmware version 1.0.4. I recall reading some information that 1.0.6 is A02 and that 1.0.4 is A01, but I think there might have been another firmware revision that's also A01 (maybe 1.0.2?). I can't find the source of this information anymore. I'm going to try to figure out how to use wireshark to capture USB traffic now.

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = 1017bfe99d98e8118ea47540c3e5cfbd
Vid = 0
Pid = 0
PartNumber = 32
BoardID =
BoardCount = 0
FirmwareVersion = 1.0.6
Name = cp2102N version 1.0.6
Type = CP210x
Family = USBXpress
Locked = 1
}

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = f06e721e74e1ea11bd9ddc2d9a583cc7
Vid = 0
Pid = 0
PartNumber = 32

BoardID =
BoardCount = 0
FirmwareVersion = 1.0.4
Name = cp2102N version 1.0.4
Type = CP210x
Family = USBXpress
Locked = 1
}

Quoted 44 lines · David Frey

I made a bit of progress. I found that CP210xManufacturing.dll was bundled with Simplicity Studio and in the same folder as the DLL was inspect_usbxpress.exe. It looks like that tool is able to report the firmware version of the device. In the output below, the first run is against the device that I am able to program successfully on any kernel and that shows firmware 1.0.6. The second run is against a device that I can't program and it shows firmware version 1.0.4. I recall reading some information that 1.0.6 is A02 and that 1.0.4 is A01, but I think there might have been another firmware revision that's also A01 (maybe 1.0.2?). I can't find the source of this information anymore. I'm going to try to figure out how to use wireshark to capture USB traffic now.

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = 1017bfe99d98e8118ea47540c3e5cfbd
Vid = 0
Pid = 0
PartNumber = 32
BoardID =
BoardCount = 0
FirmwareVersion = 1.0.6
Name = cp2102N version 1.0.6
Type = CP210x
Family = USBXpress
Locked = 1
}

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = f06e721e74e1ea11bd9ddc2d9a583cc7
Vid = 0
Pid = 0
PartNumber = 32

Quoted 8 lines

BoardID =
BoardCount = 0
FirmwareVersion = 1.0.4
Name = cp2102N version 1.0.4
Type = CP210x
Family = USBXpress
Locked = 1
}

I configured wireshark on Windows to capture the USB traffic and I ran the inspect_usbxpress.exe. I believe the request/response where the firmware version is provided is in packets 38/39 in the attached trace. Perhaps the mailing list will strip the trace, so I will describe it a bit.

Setup packet:

   bmRequestType: 0xC0 (device-to-host, vendor, device recipient)
   bRequest: 255
   wValue: 0x0010
   wIndex: 0
   wLength: 3

Response Data: {0x01, 0x00, 0x04}

When I captured the trace for the other device, the response data was {0x01, 0x00, 0x06} indicating firmware version 1.0.6.

Let me know if there is any other information I can provide.

On Linux you can use manufacturing library to check firmware version.

Then it display some information of device:

Found 1 CP210x devices
Device 0:
Product String - serial number: "a0d16702d2a3e81187d86c93f375b2a8"
Product String - Description: "CP2102N USB to UART Bridge Controller"
Error: CP210x_GetProductString() failed to return Full Path, status = 0x2
Product String (unsafe) - CP210x_GETPRODUCTSTRING_SERIAL_NUMBER: "a0d16702d2a3e81187d86c93f375b2a8" Product String (unsafe) - CP210x_GETPRODUCTSTRING_DESCRIPTION: "CP2102N USB to UART Bridge Controller"
Error: CP210x_GetProductString(CP210x_GETPRODUCTSTRING_FULL_PATH) failed, status = 0x2 Part Number = 0x20
Firmware version = 0.1.1
Vendor ID = 0x10C4
Product ID = 0xEA60

The Firmware version is field that we need to looking for, it is formatted as major version; minor version; and patch.
The A01 have range <= 1.0.4 version. It have error "3.6 CP2102N_E104 – IO Exception in .NET Applications when Manually Controlling RTS" as the cp2102n-errata.pdf have mentioned.

Our recommend is you can chose 2 options:
- option 1: remove the set xon_limit and xoff_limit lines in driver, because our firmware automatically set these value to some default values (usually very small values) in its memory if it detect these values are zeros.

- option 2: archive Part Number and Firmware version,

   check if   (  (PART_NUMBER == CP2102N_QFN28) \
    || (PART_NUMBER == CP2102N_QFN24) \
    || (PART_NUMBER == CP2102N_QFN20))

and Firmware version <=1.0.4 set the xon_limit and xoff_limit to zeros, other while set to other values. This option are more suitable.

#define CP2102N_QFN28 0x20
#define CP2102N_QFN24 0x21
#define CP2102N_QFN20 0x22

Quoted 13 lines · David Frey

I made a bit of progress. I found that CP210xManufacturing.dll was bundled with Simplicity Studio and in the same folder as the DLL was inspect_usbxpress.exe. It looks like that tool is able to report the firmware version of the device. In the output below, the first run is against the device that I am able to program successfully on any kernel and that shows firmware 1.0.6. The second run is against a device that I can't program and it shows firmware version 1.0.4. I recall reading some information that 1.0.6 is A02 and that 1.0.4 is A01, but I think there might have been another firmware revision that's also A01 (maybe 1.0.2?). I can't find the source of this information anymore. I'm going to try to figure out how to use wireshark to capture USB traffic now.

Quoted 31 lines

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = 1017bfe99d98e8118ea47540c3e5cfbd
Vid = 0
Pid = 0
PartNumber = 32
BoardID =
BoardCount = 0
FirmwareVersion = 1.0.6
Name = cp2102N version 1.0.6
Type = CP210x
Family = USBXpress
Locked = 1
}

C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\inspect_usbxpress>.\inspect_usbxpress.exe -slist
serial_no =
deviceCount = 1
device (0) {
SoftIndex = 0
adapterLabel = CP2102N USB to UART Bridge Controller (ID:0)
SerialNo = f06e721e74e1ea11bd9ddc2d9a583cc7
Vid = 0
Pid = 0
PartNumber = 32

Quoted 8 lines

BoardID =
BoardCount = 0
FirmwareVersion = 1.0.4
Name = cp2102N version 1.0.4
Type = CP210x
Family = USBXpress
Locked = 1
}

I configured wireshark on Windows to capture the USB traffic and I ran the inspect_usbxpress.exe. I believe the request/response where the firmware version is provided is in packets 38/39 in the attached trace. Perhaps the mailing list will strip the trace, so I will describe it a bit.

Setup packet:
bmRequestType: 0xC0 (device-to-host, vendor, device recipient)
bRequest: 255
wValue: 0x0010
wIndex: 0
wLength: 3

Response Data: {0x01, 0x00, 0x04}

When I captured the trace for the other device, the response data was {0x01, 0x00, 0x06} indicating firmware version 1.0.6.

Let me know if there is any other information I can provide.

CP2102N revision A01 (firmware version <= 1.0.4) has a buggy flow-control implementation that uses the ulXonLimit instead of ulFlowReplace field of the flow-control settings structure (erratum CP2102N_E104).

A recent change that set the input software flow-control limits incidentally broke RTS control for these devices when CRTSCTS is not set as the new limits would always enable hardware flow control.

Fix this by explicitly disabling flow control for the buggy firmware versions and only updating the input software flow-control limits when IXOFF is requested. This makes sure that the terminal settings matches the default zero ulXonLimit (ulFlowReplace) for these devices.

Reported-by David Frey <[email protected]>

Reported-by Alex Villacís Lasso <[email protected]>

Fixes f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")

Cc [email protected] # 5.12

Signed-off-by Johan Hovold <[email protected]>

---
  drivers/usb/serial/cp210x.c | 64 ++++++++++++++++++++++++++++++++++---
  1 file changed, 59 insertions(+), 5 deletions(-)

David and Alex,

Would you mind testing this one with your CP2108N-A01? I've verified it against a CP2108N-A02 (fw 1.0.8) here.

Johan

drivers/usb/serial/cp210x.c +58 -5

index ee595d1bea0a..910bc965e6cd 100644
@@ -252,9 +252,11 @@ struct cp210x_serial_private {
  	u8			gpio_input;
  #endif
  	u8			partnum;
+	u32			fw_version;
  	speed_t			min_speed;
  	speed_t			max_speed;
  	bool			use_actual_rate;
+	bool			no_flow_control;
  };
 
  enum cp210x_event_state {

@@ -398,6 +400,7 @@ struct cp210x_special_chars {
 
  /* CP210X_VENDOR_SPECIFIC values */
  #define CP210X_READ_2NCONFIG	0x000E
+#define CP210X_GET_FW_VER_2N	0x0010
  #define CP210X_READ_LATCH	0x00C2
  #define CP210X_GET_PARTNUM	0x370B
  #define CP210X_GET_PORTCONFIG	0x370C

@@ -1122,6 +1125,7 @@ static bool cp210x_termios_change(const struct ktermios *a, const struct ktermio
  static void cp210x_set_flow_control(struct tty_struct *tty,
  		struct usb_serial_port *port, struct ktermios *old_termios)
  {
+	struct cp210x_serial_private *priv = usb_get_serial_data(port->serial);
  	struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
  	struct cp210x_special_chars chars;
  	struct cp210x_flow_ctl flow_ctl;

@@ -1129,6 +1133,15 @@ static void cp210x_set_flow_control(struct tty_struct *tty,
  	u32 ctl_hs;
  	int ret;
 
+	/*
+	 * Some CP2102N interpret ulXonLimit as ulFlowReplace (erratum
+	 * CP2102N_E104). Report back that flow control is not supported.
+	 */
+	if (priv->no_flow_control) {
+		tty->termios.c_cflag &= ~CRTSCTS;
+		tty->termios.c_iflag &= ~(IXON | IXOFF);
+	}
+
  	if (old_termios &&
  			C_CRTSCTS(tty) == (old_termios->c_cflag & CRTSCTS) &&
  			I_IXON(tty) == (old_termios->c_iflag & IXON) &&

@@ -1185,19 +1198,20 @@ static void cp210x_set_flow_control(struct tty_struct *tty,
  		port_priv->crtscts = false;
  	}
 
-	if (I_IXOFF(tty))
+	if (I_IXOFF(tty)) {
  		flow_repl |= CP210X_SERIAL_AUTO_RECEIVE;
-	else
+
+		flow_ctl.ulXonLimit = cpu_to_le32(128);
+		flow_ctl.ulXoffLimit = cpu_to_le32(128);
+	} else {
  		flow_repl &= ~CP210X_SERIAL_AUTO_RECEIVE;
+	}
 
  	if (I_IXON(tty))
  		flow_repl |= CP210X_SERIAL_AUTO_TRANSMIT;
  	else
  		flow_repl &= ~CP210X_SERIAL_AUTO_TRANSMIT;
 
-	flow_ctl.ulXonLimit = cpu_to_le32(128);
-	flow_ctl.ulXoffLimit = cpu_to_le32(128);
-
  	dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__,
  			ctl_hs, flow_repl);
 

@@ -1908,6 +1922,45 @@ static void cp210x_init_max_speed(struct usb_serial *serial)
  	priv->use_actual_rate = use_actual_rate;
  }
 
+static int cp210x_get_fw_version(struct usb_serial *serial, u16 value)
+{
+	struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+	u8 ver[3];
+	int ret;
+
+	ret = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST, value,
+			ver, sizeof(ver));
+	if (ret)
+		return ret;
+
+	dev_dbg(&serial->interface->dev, "%s - %d.%d.%d\n", __func__,
+			ver[0], ver[1], ver[2]);
+
+	priv->fw_version = ver[0] << 16 | ver[1] << 8 | ver[2];
+
+	return 0;
+}
+
+static void cp210x_determine_quirks(struct usb_serial *serial)
+{
+	struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+	int ret;
+
+	switch (priv->partnum) {
+	case CP210X_PARTNUM_CP2102N_QFN28:
+	case CP210X_PARTNUM_CP2102N_QFN24:
+	case CP210X_PARTNUM_CP2102N_QFN20:
+		ret = cp210x_get_fw_version(serial, CP210X_GET_FW_VER_2N);
+		if (ret)
+			break;
+		if (priv->fw_version <= 0x10004)
+			priv->no_flow_control = true;
+		break;
+	default:
+		break;
+	}
+}
+
  static int cp210x_attach(struct usb_serial *serial)
  {
  	int result;

Quoted 23 lines · Johan Hovold

CP2102N revision A01 (firmware version <= 1.0.4) has a buggy flow-control implementation that uses the ulXonLimit instead of ulFlowReplace field of the flow-control settings structure (erratum CP2102N_E104).

A recent change that set the input software flow-control limits incidentally broke RTS control for these devices when CRTSCTS is not set as the new limits would always enable hardware flow control.

Fix this by explicitly disabling flow control for the buggy firmware versions and only updating the input software flow-control limits when IXOFF is requested. This makes sure that the terminal settings matches the default zero ulXonLimit (ulFlowReplace) for these devices.

Reported-by David Frey <[email protected]>

Reported-by Alex Villacís Lasso <[email protected]>

Fixes f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")

Cc [email protected] # 5.12

Signed-off-by Johan Hovold <[email protected]>

---
  drivers/usb/serial/cp210x.c | 64 ++++++++++++++++++++++++++++++++++---
  1 file changed, 59 insertions(+), 5 deletions(-)

Quoted 4 lines

David and Alex,

Would you mind testing this one with your CP2108N-A01? I've verified it against a CP2108N-A02 (fw 1.0.8) here.

Applied patch and tested with ESP32 board under kernel 5.12.9:

jun 09 11:56:00 karlalex-asus kernel: cp210x 1-9:1.0:
cp210x_get_fw_version - 1.0.4

$ miniterm.py /dev/ttyUSB0 115200
<successful connect>

jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101
jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202

At least in my case, this patch fixes the regression for my workflow.

Quoted 24 lines · Alex Villacís Lasso

Quoted 23 lines · Johan Hovold

CP2102N revision A01 (firmware version <= 1.0.4) has a buggy flow-control implementation that uses the ulXonLimit instead of ulFlowReplace field of the flow-control settings structure (erratum CP2102N_E104).

A recent change that set the input software flow-control limits incidentally broke RTS control for these devices when CRTSCTS is not set as the new limits would always enable hardware flow control.

Fix this by explicitly disabling flow control for the buggy firmware versions and only updating the input software flow-control limits when IXOFF is requested. This makes sure that the terminal settings matches the default zero ulXonLimit (ulFlowReplace) for these devices.

Reported-by David Frey <[email protected]>

Reported-by Alex Villacís Lasso <[email protected]>

Fixes f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")

Cc [email protected] # 5.12

Signed-off-by Johan Hovold <[email protected]>

---
   drivers/usb/serial/cp210x.c | 64 ++++++++++++++++++++++++++++++++++---
   1 file changed, 59 insertions(+), 5 deletions(-)

Quoted 4 lines

Quoted 4 lines

David and Alex,

Would you mind testing this one with your CP2108N-A01? I've verified it against a CP2108N-A02 (fw 1.0.8) here.

I meant CP2102N here of course. It had been a long day...

Quoted 19 lines

Applied patch and tested with ESP32 board under kernel 5.12.9:
jun 09 11:56:00 karlalex-asus kernel: cp210x 1-9:1.0:
cp210x_get_fw_version - 1.0.4

$ miniterm.py /dev/ttyUSB0 115200
<successful connect>

jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384 jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101
jun 09 11:56:50 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202

Quoted 1 line

At least in my case, this patch fixes the regression for my workflow.

Thanks for confirming. Can I add a "Tested-by" tag for you as well?

And again, thanks for the detailed report, bisection and thorough testing throughout.

Johan