kernel/git/stable/linux.git/drivers/tty/serial/8250, branch master

Merge tag 'tty-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2026-07-12T19:29:38+00:00

Pull tty/serial fixes from Greg KH: "Here are some small tty/serial/vt fixes for 7.2-rc3 that resolve some reported problems. Included in here are: - vt spurious modifier issue that showed up in -rc1 (reported a bunch) - 8250 driver bugfixes - msm serial driver bugfix - max310x serial driver bugfix All of these have been in linux-next with no reported issues" * tag 'tty-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: 8250: Ignore flow control on suspend/resume with no_console_suspend serial: 8250_mid: Disable DMA for selected platforms serial: 8250_omap: clear rx_running on zero-length DMA completes vt: fix spurious modifier in CSI/cursor key sequences serial: msm: Disable DMA for kernel console UART serial: max310x: implement gpio_chip::get_direction()

serial: 8250: Ignore flow control on suspend/resume with no_console_suspend

2026-07-10T12:47:30+00:00

If no_console_suspend is specified, on suspend the 8250 console driver uses a scratch register (UART_SCR) to store a special canary value. This is used during the resume path to identify a printk() call before the driver's own ->resume() callback. In this case, serial8250_console_restore() is called to quickly re-init the 8250 for console printing. See commit 4516d50aabed ("serial: 8250: Use canary to restart console after suspend") for the original motivation. Unfortunately, this canary workaround does not work in all cases (such as suspend to mem) because the scratch register will not reset. This has not been a real issue until now because it could simply lead to some garbage characters upon resume. However, with the introduction of console flow control it becomes a real problem because a failed suspend/resume detection when flow control is enabled leads to all characters hitting the flow control timeout. Workaround this issue by temporarily ignoring console flow control when the debug canary suspend/resume detection is active. Fixes: 5e6dfb87b191 ("serial: 8250: Add support for console flow control") Signed-off-by: John Ogness Link: https://patch.msgid.link/20260707141032.5074-1-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman

serial: 8250_mid: Disable DMA for selected platforms

2026-07-10T12:47:16+00:00

In accordance with Errata (specification updates) HSUART May Stop Functioning when DMA is Active. - Denverton document #572409, rev 3.4, DNV60 - Ice Lake Xeon D document #714070, ICXD65 - Snowridge document #731931, SNR44 For a quick fix just disable the respective callbacks during the device probe. Depending on the future development we might remove them completely. Reported-by: micas-opensource Closes: https://lore.kernel.org/linux-serial/20250625031409.2404219-1-opensource@ruijie.com.cn/ Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Cc: stable Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260626094937.561776-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: clear rx_running on zero-length DMA completes

2026-07-10T12:46:54+00:00

On AM33xx RX DMA only triggers when the FIFO reaches the configured threshold (typically 48 bytes). For smaller bursts no DMA request is issued and the FIFO is drained by RX timeout. In this case __dma_rx_do_complete() can legitimately see count == 0. The current code exits early in this case and does not clear dma->rx_running, leaving the DMA state inconsistent. This can prevent RX DMA from restarting and may cause omap_8250_rx_dma_flush() to fail, marking DMA as broken. Fix this by clearing dma->rx_running once the DMA transfer has completed or been terminated, even if no data was transferred. Fixes: a5fd8945a478 ("serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done") Cc: stable Signed-off-by: Matthias Feser Reviewed-by: Moteen Shah Link: https://patch.msgid.link/BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman

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