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@xxxxxxxxxxxxxxx> # 5.5
Reported-by: Jakub Nantl <jn@xxxxxxxxxx>
Tested-by: Jakub Nantl <jn@xxxxxxxxxx>
Signed-off-by: Johan Hovold <johan@xxxxxxxxxx>
---
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;
}
--
2.24.1
