While assumed not to make a difference, not using the factor 2 prescaler makes the receiver more susceptible to errors.

Specifically, there have been reports of problems with devices that cannot generate a 115200 rate with a smaller error than 2.1% (e.g. 117647 bps). But this can also be reproduced with a low-speed RS232 tranceiver at 115200 when the input rate is close to nominal.

So whenever possible, enable the factor 2 prescaler and halve the divisor in order to use settings closer to that of the previous algorithm.

Fixes: 35714565089e ("USB: serial: ch341: reimplement line-speed handling") Cc: stable stable@vger.kernel.org # 5.5 Reported-by: Jakub Nantl jn@forever.cz Tested-by: Jakub Nantl jn@forever.cz Signed-off-by: Johan Hovold johan@kernel.org ---

I was able to reproduce this using a MAX232 tranceiver at 115200 even with a close-to-nominal input rate, so the receiver is definitely more sensitive to errors with the 2-prescaler disabled.

Note that I had this step in the first version of the new algorithm, but couldn't convince myself that it wasn't redundant.

Reverse-engineering is fun.

Johan

drivers/usb/serial/ch341.c | 10 ++++++++++ 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c index df582fe855f0..415c3d31492b 100644 --- a/drivers/usb/serial/ch341.c +++ b/drivers/usb/serial/ch341.c @@ -205,6 +205,16 @@ static int ch341_get_divisor(speed_t speed) 16 * speed - 16 * CH341_CLKRATE / (clk_div * (div + 1))) div++;

+ /* + * Prefer lower base clock (fact = 0) if even divisor. + * + * Note that this makes the receiver more tolerant to errors. + */ + if (fact == 1 && div % 2 == 0) { + div /= 2; + fact = 0; + } + return (0x100 - div) << 8 | fact << 2 | ps; }