kernel.git/drivers/tty/serial/8250, branch linux-5.4.y

serial: 8250_dw: handle reset control deassert error

2025-12-03T11:45:06Z

[ Upstream commit daeb4037adf7d3349b4a1fb792f4bc9824686a4b ] Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails. Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted. The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics. Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling") Cc: stable Signed-off-by: Artem Shimko Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Use devm_add_action_or_reset()

2025-12-03T11:45:06Z

[ Upstream commit 295b09128d12fb1a7a67f771cc0ae0df869eafaf ] Slightly simplify ->probe() and drop a few goto labels by using devm_add_action_or_reset() for clock and reset cleanup. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220509172129.37770-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: daeb4037adf7 ("serial: 8250_dw: handle reset control deassert error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Use devm_clk_get_optional() to get the input clock

2025-12-03T11:45:06Z

[ Upstream commit a8afc193558a42d5df724c84436ae3b2446d8a30 ] Simplify the code which fetches the input clock by using devm_clk_get_optional(). This comes with a small functional change: previously all errors were ignored except deferred probe. Now all errors are treated as errors. If no input clock is present devm_clk_get_optional() will return NULL instead of an error which matches the behavior of the old code. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20190925162617.30368-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: daeb4037adf7 ("serial: 8250_dw: handle reset control deassert error") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: 8250: fix panic due to PSLVERR

2025-08-28T14:21:30Z

commit 7f8fdd4dbffc05982b96caf586f77a014b2a9353 upstream. When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui Reviewed-by: John Ogness Cc: stable Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com [ Applied fix to serial8250_do_startup() instead of serial8250_initialize() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: 8250_dma: terminate correct DMA in tx_dma_flush()

2025-04-10T12:29:39Z

commit a26503092c75abba70a0be2aa01145ecf90c2a22 upstream. When flushing transmit side DMA, it is the transmit channel that should be terminated, not the receive channel. Fixes: 9e512eaaf8f40 ("serial: 8250: Fix fifo underflow on flush") Cc: stable Reported-by: Wentao Guan Signed-off-by: John Keeping Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20250224121831.1429323-1-jkeeping@inmusicbrands.com Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250: Add some more device IDs

2025-04-10T12:29:39Z

commit be6a23650908e2f827f2e7839a3fbae41ccb5b63 upstream. These card IDs got missed the first time around. Cc: stable Signed-off-by: Cameron Williams Link: https://lore.kernel.org/r/DB7PR02MB380295BCC879CCF91315AC38C4C12@DB7PR02MB3802.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: add support for ASIX AX99100

2025-03-13T11:43:19Z

commit 0b32216557ce3b2a468d1282d99b428bf72ff532 upstream. Each of the 4 PCI functions on ASIX AX99100 PCIe to Multi I/O Controller can be configured as a single-port serial port controller. The subvendor id is 0x1000 when configured as serial port and MSI interrupts are supported. Signed-off-by: Jiaqing Zhao Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230724083933.3173513-4-jiaqing.zhao@linux.intel.com Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix fifo underflow on flush

2025-03-13T11:43:16Z

commit 9e512eaaf8f4008c44ede3dfc0fbc9d9c5118583 upstream. When flushing the serial port's buffer, uart_flush_buffer() calls kfifo_reset() but if there is an outstanding DMA transfer then the completion function will consume data from the kfifo via uart_xmit_advance(), underflowing and leading to ongoing DMA as the driver tries to transmit another 2^32 bytes. This is readily reproduced with serial-generic and amidi sending even short messages as closing the device on exit will wait for the fifo to drain and in the underflow case amidi hangs for 30 seconds on exit in tty_wait_until_sent(). A trace of that gives: kworker/1:1-84 [001] 51.769423: bprint: serial8250_tx_dma: tx_size=3 fifo_len=3 amidi-763 [001] 51.769460: bprint: uart_flush_buffer: resetting fifo irq/21-fe530000-76 [000] 51.769474: bprint: __dma_tx_complete: tx_size=3 irq/21-fe530000-76 [000] 51.769479: bprint: serial8250_tx_dma: tx_size=4096 fifo_len=4294967293 irq/21-fe530000-76 [000] 51.781295: bprint: __dma_tx_complete: tx_size=4096 irq/21-fe530000-76 [000] 51.781301: bprint: serial8250_tx_dma: tx_size=4096 fifo_len=4294963197 irq/21-fe530000-76 [000] 51.793131: bprint: __dma_tx_complete: tx_size=4096 irq/21-fe530000-76 [000] 51.793135: bprint: serial8250_tx_dma: tx_size=4096 fifo_len=4294959101 irq/21-fe530000-76 [000] 51.804949: bprint: __dma_tx_complete: tx_size=4096 Since the port lock is held in when the kfifo is reset in uart_flush_buffer() and in __dma_tx_complete(), adding a flush_buffer hook to adjust the outstanding DMA byte count is sufficient to avoid the kfifo underflow. Fixes: 9ee4b83e51f74 ("serial: 8250: Add support for dmaengine") Cc: stable Signed-off-by: John Keeping Link: https://lore.kernel.org/r/20250208124148.1189191-1-jkeeping@inmusicbrands.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: omap: Move pm_runtime_get_sync

2024-12-14T18:44:37Z

commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream. Currently in omap_8250_shutdown, the dma->rx_running flag is set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync is called, which is a runtime resume call stack which can re-set the flag. When the call omap_8250_shutdown returns, the flag is expected to be UN-SET, but this is not the case. This is causing issues the next time UART is re-opened and omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync before the omap_8250_rx_dma_flush. cc: stable@vger.kernel.org Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") Signed-off-by: Bin Liu [Judith: Add commit message] Signed-off-by: Judith Mendez Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_exar: Don't remove GPIO device on suspend

2024-03-26T22:22:24Z

[ Upstream commit 73b5a5c00be39e23b194bad10e1ea8bb73eee176 ] It seems a copy&paste mistake that suspend callback removes the GPIO device. There is no counterpart of this action, means once suspended there is no more GPIO device available untile full unbind-bind cycle is performed. Remove suspicious GPIO device removal in suspend. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240219150627.2101198-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin