kernel/linux.git/drivers/tty/serial/8250, branch v7.2-rc2

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

serial: 8250_pci: Don't specify conflicting values to pci_device_id members

2026-06-12T09:55:41+00:00

The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the next value in the initializer to define the value for .driver_data. So the construct { PCI_VDEVICE(INTASHIELD, 0x0D21), .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, .class_mask = 0xffff00, .driver_data = pbn_b2_4_115200, }, introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers") has conflicting assignments. In only some configurations (i.e. W=1 for me) that makes the compiler unhappy. So convert the two affected items to PCI_DEVICE which doesn't have that hidden assigment to .class and .class_mask. Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers") Signed-off-by: Uwe Kleine-König (The Capable Hub) Reported-by: Andy Shevchenko Closes: https://lore.kernel.org/linux-serial/ah_5qVKOf8LXG1Xo@ashevche-desk.local/T/#ma6eab90ca801b4292639f5c255a89b4033b33d21 Tested-by: Andy Shevchenko Link: https://patch.msgid.link/20260603095616.937968-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'v7.1-rc6' into tty-next

2026-06-01T16:08:02+00:00

We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: dispatch SysRq character in dw8250_handle_irq()

2026-05-22T09:51:35+00:00

dw8250_handle_irq() calls serial8250_handle_irq_locked() with the port lock held via guard(uart_port_lock_irqsave). The guard destructor is plain uart_port_unlock_irqrestore(), so a SysRq character captured into port->sysrq_ch by uart_prepare_sysrq_char() is dropped without ever being dispatched to handle_sysrq(). This is the same regression pattern as in serial8250_handle_irq(), introduced when 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") moved the function to the guard()-based locking scheme without using the sysrq-aware unlock helper. Switch to guard(uart_port_lock_check_sysrq_irqsave) so that captured sysrq_ch is dispatched on scope exit, matching the fix in serial8250_handle_irq(). Fixes: 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Jacques Nilo Link: https://patch.msgid.link/ed56fcaf4af24e4ed011a7bce206e0182acb761c.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman

serial: 8250: dispatch SysRq character in serial8250_handle_irq()

2026-05-22T09:51:35+00:00

serial8250_handle_irq() captures a SysRq character into port->sysrq_ch inside serial8250_handle_irq_locked() via uart_prepare_sysrq_char() (reached from serial8250_read_char()). Dispatch of that captured character to handle_sysrq() is expected to happen at port-unlock time, through uart_unlock_and_check_sysrq[_irqrestore](). After commit 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") the function was reduced to a wrapper that takes the port lock via guard(uart_port_lock_irqsave) whose destructor is plain uart_port_unlock_irqrestore(). The sysrq-aware unlock helper is no longer called, so port->sysrq_ch is captured but never dispatched: BREAK + SysRq key is consumed silently. This was the very condition Johan Hovold's 853a9ae29e978 ("serial: 8250: fix handle_irq locking", 2021) introduced uart_unlock_and_check_sysrq_irqrestore() to address. Switch to the new guard(uart_port_lock_check_sysrq_irqsave), whose destructor is the sysrq-aware unlock helper, restoring the pre-split behaviour. Update the Context: comment on serial8250_handle_irq_locked() so future HW-specific 8250 wrappers know to use the same guard or the explicit sysrq-aware unlock. Verified on RTL8196E with CONFIG_MAGIC_SYSRQ_SERIAL=y: BREAK + 'h' on the console UART produces the SysRq help dump in dmesg and the brk counter in /proc/tty/driver/serial increments correctly. Fixes: 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen Signed-off-by: Jacques Nilo Link: https://patch.msgid.link/52692ae6c3501f7940347cef364ad7fcacaab7e5.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman

serial: 8250: fix possible ISR soft lockup

2026-05-22T09:47:22+00:00

There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected. Signed-off-by: Marco Felsch Link: https://patch.msgid.link/20260519-v7-1-topic-serial-8250-v1-1-56b04293a246@pengutronix.de Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: remove clock-notifier infrastructure

2026-05-22T09:46:18+00:00

The clock notifier and matching work_struct in dw8250_data were added in 2020 for the Baikal-T1 SoC, whose multiple UART ports share a single reference clock and need to be informed when another consumer re-rates that clock. Baikal SoC support has since been removed from the kernel (see e.g. commit 5d6c477687ae ("clk: baikal-t1: Remove not-going-to-be-supported code for Baikal SoC") and the matching removals across bus/, mtd/, PCI/, hwmon/, memory/). No remaining in-tree user needs the cross-device baudclk rate-change notification path: the only configuration that wired up the notifier was Baikal-T1's shared reference clock topology. Drop the now-unused clock-notifier and its deferred-update worker: - struct dw8250_data fields clk_notifier and clk_work, - the clk_to_dw8250_data() and work_to_dw8250_data() helpers, - the dw8250_clk_work_cb() and dw8250_clk_notifier_cb() callbacks, - the INIT_WORK / notifier_call setup in dw8250_probe(), - the clk_notifier_register() / queue_work() in dw8250_probe(), - the matching clk_notifier_unregister() / flush_work() in dw8250_remove(), - the stale comment in dw8250_set_termios() about the worker blocking, - the linux/notifier.h and linux/workqueue.h includes that are no longer used. dw8250_set_termios() keeps calling clk_set_rate() directly, which is all the remaining single-UART configurations require. Signed-off-by: Stepan Ionichev Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260514143746.23671-3-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails

2026-05-22T09:46:18+00:00

dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path. Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260514143746.23671-2-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman

serial: 8250: Add support for console flow control

2026-05-22T09:45:41+00:00

The kernel documentation specifies that the console option 'r' can be used to enable hardware flow control for console writes. The 8250 driver does include code for hardware flow control on the console if cons_flow is set, but there is no code path that actually sets this. However, that is not the only issue. The problems are: 1. Specifying the console option 'r' does not lead to cons_flow being set. 2. Even if cons_flow would be set, serial8250_register_8250_port() clears it. 3. When the console option 'r' is specified, uart_set_options() attempts to initialize the port for CRTSCTS. However, afterwards it does not set the UPSTAT_CTS_ENABLE status bit and therefore on boot, uart_cts_enabled() is always false. This policy bit is important for console drivers as a criteria if they may poll CTS. 4. Even though uart_set_options() attempts to initialize the port for CRTSCTS, the 8250 set_termios() callback does not enable the RTS signal (TIOCM_RTS) and thus the hardware is not properly initialized for CTS polling. 5. Even if modem control was properly setup for CTS polling (TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus breaking CTS polling. 6. wait_for_xmitr() and serial8250_console_write() use cons_flow to decide if CTS polling should occur. However, the condition should also include a check that it is not in RS485 mode and CRTSCTS is actually enabled in the hardware. Address all these issues as conservatively as possible by gating them behind checks focussed on the user specifying console hardware flow control support and the hardware being configured for CTS polling at the time of the write to the UART. Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new condition gate, these changes also support runtime termios updates to disable/enable CRTSCTS. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260511152706.151498-4-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman

serial: 8250: Check LSR timeout on console flow control

2026-05-22T09:45:41+00:00

wait_for_xmitr() calls wait_for_lsr() to wait for the transmission registers to be empty. wait_for_lsr() can timeout after a reasonable amount of time. When console flow control is active, wait_for_xmitr() additionally polls CTS, waiting for the peer to signal that it is ready to receive more data. If hardware flow control is enabled (auto CTS) and the peer deasserts CTS, wait_for_lsr() will timeout. If additionally console flow control is active and while polling CTS the peer asserts CTS, the console will assume it can immediately transmit, even though the transmission registers may not be empty. This can lead to data loss. Avoid this problem by performing an extra wait_for_lsr() upon CTS assertion if wait_for_lsr() previously timed out. Signed-off-by: John Ogness Link: https://patch.msgid.link/20260511152706.151498-3-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman