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
