summaryrefslogtreecommitdiff
path: root/.gitattributes
diff options
context:
space:
mode:
authorSergey Organov <sorganov@gmail.com>2023-02-01 17:26:55 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-02-08 15:11:52 +0300
commit496a4471b7c3ae5c0be1a3fccd69e7debc127e08 (patch)
treed8823a7dc5eada028a625da49d6a2067b00d1c24 /.gitattributes
parentd45fb2e430e54fac6af3cabb39c36171c4bf3f52 (diff)
downloadlinux-496a4471b7c3ae5c0be1a3fccd69e7debc127e08.tar.xz
serial: imx: work-around for hardware RX flood
Check if hardware Rx flood is in progress, and issue soft reset to UART to stop the flood. A way to reproduce the flood (checked on iMX6SX) is: open iMX UART at 9600 8N1, and from external source send 0xf0 char at 115200 8N1. In about 90% of cases this starts a flood of "receiving" of 0xff characters by the iMX UART that is terminated by any activity on RxD line, or could be stopped by issuing soft reset to the UART (just stop/start of RX does not help). Note that in essence what we did here is sending isolated start bit about 2.4 times shorter than it is to be if issued on the UART configured baud rate. There was earlier attempt to fix similar issue in: 'commit b38cb7d25711 ("serial: imx: Disable new features of autobaud detection")', but apparently it only gets harder to reproduce the issue after that commit. Signed-off-by: Sergey Organov <sorganov@gmail.com> Link: https://lore.kernel.org/r/20230201142700.4346-3-sorganov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions