kernel/linux.git/drivers/tty/serial/8250, branch v6.12.80

serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY

2026-03-25T10:08:49+00:00

commit e0a368ae79531ff92105a2692f10d83052055856 upstream. When DW UART is !uart_16550_compatible, it can indicate BUSY at any point (when under constant Rx pressure) unless a complex sequence of steps is performed. Any LCR write can run a foul with the condition that prevents writing LCR while the UART is BUSY, which triggers BUSY_DETECT interrupt that seems unmaskable using IER bits. Normal flow is that dw8250_handle_irq() handles BUSY_DETECT condition by reading USR register. This BUSY feature, however, breaks the assumptions made in serial8250_do_shutdown(), which runs synchronize_irq() after clearing IER and assumes no interrupts can occur after that point but then proceeds to update LCR, which on DW UART can trigger an interrupt. If serial8250_do_shutdown() releases the interrupt handler before the handler has run and processed the BUSY_DETECT condition by read the USR register, the IRQ is not deasserted resulting in interrupt storm that triggers "irq x: nobody cared" warning leading to disabling the IRQ. Add late synchronize_irq() into serial8250_do_shutdown() to ensure BUSY_DETECT from DW UART is handled before port's interrupt handler is released. Alternative would be to add DW UART specific shutdown function but it would mostly duplicate the generic code and the extra synchronize_irq() seems pretty harmless in serial8250_do_shutdown(). Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver") Cc: stable Reported-by: Bandal, Shankar Tested-by: Bandal, Shankar Tested-by: Murthy, Shanth Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://patch.msgid.link/20260203171049.4353-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix TX deadlock when using DMA

2026-03-25T10:08:49+00:00

commit a424a34b8faddf97b5af41689087e7a230f79ba7 upstream. `dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma->tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma->tx_running` will never get cleared and we will never schedule new TX DMA transactions again. This change makes it so we clear `dma->tx_running` after we terminate the DMA transaction. This is "safe" because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma->tx_running` is serialized. Fixes: 9e512eaaf8f4 ("serial: 8250: Fix fifo underflow on flush") Cc: stable Signed-off-by: Raul E Rangel Link: https://patch.msgid.link/20260209135815.1.I16366ecb0f62f3c96fe3dd5763fcf6f3c2b4d8cd@changeid Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: add support for the AX99100

2026-03-25T10:08:49+00:00

commit 9c0072bc33d349c83d223e64be30794e11938a6b upstream. This is found in popular brands such as StarTech.com or Delock, and has been a source of frustration to quite a few people, if I can trust Amazon comments complaining about Linux support via the official out-of-the-tree driver. Signed-off-by: Martin Roukala (né Peres) Cc: stable Link: https://patch.msgid.link/20260309-8250_pci_ax99100-v1-1-3328bdfd8e94@mupuf.org Signed-off-by: Greg Kroah-Hartman

serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done

2026-03-04T12:21:25+00:00

[ Upstream commit a5fd8945a478ff9be14812693891d7c9b4185a50 ] Clear rx_running flag only after DMA teardown polling completes. In the previous implementation the flag was being cleared while hardware teardown was still in progress, creating a mismatch between software state (flag = 0, "ready") and hardware state (still terminating). Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-3-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250: 8250_omap.c: Add support for handling UART error conditions

2026-03-04T12:21:25+00:00

[ Upstream commit 623b07b370e9963122d167e04fdc1dc713ebfbaf ] The DMA IRQ handler does not accounts for the overrun(OE) or any other errors being reported by the IP before triggering a DMA transaction which leads to the interrupts not being handled resulting into an IRQ storm. The way to handle OE is to: 1. Reset the RX FIFO. 2. Read the UART_RESUME register, which clears the internal flag Earlier, the driver issued DMA transations even in case of OE which shouldn't be done according to the OE handling mechanism mentioned above, as we are resetting the FIFO's, refer section: "12.1.6.4.8.1.3.6 Overrun During Receive" [0]. [0] https://www.ti.com/lit/pdf/spruiu1 Signed-off-by: Moteen Shah Link: https://patch.msgid.link/20260112081829.63049-2-m-shah@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_dw: handle clock enable errors in runtime_resume

2026-03-04T12:21:23+00:00

[ Upstream commit d31228143a489ba6ba797896a07541ce06828c09 ] Add error checking for clk_prepare_enable() calls in dw8250_runtime_resume(). Currently if either clock fails to enable, the function returns success while leaving clocks in inconsistent state. This change implements comprehensive error handling by checking the return values of both clk_prepare_enable() calls. If the second clock enable operation fails after the first clock has already been successfully enabled, the code now properly cleans up by disabling and unpreparing the first clock before returning. The error code is then propagated to the caller, ensuring that clock enable failures are properly reported rather than being silently ignored. Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251104145433.2316165-2-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Fix broken RS485 for F81504/508/512

2026-01-30T09:28:40+00:00

commit 27aff0a56b3c77ea1a73641c9b3c4172a8f7238f upstream. Fintek F81504/508/512 can support both RTS_ON_SEND and RTS_AFTER_SEND, but pci_fintek_rs485_supported only announces the former. This makes it impossible to unset SER_RS485_RTS_ON_SEND from userspace because of uart_sanitize_serial_rs485(). Some devices with these chips need RTS low on TX, so they are effectively broken. Fix this by announcing the support for SER_RS485_RTS_AFTER_SEND, similar to commit 068d35a7be65 ("serial: sc16is7xx: announce support for SER_RS485_RTS_ON_SEND"). Fixes: 4afeced55baa ("serial: core: fix sanitizing check for RTS settings") Cc: stable Signed-off-by: Marnix Rijnart Link: https://patch.msgid.link/20260112000931.61703-1-marnix.rijnart@iwell.eu Signed-off-by: Greg Kroah-Hartman

serial: add support of CPCI cards

2025-12-12T17:37:19+00:00

commit 0e5a99e0e5f50353b86939ff6e424800d769c818 upstream. Addi-Data GmbH is manufacturing multi-serial ports cards supporting CompactPCI (known as CPCI). Those cards are identified with different DeviceIds. Those cards integrating standard UARTs work the same way as PCI/PCIe models already supported in the serial driver. Signed-off-by: Magne Bruno Link: https://patch.msgid.link/20251110162456.341029-1-magne.bruno@addi-data.com Cc: stable Signed-off-by: Greg Kroah-Hartman

serial: 8250_mtk: Enable baud clock and manage in runtime PM

2025-10-29T13:09:01+00:00

commit d518314a1fa4e980a227d1b2bda1badf433cb932 upstream. Some MediaTek SoCs got a gated UART baud clock, which currently gets disabled as the clk subsystem believes it would be unused. This results in the uart freezing right after "clk: Disabling unused clocks" on those platforms. Request the baud clock to be prepared and enabled during probe, and to restore run-time power management capabilities to what it was before commit e32a83c70cf9 ("serial: 8250-mtk: modify mtk uart power and clock management") disable and unprepare the baud clock when suspending the UART, prepare and enable it again when resuming it. Fixes: e32a83c70cf9 ("serial: 8250-mtk: modify mtk uart power and clock management") Fixes: b6c7ff2693ddc ("serial: 8250_mtk: Simplify clock sequencing and runtime PM") Cc: stable Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Golle Link: https://patch.msgid.link/de5197ccc31e1dab0965cabcc11ca92e67246cf6.1758058441.git.daniel@makrotopia.org Signed-off-by: Greg Kroah-Hartman

serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018

2025-10-29T13:09:01+00:00

commit e7cbce761fe3fcbcb49bcf30d4f8ca5e1a9ee2a0 upstream. The Advantech 2-port serial card with PCI vendor=0x13fe and device=0x0018 has a 'XR17V35X' chip installed on the circuit board. Therefore, this driver can be used instead of theu outdated out-of-tree driver from the manufacturer. Signed-off-by: Florian Eckert Cc: stable Link: https://patch.msgid.link/20250924134115.2667650-1-fe@dev.tdt.de Signed-off-by: Greg Kroah-Hartman