| Message ID | 20200206111819.20829-1-johan@kernel.org (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 7c3d02285ad558691f27fde760bcd841baa27eab |
| Headers | show |
| Series | USB: serial: ch341: fix receiver regression | expand |
On Thu, Feb 06, 2020 at 12:18:19PM +0100, Johan Hovold wrote: > 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> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Thu, Feb 06, 2020 at 11:45:46AM +0000, Greg Kroah-Hartman wrote: > On Thu, Feb 06, 2020 at 12:18:19PM +0100, Johan Hovold wrote: > > 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> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks for reviewing. Now applied. Johan
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(+)