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 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