On Sat, Jun 05, 2021 at 12:24:34PM +0200, Johan Hovold wrote:

On Fri, Jun 04, 2021 at 01:25:19PM -0500, Alex Villacís Lasso wrote:

quoted

El 4/6/21 a las 10:42, Johan Hovold escribió:

quoted

quoted

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

quoted

I am starting to suspect that the root cause is that the 0x07 command 
(CP210X_SET_MHS macro in the code) is invalid to send, if the device has 
been previously programmed with nonzero ulXonLimit/ulXoffLimit. When the 
patch programs both limits back to 0, the command succeeds.

Right, that's what the bisection and logs seem to suggest.

quoted

I am attaching the patch I used, which is the combination of both debug 
patches, plus this change:

@@ -1195,11 +1201,14 @@
         else
                 flow_repl &= ~CP210X_SERIAL_AUTO_TRANSMIT;

-       flow_ctl.ulXonLimit = cpu_to_le32(128);
-       flow_ctl.ulXoffLimit = cpu_to_le32(128);
+       flow_ctl.ulXonLimit = (I_IXON(tty)) ? cpu_to_le32(128) : 

cpu_to_le32(0);
+       flow_ctl.ulXoffLimit = (I_IXOFF(tty)) ? cpu_to_le32(128) : 
cpu_to_le32(0);

These are both only needed when IXOFF (input flow control) is used (IXON
is for output flow control and does not use these limits).

And the fact that they cause a mostly unrelated error when set still
indicates a firmware bug. That doesn't mean it may be possible to work
around it somehow of course.

Oops, missed a negation there: That doesn't mean it may *not* be
possible to work around it somehow of course.

quoted

With this patch, the miniterm.py program sort of keeps running and shows 
output. Not a perfect patch by any means, since some failures still happen:

quoted

$ miniterm.py /dev/ttyUSB0 115200
<program waits for input>

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_change_speed - setting baud rate to 9600
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x00
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - BEFORE: xon_limit = 0, xoff_limit = 0
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - AFTER: ctrl = 0x00, flow = 0x01
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - AFTER: xon_limit = 128, xoff_limit = 0

Another data point: just setting the XON limit is enough to trigger the
bug.

quoted

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_tiocmset_port - control = 0x0303
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: failed set request 
0x7 status: -32

As here SET_MHS fails.

quoted

jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_change_speed - setting baud rate to 115384
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - BEFORE: ctrl = 0x00, flow = 0x01
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - BEFORE: xon_limit = 128, xoff_limit = 0
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - AFTER: ctrl = 0x01, flow = 0x40
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_set_flow_control - AFTER: xon_limit = 0, xoff_limit = 0
jun 04 13:05:12 karlalex-asus kernel: cp210x ttyUSB0: 
cp210x_tiocmset_port - control = 0x0101

And when XON is reset, settings RTS again works.

For completeness you could try setting only the XOFF limit and see if
that alone is sufficient to trigger the issue.

But please also try hardcoding both limits to 513 as I mentioned
above and see if that makes any difference.

Took a last peek in the datasheet and apparently setting the limits >512
is an A02 firmware feature, and you likely have the A01.

	"Changed information in 4.3.8 Software Handshaking to indicate
	that in CP2102N-A02, watermark levels greater than 512 are
	converted to an XON limit of 192 and an XOFF limit of 64 bytes."

This still suggests that there were some changes in the software flow
control implementation from A01 to A02 which could have fixed the bug.

Johan