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

[Johan Hovold <johan@kernel.org>]

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