| Message ID | 20200206111819.20829-1-johan@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | USB: serial: ch341: fix receiver regression | expand |
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; }
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(+)