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@xxxxxxxxxx> 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@xxxxxxxxxxxxx > 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@xxxxxxxxxx> > > > 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
