[PATCH v2] serial: 8250: clear a stuck RX-timeout interrupt with an empty FIFO

[Ryan Wilbur <rwilbur633@gmail.com>]

Some UARTs can latch an RX character-timeout interrupt while the
RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is
clear. A character timeout is only cleared by reading RHR, but
serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever
clears the condition. The interrupt is level-triggered and re-fires
immediately, so on a single-core ARM926 the resulting interrupt
storm livelocks the CPU.

It is reproducible when userspace repeatedly opens the front-panel port
(ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and
the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping
the soft-lockup detector in serial8250_handle_irq_locked().

Fix this by doing one throwaway RHR read to clear the timeout when the
FIFO is empty (LSR.DR clear), so no real received data is ever discarded,
and it is a no-op on healthy UARTs which never report a timeout with
DR==0.

This is the same class of bug already worked around in 8250 drivers;
see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt")
which reports the identical iir=0xcc/lsr=0x60. See also
UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.

LPC32xx (PORT_LPC3220) has no dedicated 8250 glue driver, driven
by generic 8250_of, so it's handled here.

Cc: stable@vger.kernel.org
Signed-off-by: Ryan Wilbur <rwilbur633@gmail.com>
---
Changes in v2:
- Drop the PORT_LPC3220 gate and handle the spurious RX timeout generically

v1: https://lore.kernel.org/linux-serial/20260717123530.481021-1-rwilbur633@gmail.com/

 drivers/tty/serial/8250/8250_port.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 8c241ec7f4f2..c63c4165105a 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1803,6 +1803,21 @@ void serial8250_handle_irq_locked(struct uart_port *port, unsigned int iir)
 	if (!(status & UART_LSR_DR) && (status & UART_LSR_FIFOE))
 		serial8250_clear_and_reinit_fifos(up);
 
+	/*
+	 * A UART can raise an RX character-timeout interrupt while the RX
+	 * FIFO is already empty (IIR reports RX_TIMEOUT but LSR.DR is
+	 * clear). The timeout is only cleared by reading RHR, but the RX
+	 * path below is skipped when the FIFO is empty, so nothing clears
+	 * it. With a level-triggered IRQ it re-fires immediately and can
+	 * livelock a single-core. Observed on the NXP LPC32xx
+	 * UART (PORT_LPC3220). Do one throwaway RHR read to
+	 * clear it. A healthy 16550 UART never reports a timeout with DR clear,
+	 * so this is a no-op elsewhere.
+	 */
+	if ((iir & UART_IIR_RX_TIMEOUT) == UART_IIR_RX_TIMEOUT &&
+	    !(status & UART_LSR_DR))
+		serial_in(up, UART_RX);
+
 	/*
 	 * If port is stopped and there are no error conditions in the
 	 * FIFO, then don't drain the FIFO, as this may lead to TTY buffer

base-commit: da7b5fd4e17f8e44c5590f2d603c01d499f056e6
-- 
2.25.1