* cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
@ 2021-05-31 17:38 Alex Villacís Lasso
2021-06-01 7:50 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-05-31 17:38 UTC (permalink / raw)
To: linux-usb
(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
2. What is the Version-Release number of the kernel:
kernel-5.12.5-300.fc34.x86_64
kernel-5.12.6-300.fc34.x86_64
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
https://koji.fedoraproject.org/koji/packageinfo?packageID=8 <https://koji.fedoraproject.org/koji/packageinfo?packageID=8> :
Previously worked on kernel-5.11.21-300.fc34.x86_64 as explained above.
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
- Get device that shows as an USB port to be managed by cp210x module
- Plug device
- Open autoprobed /dev/ttyUSBx port with any serial console
5. Does this problem occur with the latest Rawhide kernel? To install the
Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
``sudo dnf update --enablerepo=rawhide kernel``:
6. Are you running any modules that not shipped with directly Fedora's kernel?:
Using VirtualBox modules from rpmfusion. However, no virtual machines are running alongside any of the tests performed.
7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.
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 <johan@kernel.org <mailto:johan@kernel.org>>
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 <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>>
Signed-off-by: Johan Hovold <johan@kernel.org <mailto:johan@kernel.org>>
drivers/usb/serial/cp210x.c | 3 +++
1 file changed, 3 insertions(+)
This is the bisection log:
git bisect start
# bad: [9f4ad9e425a1d3b6a34617b8ea226d56a119a717] Linux 5.12
git bisect bad 9f4ad9e425a1d3b6a34617b8ea226d56a119a717
# good: [f40ddce88593482919761f74910f42f4b84c004b] Linux 5.11
git bisect good f40ddce88593482919761f74910f42f4b84c004b
# bad: [d99676af540c2dc829999928fb81c58c80a1dce4] Merge tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drm
git bisect bad d99676af540c2dc829999928fb81c58c80a1dce4
# bad: [f9d58de23152f2c16f326d7e014cfa2933b00304] Merge tag 'affs-for-5.12-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
git bisect bad f9d58de23152f2c16f326d7e014cfa2933b00304
# good: [b8af417e4d93caeefb89bbfbd56ec95dedd8dab5] Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
git bisect good b8af417e4d93caeefb89bbfbd56ec95dedd8dab5
# good: [82851fce6107d5a3e66d95aee2ae68860a732703] Merge tag 'arm-dt-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect good 82851fce6107d5a3e66d95aee2ae68860a732703
# bad: [780607b9731feef575514108fc7956c54180f16e] Merge tag 'usb-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect bad 780607b9731feef575514108fc7956c54180f16e
# bad: [c85bfed171aaa91a32dcecd7962a4c880bf9d0ab] Merge tag 'usb-serial-5.12-rc1' ofhttps://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial <https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial> into usb-next
git bisect bad c85bfed171aaa91a32dcecd7962a4c880bf9d0ab
# good: [29b01295a829fba7399ee84afff4e64660e49f04] usb: typec: Add typec_partner_set_pd_revision
git bisect good 29b01295a829fba7399ee84afff4e64660e49f04
# good: [31737c27d665bb3bc8ad9396c63fae2543dd8818] usb: pd: Make SVDM Version configurable in VDM header
git bisect good 31737c27d665bb3bc8ad9396c63fae2543dd8818
# bad: [6420a569504e212d618d4a4736e2c59ed80a8478] USB: serial: option: update interface mapping for ZTE P685M
git bisect bad 6420a569504e212d618d4a4736e2c59ed80a8478
# bad: [54c98d9d7ba48c66d64f72e3d5a7586601705611] USB: serial: xr: fix interface leak at disconnect
git bisect bad 54c98d9d7ba48c66d64f72e3d5a7586601705611
# bad: [f7de9b64265faafe96c2533ddfcc1ad7b2e8080d] USB: serial: mxuport: drop short control-transfer check
git bisect bad f7de9b64265faafe96c2533ddfcc1ad7b2e8080d
# bad: [f61309d9c96a308465bec9d2e5206da265b075a0] USB: serial: cp210x: set IXOFF thresholds
git bisect bad f61309d9c96a308465bec9d2e5206da265b075a0
# good: [979d9cbe75b922ab1695b8ad5576115774f72e62] USB: serial: pl2303: fix line-speed handling on newer chips
git bisect good 979d9cbe75b922ab1695b8ad5576115774f72e62
# good: [7748feffcd80f3ee25dae5e6acd3cf90e8e838d8] USB: serial: cp210x: add support for software flow control
git bisect good 7748feffcd80f3ee25dae5e6acd3cf90e8e838d8
# first bad commit: [f61309d9c96a308465bec9d2e5206da265b075a0] USB: serial: cp210x: set IXOFF thresholds
Bug still present in kernel-5.12.7-300.fc34.x86_64 .
If I manually revert commit f61309d9c96a308465bec9d2e5206da265b075a0 from cp210x.c from 5.12.7, it works correctly. Further proof that this commit introduced the bug.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-05-31 17:38 cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection) Alex Villacís Lasso
@ 2021-06-01 7:50 ` Johan Hovold
2021-06-01 14:51 ` Alex Villacís Lasso
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-01 7:50 UTC (permalink / raw)
To: Alex Villacís Lasso; +Cc: linux-usb
On Mon, May 31, 2021 at 12:38:19PM -0500, Alex Villacís Lasso wrote:
> (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 <johan@kernel.org <mailto:johan@kernel.org>>
> 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 <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>>
> Signed-off-by: Johan Hovold <johan@kernel.org <mailto:johan@kernel.org>>
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-01 7:50 ` Johan Hovold
@ 2021-06-01 14:51 ` Alex Villacís Lasso
2021-06-01 15:40 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-01 14:51 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
El 1/6/21 a las 02:50, Johan Hovold escribió:
> On Mon, May 31, 2021 at 12:38:19PM -0500, Alex Villacís Lasso wrote:
>> (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 <johan@kernel.org <mailto:johan@kernel.org>>
>> 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 <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>>
>> Signed-off-by: Johan Hovold <johan@kernel.org <mailto:johan@kernel.org>>
>> 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.
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control
# modprobe cp210x dyndbg==p
jun 01 09:22:54 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 01 09:22:54 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: new full-speed USB
device number 5 using xhci_hcd
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: Product: CP2102N USB to
UART Bridge Controller
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: Manufacturer: Silicon Labs
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 01 09:23:14 karlalex-asus kernel: cp210x 1-10:1.0: cp210x converter
detected
jun 01 09:23:14 karlalex-asus kernel: usb 1-10: cp210x converter now
attached to ttyUSB0
jun 01 09:23:14 karlalex-asus mtp-probe[3280]: checking bus 1, device 5:
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
jun 01 09:23:14 karlalex-asus mtp-probe[3280]: bus: 1, device: 5 was not
an MTP device
jun 01 09:23:14 karlalex-asus mtp-probe[3297]: checking bus 1, device 5:
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
jun 01 09:23:14 karlalex-asus mtp-probe[3297]: bus: 1, device: 5 was not
an MTP device
jun 01 09:23:16 karlalex-asus ModemManager[726]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10': not supported by any
plugin
$ 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
jun 01 09:23:55 karlalex-asus abrt-server[3363]: Deleting problem
directory Python3-2021-06-01-09:23:55-3362 (dup of
Python3-2021-05-27-14:26:21-17653)
jun 01 09:23:55 karlalex-asus abrt-notification[3382]: [🡕] Process
17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError
exception
$ cat /dev/ttyUSB0
<cat immediately exits, could not press Ctrl-C>
$
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:28:53 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
# rmmod cp210x
<unplug device>
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control
# modprobe cp210x dyndbg==p
jun 01 09:33:09 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 01 09:33:09 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: new full-speed USB
device number 6 using xhci_hcd
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: Product: CP2102N USB to
UART Bridge Controller
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: Manufacturer: Silicon Labs
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 01 09:34:37 karlalex-asus kernel: cp210x 1-10:1.0: cp210x converter
detected
jun 01 09:34:37 karlalex-asus kernel: usb 1-10: cp210x converter now
attached to ttyUSB0
jun 01 09:34:37 karlalex-asus mtp-probe[3722]: checking bus 1, device 6:
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
jun 01 09:34:37 karlalex-asus mtp-probe[3722]: bus: 1, device: 6 was not
an MTP device
jun 01 09:34:37 karlalex-asus mtp-probe[3739]: checking bus 1, device 6:
"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10"
jun 01 09:34:37 karlalex-asus mtp-probe[3739]: bus: 1, device: 6 was not
an MTP device
jun 01 09:34:39 karlalex-asus ModemManager[726]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10': not supported by any
plugin
$ stty -F /dev/ttyUSB0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
= ^R; werase = ^W; lnext = ^V; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke -flusho -extproc
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:35:28 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
$ 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:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x01
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x01, flow = 0x40
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0101
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:37:25 karlalex-asus python3[3814]: detected unhandled Python
exception in '/usr/bin/miniterm.py'
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:37:25 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:37:25 karlalex-asus abrt-server[3815]: Deleting problem
directory Python3-2021-06-01-09:37:25-3814 (dup of
Python3-2021-05-27-14:26:21-17653)
jun 01 09:37:25 karlalex-asus abrt-notification[3835]: [🡕] Process
17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError
exception
$ stty -F /dev/ttyUSB0 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
= ^R; werase = ^W; lnext = ^V; discard = ^O;
min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke -flusho -extproc
jun 01 09:38:18 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 115384
jun 01 09:38:18 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x00, flow = 0x00
jun 01 09:38:18 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 01 09:38:18 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 09:38:18 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 09:38:18 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-01 14:51 ` Alex Villacís Lasso
@ 2021-06-01 15:40 ` Johan Hovold
2021-06-01 17:18 ` Alex Villacís Lasso
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-01 15:40 UTC (permalink / raw)
To: Alex Villacís Lasso; +Cc: linux-usb
On Tue, Jun 01, 2021 at 09:51:56AM -0500, Alex Villacís Lasso wrote:
> 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
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).
> 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 <johan@kernel.org>
Date: Tue, 1 Jun 2021 17:29:01 +0200
Subject: [PATCH] USB: cp210x: add flow-control debugging
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/serial/cp210x.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index ee595d1bea0a..92382798b574 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -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);
+ dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__,
+ ctl_hs, flow_repl);
+ dev_dbg(&port->dev, "%s - xon_limit = %u, xoff_limit = %u\n", __func__,
+ le32_to_cpu(flow_ctl.ulXonLimit),
+ le32_to_cpu(flow_ctl.ulXoffLimit));
+
ctl_hs &= ~CP210X_SERIAL_DSR_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
--
2.31.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-01 15:40 ` Johan Hovold
@ 2021-06-01 17:18 ` Alex Villacís Lasso
2021-06-02 14:50 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-01 17:18 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
El 1/6/21 a las 10:40, Johan Hovold escribió:
> On Tue, Jun 01, 2021 at 09:51:56AM -0500, Alex Villacís Lasso wrote:
>
>> 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
> 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).
>
>> 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 <johan@kernel.org>
> Date: Tue, 1 Jun 2021 17:29:01 +0200
> Subject: [PATCH] USB: cp210x: add flow-control debugging
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/usb/serial/cp210x.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index ee595d1bea0a..92382798b574 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -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);
>
> + dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__,
> + ctl_hs, flow_repl);
> + dev_dbg(&port->dev, "%s - xon_limit = %u, xoff_limit = %u\n", __func__,
> + le32_to_cpu(flow_ctl.ulXonLimit),
> + le32_to_cpu(flow_ctl.ulXoffLimit));
> +
> ctl_hs &= ~CP210X_SERIAL_DSR_HANDSHAKE;
> ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
> ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
As before:
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control
# insmod ./cp210x.ko dyndbg==p
jun 01 12:09:51 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 01 12:09:51 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: new full-speed USB device
number 7 using xhci_hcd
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: Product: CP2102N USB to
UART Bridge Controller
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: Manufacturer: Silicon Labs
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 01 12:11:38 karlalex-asus kernel: cp210x 1-9:1.0: cp210x converter
detected
jun 01 12:11:38 karlalex-asus kernel: usb 1-9: cp210x converter now
attached to ttyUSB0
jun 01 12:11:38 karlalex-asus mtp-probe[11596]: checking bus 1, device
7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 01 12:11:38 karlalex-asus mtp-probe[11596]: bus: 1, device: 7 was
not an MTP device
jun 01 12:11:38 karlalex-asus mtp-probe[11613]: checking bus 1, device
7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 01 12:11:38 karlalex-asus mtp-probe[11613]: bus: 1, device: 7 was
not an MTP device
jun 01 12:11:40 karlalex-asus ModemManager[726]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9': not supported by any
plugin
$ 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
jun 01 12:12:13 karlalex-asus python3[11633]: detected unhandled Python
exception in '/usr/bin/miniterm.py'
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 01 12:12:13 karlalex-asus abrt-server[11634]: Deleting problem
directory Python3-2021-06-01-12:12:13-11633 (dup of
Python3-2021-05-27-14:26:21-17653)
jun 01 12:12:13 karlalex-asus abrt-notification[11653]: [🡕] Process
17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError
exception
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-01 17:18 ` Alex Villacís Lasso
@ 2021-06-02 14:50 ` Johan Hovold
2021-06-02 15:54 ` Alex Villacís Lasso
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-02 14:50 UTC (permalink / raw)
To: Alex Villacís Lasso; +Cc: linux-usb
On Tue, Jun 01, 2021 at 12:18:27PM -0500, Alex Villacís Lasso wrote:
> El 1/6/21 a las 10:40, Johan Hovold escribió:
> > 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.
> $ 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
So the default device settings are the same as for my device and
hardware flow control is disabled.
> 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.
> 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.
> 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).
> 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.
> 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.
> 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.
> jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
> cp210x_tiocmset_port - control = 0x0101
DTR can still be changed.
> 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 <johan@kernel.org>
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(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 89da00de9739..f5c9e21538f8 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -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;
@@ -1857,6 +1888,8 @@ static int cp210x_port_probe(struct usb_serial_port *port)
usb_set_serial_port_data(port, port_priv);
+ cp210x_dump_props(port);
+
return 0;
}
--
2.31.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-02 14:50 ` Johan Hovold
@ 2021-06-02 15:54 ` Alex Villacís Lasso
2021-06-04 15:42 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-02 15:54 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb
El 2/6/21 a las 09:50, Johan Hovold escribió:
> On Tue, Jun 01, 2021 at 12:18:27PM -0500, Alex Villacís Lasso wrote:
>> El 1/6/21 a las 10:40, Johan Hovold escribió:
>>> 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.
>
>> $ 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
> So the default device settings are the same as for my device and
> hardware flow control is disabled.
>
>> 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.
>
>> 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.
>
>> 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).
>
>> 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.
>
>> 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.
>
>> 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.
>
>> jun 01 12:12:13 karlalex-asus kernel: cp210x ttyUSB0:
>> cp210x_tiocmset_port - control = 0x0101
> DTR can still be changed.
>
>> 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 <johan@kernel.org>
> 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(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index 89da00de9739..f5c9e21538f8 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -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;
> @@ -1857,6 +1888,8 @@ static int cp210x_port_probe(struct usb_serial_port *port)
>
> usb_set_serial_port_data(port, port_priv);
>
> + cp210x_dump_props(port);
> +
> return 0;
> }
>
Tests with *both* patches applied:
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control
# insmod ./cp210x.ko dyndbg==p
jun 02 10:42:38 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 02 10:42:38 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 02 10:44:28 karlalex-asus kernel: usb 1-9: new full-speed USB device
number 5 using xhci_hcd
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: usb 1-9: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 02 10:44:29 karlalex-asus kernel: usb 1-9: Product: CP2102N USB to
UART Bridge Controller
jun 02 10:44:29 karlalex-asus kernel: usb 1-9: Manufacturer: Silicon Labs
jun 02 10:44:29 karlalex-asus kernel: usb 1-9: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 02 10:44:29 karlalex-asus kernel: cp210x 1-9:1.0: cp210x converter
detected
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
jun 02 10:44:29 karlalex-asus kernel: usb 1-9: cp210x converter now
attached to ttyUSB0
jun 02 10:44:29 karlalex-asus mtp-probe[10146]: checking bus 1, device
5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 02 10:44:29 karlalex-asus mtp-probe[10146]: bus: 1, device: 5 was
not an MTP device
jun 02 10:44:29 karlalex-asus mtp-probe[10163]: checking bus 1, device
5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 02 10:44:29 karlalex-asus mtp-probe[10163]: bus: 1, device: 5 was
not an MTP device
jun 02 10:44:31 karlalex-asus ModemManager[725]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9': not supported by any
plugin
$ 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
$ cat /dev/ttyUSB0
<cat now waits for input>
jun 02 10:47:52 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 02 10:47:52 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x08, flow = 0x00
jun 02 10:47:52 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - xon_limit = 128, xoff_limit = 128
jun 02 10:47:52 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - ctrl = 0x08, flow = 0x00
jun 02 10:47:52 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x09, flow = 0x80
<Ctrl-C pressed, returned to shell prompt>
jun 02 10:48:59 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-02 15:54 ` Alex Villacís Lasso
@ 2021-06-04 15:42 ` Johan Hovold
2021-06-04 18:25 ` Alex Villacís Lasso
2021-06-04 23:16 ` David Frey
0 siblings, 2 replies; 27+ messages in thread
From: Johan Hovold @ 2021-06-04 15:42 UTC (permalink / raw)
To: Alex Villacís Lasso
Cc: linux-usb, David Frey, Pho Tran, Tung Pham, Hung.Nguyen
[ +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/465ef3ac-4291-6392-e52b-26cc0c34dd7c@palosanto.com
On Wed, Jun 02, 2021 at 10:54:14AM -0500, Alex Villacís Lasso wrote:
> El 2/6/21 a las 09:50, Johan Hovold escribió:
> > 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.
> > From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
> > From: Johan Hovold <johan@kernel.org>
> > 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.
> <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
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).
> $ 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
Here IXOFF is enabled.
> 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.
> $ 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
Here hardware flow control is enabled.
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-04 15:42 ` Johan Hovold
@ 2021-06-04 18:25 ` Alex Villacís Lasso
2021-06-05 10:24 ` Johan Hovold
2021-06-04 23:16 ` David Frey
1 sibling, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-04 18:25 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-usb, David Frey, Pho Tran, Tung Pham, Hung.Nguyen
[-- Attachment #1: Type: text/plain, Size: 18589 bytes --]
El 4/6/21 a las 10:42, Johan Hovold escribió:
> [ +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/465ef3ac-4291-6392-e52b-26cc0c34dd7c@palosanto.com
> On Wed, Jun 02, 2021 at 10:54:14AM -0500, Alex Villacís Lasso wrote:
>> El 2/6/21 a las 09:50, Johan Hovold escribió:
>>> 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.
>>> From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
>>> From: Johan Hovold <johan@kernel.org>
>>> 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.
>
>> <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
> 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).
>
>> $ 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
> Here IXOFF is enabled.
>
>> 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.
>
>> $ 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
> Here hardware flow control is enabled.
>
>> 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 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.
I am attaching the patch I used, which is the combination of both debug
patches, plus this change:
@@ -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);
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:
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control ;
insmod ./cp210x.ko dyndbg==p
jun 04 13:03:52 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 04 13:03:52 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: new full-speed USB device
number 8 using xhci_hcd
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: Product: CP2102N USB to
UART Bridge Controller
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: Manufacturer: Silicon Labs
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 04 13:04:44 karlalex-asus kernel: cp210x 1-9:1.0: cp210x converter
detected
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities
= 0x13f
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams =
0x7f
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue
= 640
jun 04 13:04:44 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue
= 640
jun 04 13:04:44 karlalex-asus kernel: usb 1-9: cp210x converter now
attached to ttyUSB0
jun 04 13:04:44 karlalex-asus mtp-probe[22237]: checking bus 1, device
8: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 04 13:04:44 karlalex-asus mtp-probe[22237]: bus: 1, device: 8 was
not an MTP device
jun 04 13:04:44 karlalex-asus mtp-probe[22254]: checking bus 1, device
8: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 04 13:04:44 karlalex-asus mtp-probe[22254]: bus: 1, device: 8 was
not an MTP device
jun 04 13:04:47 karlalex-asus ModemManager[724]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9': not supported by any
plugin
$ 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
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0202
<miniterm.py terminated via Ctrl-]>
jun 04 13:07:09 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
--------------------------------------
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control ;
insmod ./cp210x.ko dyndbg==p
jun 04 13:08:33 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 04 13:08:33 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: new full-speed USB device
number 9 using xhci_hcd
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: Product: CP2102N USB to
UART Bridge Controller
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: Manufacturer: Silicon Labs
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 04 13:09:30 karlalex-asus kernel: cp210x 1-9:1.0: cp210x converter
detected
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: wLength = 66
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulMaxTxQueue = 640
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulMaxRxQueue = 640
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulProvSubType = 1
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulProvCapabilities
= 0x13f
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulSettableParams =
0x7f
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentTx-Queue
= 640
jun 04 13:09:30 karlalex-asus kernel: cp210x ttyUSB0: ulCurrentRx-Queue
= 640
jun 04 13:09:30 karlalex-asus kernel: usb 1-9: cp210x converter now
attached to ttyUSB0
jun 04 13:09:30 karlalex-asus mtp-probe[22662]: checking bus 1, device
9: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 04 13:09:30 karlalex-asus mtp-probe[22662]: bus: 1, device: 9 was
not an MTP device
jun 04 13:09:30 karlalex-asus mtp-probe[22679]: checking bus 1, device
9: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 04 13:09:30 karlalex-asus mtp-probe[22679]: bus: 1, device: 9 was
not an MTP device
jun 04 13:09:32 karlalex-asus ModemManager[724]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9': not supported by any
plugin
$ stty -F /dev/ttyUSB0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt
= ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke -flusho -extproc
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x00
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 0, xoff_limit = 0
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x01
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 0
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 04 13:10:47 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
$ stty -F /dev/ttyUSB0 ixon ixoff
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x01
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 0
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x01
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 0
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x01
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 0
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x01, flow = 0x43
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 128
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0300
jun 04 13:12:31 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
$ stty -F /dev/ttyUSB0 crtscts -ixon -ixoff
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x01, flow = 0x43
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 128
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x03
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 128
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - control = 0x0303
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0: failed set request
0x7 status: -32
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x03
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 128
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x09, flow = 0x80
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 0, xoff_limit = 0
jun 04 13:14:49 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00
$ cat /dev/ttyUSB0
<waits for input>
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_change_speed - setting baud rate to 9600
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: ctrl = 0x08, flow = 0x00
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - BEFORE: xon_limit = 0, xoff_limit = 0
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: ctrl = 0x08, flow = 0x00
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_set_flow_control - AFTER: xon_limit = 0, xoff_limit = 0
jun 04 13:17:21 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x09, flow = 0x80
<Ctrl-C pressed>
jun 04 13:17:57 karlalex-asus kernel: cp210x ttyUSB0:
cp210x_tiocmset_port - ctrl = 0x08, flow = 0x00
[-- Attachment #2: t1.patch --]
[-- Type: text/x-patch, Size: 2727 bytes --]
--- cp210x.c.orig-5.12.8 2021-06-01 12:04:24.807117676 -0500
+++ cp210x.c 2021-06-04 13:03:14.300539440 -0500
@@ -1159,6 +1159,12 @@
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
+ dev_dbg(&port->dev, "%s - BEFORE: ctrl = 0x%02x, flow = 0x%02x\n", __func__,
+ ctl_hs, flow_repl);
+ dev_dbg(&port->dev, "%s - BEFORE: xon_limit = %u, xoff_limit = %u\n", __func__,
+ le32_to_cpu(flow_ctl.ulXonLimit),
+ le32_to_cpu(flow_ctl.ulXoffLimit));
+
ctl_hs &= ~CP210X_SERIAL_DSR_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
@@ -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);
- dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__,
+ dev_dbg(&port->dev, "%s - AFTER: ctrl = 0x%02x, flow = 0x%02x\n", __func__,
ctl_hs, flow_repl);
+ dev_dbg(&port->dev, "%s - AFTER: xon_limit = %u, xoff_limit = %u\n", __func__,
+ le32_to_cpu(flow_ctl.ulXonLimit),
+ le32_to_cpu(flow_ctl.ulXoffLimit));
flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
@@ -1829,6 +1838,37 @@
#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;
@@ -1843,6 +1883,8 @@
usb_set_serial_port_data(port, port_priv);
+ cp210x_dump_props(port);
+
return 0;
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-04 15:42 ` Johan Hovold
2021-06-04 18:25 ` Alex Villacís Lasso
@ 2021-06-04 23:16 ` David Frey
2021-06-05 10:13 ` Johan Hovold
1 sibling, 1 reply; 27+ messages in thread
From: David Frey @ 2021-06-04 23:16 UTC (permalink / raw)
To: Johan Hovold
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
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.
Thanks,
David
On Fri, Jun 4, 2021 at 8:42 AM Johan Hovold <johan@kernel.org> wrote:
>
> [ +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/465ef3ac-4291-6392-e52b-26cc0c34dd7c@palosanto.com
> On Wed, Jun 02, 2021 at 10:54:14AM -0500, Alex Villacís Lasso wrote:
> > El 2/6/21 a las 09:50, Johan Hovold escribió:
>
> > > 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.
>
> > > From 65b53f408b5d6b6408420ed9d1c827f80401796e Mon Sep 17 00:00:00 2001
> > > From: Johan Hovold <johan@kernel.org>
> > > 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.
>
> > <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
>
> 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).
>
> > $ 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
>
> Here IXOFF is enabled.
>
> > 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.
>
> > $ 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
>
> Here hardware flow control is enabled.
>
> > 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-04 23:16 ` David Frey
@ 2021-06-05 10:13 ` Johan Hovold
2021-06-07 15:16 ` Alex Villacís Lasso
2021-06-07 16:44 ` David Frey
0 siblings, 2 replies; 27+ messages in thread
From: Johan Hovold @ 2021-06-05 10:13 UTC (permalink / raw)
To: David Frey
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Fri, Jun 04, 2021 at 04:16:26PM -0700, David Frey wrote:
> 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.
If anyone's got a Windows installation it may be possible to dump the
USB traffic using Wireshark to determine the request. Unless Silabs can
chime in here of course.
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
> On Fri, Jun 4, 2021 at 8:42 AM Johan Hovold <johan@kernel.org> wrote:
> > 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).
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-04 18:25 ` Alex Villacís Lasso
@ 2021-06-05 10:24 ` Johan Hovold
2021-06-05 10:54 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-05 10:24 UTC (permalink / raw)
To: Alex Villacís Lasso
Cc: linux-usb, David Frey, Pho Tran, Tung Pham, Hung.Nguyen
On Fri, Jun 04, 2021 at 01:25:19PM -0500, Alex Villacís Lasso wrote:
> El 4/6/21 a las 10:42, Johan Hovold escribió:
> > 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).
> 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.
> I am attaching the patch I used, which is the combination of both debug
> patches, plus this change:
>
> @@ -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.
> 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
Another data point: just setting the XON limit is enough to trigger the
bug.
> 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.
> 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
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.
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-05 10:24 ` Johan Hovold
@ 2021-06-05 10:54 ` Johan Hovold
0 siblings, 0 replies; 27+ messages in thread
From: Johan Hovold @ 2021-06-05 10:54 UTC (permalink / raw)
To: Alex Villacís Lasso
Cc: linux-usb, David Frey, Pho Tran, Tung Pham, Hung.Nguyen
On Sat, Jun 05, 2021 at 12:24:34PM +0200, Johan Hovold wrote:
> On Fri, Jun 04, 2021 at 01:25:19PM -0500, Alex Villacís Lasso wrote:
> > El 4/6/21 a las 10:42, Johan Hovold escribió:
>
> > > 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).
>
> > 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.
>
> > I am attaching the patch I used, which is the combination of both debug
> > patches, plus this change:
> >
> > @@ -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.
Oops, missed a negation there: That doesn't mean it may *not* be
possible to work around it somehow of course.
> > 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
>
> Another data point: just setting the XON limit is enough to trigger the
> bug.
>
> > 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.
>
> > 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
>
> 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.
Took a last peek in the datasheet and apparently setting the limits >512
is an A02 firmware feature, and you likely have the A01.
"Changed information in 4.3.8 Software Handshaking to indicate
that in CP2102N-A02, watermark levels greater than 512 are
converted to an XON limit of 192 and an XOFF limit of 64 bytes."
This still suggests that there were some changes in the software flow
control implementation from A01 to A02 which could have fixed the bug.
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-05 10:13 ` Johan Hovold
@ 2021-06-07 15:16 ` Alex Villacís Lasso
2021-06-07 16:45 ` Johan Hovold
2021-06-07 16:44 ` David Frey
1 sibling, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-07 15:16 UTC (permalink / raw)
To: Johan Hovold, David Frey; +Cc: linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
El 5/6/21 a las 05:13, Johan Hovold escribió:
> On Fri, Jun 04, 2021 at 04:16:26PM -0700, David Frey wrote:
>> 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.
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-05 10:13 ` Johan Hovold
2021-06-07 15:16 ` Alex Villacís Lasso
@ 2021-06-07 16:44 ` David Frey
2021-06-07 16:52 ` Johan Hovold
1 sibling, 1 reply; 27+ messages in thread
From: David Frey @ 2021-06-07 16:44 UTC (permalink / raw)
To: Johan Hovold
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Sat, Jun 5, 2021 at 3:13 AM Johan Hovold <johan@kernel.org> wrote:
>
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 15:16 ` Alex Villacís Lasso
@ 2021-06-07 16:45 ` Johan Hovold
0 siblings, 0 replies; 27+ messages in thread
From: Johan Hovold @ 2021-06-07 16:45 UTC (permalink / raw)
To: Alex Villacís Lasso
Cc: David Frey, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Mon, Jun 07, 2021 at 10:16:30AM -0500, Alex Villacís Lasso wrote:
> El 5/6/21 a las 05:13, Johan Hovold escribió:
> > On Fri, Jun 04, 2021 at 04:16:26PM -0700, David Frey wrote:
> >> 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.
>
> 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'm afraid not; I have the same string encoded at offset 60 as you do:
uniProvName = 33 00 2e 00 30 00 00 00 00 00 00 00 00 00 00
It seems we need help from Silabs here unless someone can reverse
engineer the Windows tool or library to determine the firmware version
request.
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 16:44 ` David Frey
@ 2021-06-07 16:52 ` Johan Hovold
2021-06-07 18:02 ` David Frey
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-07 16:52 UTC (permalink / raw)
To: David Frey
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Mon, Jun 07, 2021 at 09:44:59AM -0700, David Frey wrote:
> On Sat, Jun 5, 2021 at 3:13 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 16:52 ` Johan Hovold
@ 2021-06-07 18:02 ` David Frey
2021-06-07 20:44 ` David Frey
0 siblings, 1 reply; 27+ messages in thread
From: David Frey @ 2021-06-07 18:02 UTC (permalink / raw)
To: Johan Hovold
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Mon, Jun 7, 2021 at 9:53 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Mon, Jun 07, 2021 at 09:44:59AM -0700, David Frey wrote:
> > On Sat, Jun 5, 2021 at 3:13 AM Johan Hovold <johan@kernel.org> wrote:
> > >
> > > 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
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 18:02 ` David Frey
@ 2021-06-07 20:44 ` David Frey
2021-06-07 23:50 ` Alex Villacís Lasso
2021-06-08 9:41 ` Johan Hovold
0 siblings, 2 replies; 27+ messages in thread
From: David Frey @ 2021-06-07 20:44 UTC (permalink / raw)
To: Johan Hovold
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]
On Mon, Jun 7, 2021 at 11:02 AM David Frey <dpfrey@gmail.com> wrote:
>
> 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
> }
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.
[-- Attachment #2: cp2102 get firmware version.pcapng --]
[-- Type: application/octet-stream, Size: 7272 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 20:44 ` David Frey
@ 2021-06-07 23:50 ` Alex Villacís Lasso
2021-06-08 9:10 ` Tung Pham
2021-06-08 9:41 ` Johan Hovold
1 sibling, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-07 23:50 UTC (permalink / raw)
To: David Frey, Johan Hovold; +Cc: linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
El 7/6/21 a las 15:44, David Frey escribió:
> On Mon, Jun 7, 2021 at 11:02 AM David Frey <dpfrey@gmail.com> wrote:
>> 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
>> }
> 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.
Yes! This is exactly the information required to query the firmware. Now
a patch should be made that calls cp210x_read_vendor_block(), which
internally uses CP210X_VENDOR_SPECIFIC (0xFF) with a #define
CP210X_READ_FIRMWARE_VER 0x0010, and a 3-byte buffer that will
contain the firmware version. Then the driver will refrain from
programming the XON/XOFF limits if the firmware version is not the fixed
one.
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 23:50 ` Alex Villacís Lasso
@ 2021-06-08 9:10 ` Tung Pham
2021-06-08 9:52 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Tung Pham @ 2021-06-08 9:10 UTC (permalink / raw)
To: Alex Villacís Lasso, David Frey, Johan Hovold
Cc: linux-usb, Pho Tran, Hung Nguyen
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
Dear Johan Hovold.
On Linux you can use manufacturing library to check firmware version.
cd manufacturing/lib/manufacturing/linux
make preinstall
make install
sudo make install
cd manufacturing/lib/manufacturing/test/BasicTestApp/linux
make
./CP210xManufacturingBasicTestApp
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
Thanks.
[-- Attachment #2: manufacturing.zip --]
[-- Type: application/x-zip-compressed, Size: 89111 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-07 20:44 ` David Frey
2021-06-07 23:50 ` Alex Villacís Lasso
@ 2021-06-08 9:41 ` Johan Hovold
2021-06-09 16:15 ` [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control Johan Hovold
1 sibling, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-08 9:41 UTC (permalink / raw)
To: David Frey
Cc: Alex Villacís Lasso, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen
On Mon, Jun 07, 2021 at 01:44:03PM -0700, David Frey wrote:
> On Mon, Jun 7, 2021 at 11:02 AM David Frey <dpfrey@gmail.com> wrote:
> >
> > 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.
The firmware revisions were listed here:
https://www.silabs.com/community/interface/knowledge-base.entry.html/2020/03/31/how_to_determinecp2102nrevisiona01vsa02-DCJI
Apparently both 1.0.2 and 1.0.4 is A01, while 1.0.8 is A2.
Not sure what to make of 1.0.6, but at least it works.
> > 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
> > }
>
> 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.
Excellent, nice job! That's the missing piece we needed. I'll cook up a
patch.
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection)
2021-06-08 9:10 ` Tung Pham
@ 2021-06-08 9:52 ` Johan Hovold
0 siblings, 0 replies; 27+ messages in thread
From: Johan Hovold @ 2021-06-08 9:52 UTC (permalink / raw)
To: Tung Pham
Cc: Alex Villacís Lasso, David Frey, linux-usb, Pho Tran, Hung Nguyen
On Tue, Jun 08, 2021 at 09:10:51AM +0000, Tung Pham wrote:
> On Linux you can use manufacturing library to check firmware version.
Ah, I remember now that you sent a link to this application a few ago in
another thread.
> 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.
Thanks for the details and for confirming or findings.
> 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.
Yeah, this was the fallback option I had in mind, but the CP2102N I have
here then sent XOFF after having received only 7 chars or so when I
tried it.
> - 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
Yes, we'll go with something like that now that we know how to check the
firmware version.
I guess it's even possible to implement flow-control support for these
buggy firmware revisions (by abusing xon_limit), but that would be a new
feature and not something that's needed to fix the regression.
Thanks again.
Johan
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control
2021-06-08 9:41 ` Johan Hovold
@ 2021-06-09 16:15 ` Johan Hovold
2021-06-09 17:00 ` Alex Villacís Lasso
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-09 16:15 UTC (permalink / raw)
To: David Frey, Alex Villacís Lasso
Cc: linux-usb, Pho Tran, Tung Pham, Hung.Nguyen, Johan Hovold, stable
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 <dpfrey@gmail.com>
Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")
Cc: stable@vger.kernel.org # 5.12
Signed-off-by: Johan Hovold <johan@kernel.org>
---
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
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index ee595d1bea0a..910bc965e6cd 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -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;
@@ -1928,6 +1981,7 @@ static int cp210x_attach(struct usb_serial *serial)
usb_set_serial_data(serial, priv);
+ cp210x_determine_quirks(serial);
cp210x_init_max_speed(serial);
result = cp210x_gpio_init(serial);
--
2.31.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control
2021-06-09 16:15 ` [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control Johan Hovold
@ 2021-06-09 17:00 ` Alex Villacís Lasso
2021-06-10 7:23 ` Johan Hovold
0 siblings, 1 reply; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-09 17:00 UTC (permalink / raw)
To: Johan Hovold, David Frey
Cc: linux-usb, Pho Tran, Tung Pham, Hung.Nguyen, stable
El 9/6/21 a las 11:15, Johan Hovold escribió:
> 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 <dpfrey@gmail.com>
> Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
> Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")
> Cc: stable@vger.kernel.org # 5.12
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> 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
>
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index ee595d1bea0a..910bc965e6cd 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -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;
> @@ -1928,6 +1981,7 @@ static int cp210x_attach(struct usb_serial *serial)
>
> usb_set_serial_data(serial, priv);
>
> + cp210x_determine_quirks(serial);
> cp210x_init_max_speed(serial);
>
> result = cp210x_gpio_init(serial);
Applied patch and tested with ESP32 board under kernel 5.12.9:
# echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control ;
insmod ./cp210x.ko dyndbg==p
jun 09 11:51:52 karlalex-asus kernel: usbcore: registered new interface
driver cp210x
jun 09 11:51:52 karlalex-asus kernel: usbserial: USB Serial support
registered for cp210x
<device plugged in>
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: new full-speed USB device
number 6 using xhci_hcd
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: New USB device found,
idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: Product: CP2102N USB to
UART Bridge Controller
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: Manufacturer: Silicon Labs
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: SerialNumber:
283405bafee6e81182024fe64b629a73
jun 09 11:56:00 karlalex-asus kernel: cp210x 1-9:1.0: cp210x converter
detected
jun 09 11:56:00 karlalex-asus kernel: cp210x 1-9:1.0:
cp210x_get_fw_version - 1.0.4
jun 09 11:56:00 karlalex-asus kernel: usb 1-9: cp210x converter now
attached to ttyUSB0
jun 09 11:56:00 karlalex-asus mtp-probe[15041]: checking bus 1, device
6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 09 11:56:00 karlalex-asus mtp-probe[15041]: bus: 1, device: 6 was
not an MTP device
jun 09 11:56:00 karlalex-asus mtp-probe[15060]: checking bus 1, device
6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
jun 09 11:56:00 karlalex-asus mtp-probe[15060]: bus: 1, device: 6 was
not an MTP device
jun 09 11:56:02 karlalex-asus ModemManager[726]: <info> [base-manager]
couldn't check support for device
'/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9': not supported by any
plugin
$ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control
2021-06-09 17:00 ` Alex Villacís Lasso
@ 2021-06-10 7:23 ` Johan Hovold
2021-06-10 14:55 ` Alex Villacís Lasso
0 siblings, 1 reply; 27+ messages in thread
From: Johan Hovold @ 2021-06-10 7:23 UTC (permalink / raw)
To: Alex Villacís Lasso
Cc: David Frey, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen, stable
On Wed, Jun 09, 2021 at 12:00:36PM -0500, Alex Villacís Lasso wrote:
> El 9/6/21 a las 11:15, Johan Hovold escribió:
> > 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 <dpfrey@gmail.com>
> > Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
> > Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")
> > Cc: stable@vger.kernel.org # 5.12
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > 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.
I meant CP2102N here of course. It had been a long day...
> 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.
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control
2021-06-10 7:23 ` Johan Hovold
@ 2021-06-10 14:55 ` Alex Villacís Lasso
0 siblings, 0 replies; 27+ messages in thread
From: Alex Villacís Lasso @ 2021-06-10 14:55 UTC (permalink / raw)
To: Johan Hovold
Cc: David Frey, linux-usb, Pho Tran, Tung Pham, Hung.Nguyen, stable
El 10/6/21 a las 02:23, Johan Hovold escribió:
> On Wed, Jun 09, 2021 at 12:00:36PM -0500, Alex Villacís Lasso wrote:
>> El 9/6/21 a las 11:15, Johan Hovold escribió:
>>> 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 <dpfrey@gmail.com>
>>> Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
>>> Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds")
>>> Cc: stable@vger.kernel.org # 5.12
>>> Signed-off-by: Johan Hovold <johan@kernel.org>
>>> ---
>>> 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.
> I meant CP2102N here of course. It had been a long day...
>
>> 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.
> 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
Yes, go ahead. You can put the Tested-by on my behalf.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-06-10 14:55 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-31 17:38 cp210x module broken in 5.12.5 and 5.12.6, works in 5.11.21 (with bisection) Alex Villacís Lasso
2021-06-01 7:50 ` Johan Hovold
2021-06-01 14:51 ` Alex Villacís Lasso
2021-06-01 15:40 ` Johan Hovold
2021-06-01 17:18 ` Alex Villacís Lasso
2021-06-02 14:50 ` Johan Hovold
2021-06-02 15:54 ` Alex Villacís Lasso
2021-06-04 15:42 ` Johan Hovold
2021-06-04 18:25 ` Alex Villacís Lasso
2021-06-05 10:24 ` Johan Hovold
2021-06-05 10:54 ` Johan Hovold
2021-06-04 23:16 ` David Frey
2021-06-05 10:13 ` Johan Hovold
2021-06-07 15:16 ` Alex Villacís Lasso
2021-06-07 16:45 ` Johan Hovold
2021-06-07 16:44 ` David Frey
2021-06-07 16:52 ` Johan Hovold
2021-06-07 18:02 ` David Frey
2021-06-07 20:44 ` David Frey
2021-06-07 23:50 ` Alex Villacís Lasso
2021-06-08 9:10 ` Tung Pham
2021-06-08 9:52 ` Johan Hovold
2021-06-08 9:41 ` Johan Hovold
2021-06-09 16:15 ` [PATCH] USB: serial: cp210x: fix CP2102N-A01 modem control Johan Hovold
2021-06-09 17:00 ` Alex Villacís Lasso
2021-06-10 7:23 ` Johan Hovold
2021-06-10 14:55 ` Alex Villacís Lasso
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.