Re: Possible bug in the cp210x kernel driver?

[Johan Hovold <johan@kernel.org>]

On Tue, Sep 21, 2021 at 06:55:21PM +0200, Malte Di Donato wrote:
> Hi Johan,
> 
> Sorry about the html crap.
> (and double excuse that I've totally forgotten to change my webmail
> account surname since wedding ;)

Heh, good that you noticed in time so I can give you proper credit in
the commit message. ;)

Unfortunately your mails won't be seen by anyone else one the list
unless you can disable that html.

> Placed the patch code into my running debian kernel version
> 5.10.0-8-amd64 and put the two invocations to the
> cp210x_init_max_speed function (cp210x_get_fw_version not existent in
> my kernel source file).

Sounds good, we need to do the same when backporting the fix.

> Here's the dmesg with the patched driver:
> 
> [19089.502913] usbcore: registered new interface driver cp210x
> [19089.502951] usbserial: USB Serial support registered for cp210x
> [19096.084910] usb 3-1.2: new full-speed USB device number 9 using ehci-pci
> [19096.224973] usb 3-1.2: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
> [19096.225034] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [19096.225037] usb 3-1.2: Product: CP2102 USB to UART Bridge Controller
> [19096.225040] usb 3-1.2: Manufacturer: Silicon Labs
> [19096.225043] usb 3-1.2: SerialNumber: 0001
> [19096.233460] cp210x 3-1.2:1.0: cp210x converter detected
> [19096.233939] cp210x 3-1.2:1.0: cp210x_init_max_speed - type = 0x02
> [19096.234458] cp210x 3-1.2:1.0: failed to get vendor val 0x370b size 8: 1

So the device returns one byte (instead of eight) as I suspected. Then
we can use this to detect these devices.

> [19096.236568] usb 3-1.2: cp210x converter now attached to ttyUSB0
> 
> I also compiled the cp2102-det and run it against the chip:
> 09: Got 128 bytes:  FF F0 FF FA 01 00 60 E3 16 00 FF F0 FF FA 01 00 60 E3 16 00 FF EC FF F8 01 00 80 4F 12 00 FF E6 FF F6 01 00 00 10 0E 00 FF D6 FF F0 01 00 00 CA 08 00 FF D0 FF EE 01 00 20 A1 07 00 FF CC FF EC 01 00 00 08 07 00 FF A2 FF DC 01 00 00 E8 03 00 FF A0 FF DC 01 00 90 D0 03 00 FF 98 FF D9 01 00 00 84 03 00 FF 64 FF C5 01 00 00 58 02 00 FF 44 FF B9 01 00 00 F4 01 00 FF 30 FF B2 01 00 00 C2 
> 0A: Got 1 bytes:  FF 
> 0B: Got 1 bytes:  02 
> Done.
> 
> Hope this helps?

It does, thanks. The 0B request above is the part-number request. The
original CP2102 I have here returns 8 bytes if that's requested.

> As I look on the "SerialNumber: 0001" in dmesg it may be possible that
> I've got a cloned chip on the chinesium usb/ttl converter...

Mine has 0001 as serial number as well, but the lack of event-mode and
different vendor request behaviour seems to suggest it could be a
counterfeit.

I'll reply to this mail with a fix that fixes the dropped character
issue by disabling event-insertion mode (and thus parity reporting) for
devices such as yours.

I've verified it here as well as I could, but could you give it a spin
with your device as well? If you want you can reply to the patch mail
with a Tested-by tag and I'll add that to the commit message as well.

Johan