diff options
author | Tomasz Moń <tomasz.mon@camlingroup.com> | 2022-02-28 06:49:11 +0100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2022-04-22 16:25:06 +0200 |
commit | b0e0bd9d0d891c1811f52e836ef54fff486db866 (patch) | |
tree | 1f981cd957b2f84f26c138637687d1ea41b83e4c /drivers/tty/n_tty.c | |
parent | 7ea4aa70bfcec3225e2a38d8934c0b1f582c48c1 (diff) | |
download | linux-b0e0bd9d0d891c1811f52e836ef54fff486db866.tar.gz linux-b0e0bd9d0d891c1811f52e836ef54fff486db866.tar.bz2 linux-b0e0bd9d0d891c1811f52e836ef54fff486db866.zip |
serial: core: fix tcdrain() with CTS enabled
Do not set timeout to twice the approximate amount of time to send the
entire FIFO if CTS is enabled. If the caller requested no timeout, e.g.
when userspace program called tcdrain(), then wait without any timeout.
Premature return from tcdrain() was observed on imx based system which
has 32 character long transmitter FIFO with hardware CTS handling.
Simple userspace application that reproduces problem has to:
* Open tty device, enable hardware flow control (CRTSCTS)
* Write data, e.g. 26 bytes
* Call tcdrain() to wait for the transmitter
* Close tty device
The other side of serial connection has to:
* Receive some data, e.g. 10 bytes
* Set RTS output (CTS input from sender perspective) inactive for
at least twice the port timeout
* Try to receive remaining data
Without this patch, userspace application will finish without any error
while the other side of connection will never receive remaining data.
Signed-off-by: Tomasz Moń <tomasz.mon@camlingroup.com>
Link: https://lore.kernel.org/r/20220228054911.1420221-1-tomasz.mon@camlingroup.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/tty/n_tty.c')
0 files changed, 0 insertions, 0 deletions