linux-stable.git/drivers/tty/mxser.c, branch v5.16.3

mxser: increase buf_overrun if tty_insert_flip_char() fails

2022-01-27T11:02:17+00:00

[ Upstream commit eb68ac0462bffc2ceb63b3a76737d6c9f186e6de ]

mxser doesn't increase port->icount.buf_overrun at all. Do so if overrun
happens, so that it can be read from the stats.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20211118073125.12283-17-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mxser: don't throttle manually

2022-01-27T11:02:17+00:00

[ Upstream commit c6693e6e07805f1b7822b13a5b482bf2b6a1f312 ]

First, checking tty->receive_room to signalize whether there is enough space
in the tty buffers does not make much sense. Provided the tty buffers
are in tty_port and those are not checked at all.

Second, if the rx path is throttled, with CRTSCTS, RTS is deasserted,
but is never asserted again. This leads to port "lockup", not accepting
any more input.

So:
1) stty -F /dev/ttyMI0 crtscts # the mxser port
2) stty -F /dev/ttyS6 crtscts # the connected port
3) cat /dev/ttyMI0
4) "write in a loop" to /dev/ttyS6
5) cat from 3) produces the bytes from 4)
6) killall -STOP cat (the 3)'s one)
7) wait for RTS to drop on /dev/ttyMI0
8) killall -CONT cat (again the 3)'s one)

cat erroneously produces no more output now (i.e. no data sent from
ttyS6 to ttyMI can be seen).

Note that the step 7) is performed twice: once from n_tty by
tty_throttle_safe(), once by mxser_stoprx() from the receive path. Then
after step 7), n_tty correctly unthrottles the input, but mxser calls
mxser_stoprx() again as there is still only a little space in n_tty
buffers (tty->receive_room mentioned at the beginning), but the device's
FIFO is/can be already filled.

After this patch, the output is correctly resumed, i.e. n_tty both
throttles and unthrottles without interfering with mxser's attempts.

This allows us to get rid of the non-standard ldisc_stop_rx flag from
struct mxser_port.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20211118073125.12283-15-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mxser: keep only !tty test in ISR

2022-01-27T11:02:17+00:00

[ Upstream commit 274ab58dc2b460cc474ffc7ccfcede4b2be1a3f5 ]

The others are superfluous with tty refcounting in place now. And they
are racy in fact:
* tty_port_initialized() reports false for a small moment after
  interrupts are enabled.
* closing is 1 while the port is still alive.

The queues are flushed later during close anyway. So there is no need
for this special handling. Actually, the ISR should not flush the
queues. It should behave as every other driver, just queue the chars
into tty buffer and go on. But this will be changed later. There is
still a lot code depending on having tty in ISR (and not only tty_port).

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20211118073125.12283-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mxser: store FCR state in mxser_port::FCR

2021-10-05T12:08:09+00:00

We force the FCR contents on many places in the code instead of writing
what was actually set in mxser_change_speed() (by ->activate() or
->set_serial_info()).

So introduce mxser_port::FCR to hold the proper contents and bitwise-OR
the value to what needs to be set on all those locations. That is,
clearing RX and/or TX FIFOs. Those flags are self-clearing, so no need
to set them to mxser_port::FCR.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-7-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: don't read from UART_FCR

2021-10-05T12:08:09+00:00

The UART_FCR register is write-only. When reading it, one gets contents
of (read-only) UART_IIR instead as they are shared. This mistake was
performed in mxser_flush_buffer() to clear FIFOs.

Actually FCR handling throughout the driver is completely broken. On
many places, it respects neither mu860 settings, nor FIFO (16450 vs
16550) setting. This patch doesn't help to fix this, it actually does
the same. We will introduce a mxser_port::FCR in the next patch to fix
this issue.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-6-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: move FIFO clearing to mxser_disable_and_clear_FIFO()

2021-10-05T12:08:09+00:00

This code is used on two places, make a helper for disabling and
clearing FIFOs. And demangle the too complicated 'if' by using a local
variable.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: simplify FCR computation in mxser_change_speed()

2021-10-05T12:08:09+00:00

Provided FIFO is always enabled for MUST chips, move its FCR setting out
of PORT_8250/PORT_16450 special case in mxser_change_speed(). Now, we
can pre-set fcr to zero and invert the condition of the 'if'.

This makes the code more readable (no functional change intended).

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: make mxser_port::ldisc_stop_rx a bool

2021-10-05T12:08:08+00:00

It's used only as a yes-no variable, so make it a bool and switch the
set values appropriately.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: simplify condition in mxser_receive_chars_new

2021-10-05T12:08:08+00:00

mxser_receive_chars_old() is used whenever MOXA_MUST_LSR_RERR is set in
status no matter the HW ID (the last 'if'). So there is no need for
another check of MOXA_MUST_LSR_RERR _with_ hwid == MOXA_MUST_MU860_HWID
(the third 'if').  Hence remove this subcase. That allows us to check
status on a single line with both UART_LSR_BRK_ERROR_BITS (from the
second 'if') and MOXA_MUST_LSR_RERR (the last 'if').

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

mxser: restore baud rate if its setting fails

2021-10-05T12:08:08+00:00

If a user tries to set a too high rate, it fails due to check in
mxser_set_baud(). But the high rate remains set in termios, so the user
might think everything went smooth. Restore the baud rate from the
old_termios if this happens, so that user knows nothing was changed in
fact.

It used to behave the correct way many years ago, but somehow the
restoration vanished with commit 1c45607ad3eb (Char: mxser, remove it)
-- the commit removed mxser's older clone.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210922075938.31390-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman