Re: [PATCH v4] serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Jul 30, 2026 at 04:39:20PM -0300, Ryan Wilbur wrote:
> The NXP LPC32xx UART (PORT_LPC3220) 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().
> 
> LPC32xx has no dedicated 8250 glue driver, it's driven by the generic
> 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up
> in of_platform_serial_setup() the same way fsl8250_handle_irq is
> installed. The handler follows dw8250_handle_irq(): on an RX timeout
> with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR
> read to clear the condition, then calls serial8250_handle_irq_locked().
> No real received data is ever discarded, and it is a no-op on healthy
> UARTs which never report a timeout with DR clear.
> 
> This is the same class of bug already worked around in other 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.

As long as this quirk is not anymore in the generic 8250 code, I'm fine with it
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko