kernel/linux.git/drivers/tty/serial/serial_core.c, branch v6.19.12

serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN

2026-03-25T10:13:20+00:00

commit 455ce986fa356ff43a43c0d363ba95fa152f21d5 upstream. uart_write_room() and uart_write() behave inconsistently when xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were never properly initialized): - uart_write_room() returns kfifo_avail() which can be > 0 - uart_write() checks xmit_buf and returns 0 if NULL This inconsistency causes an infinite loop in drivers that rely on tty_write_room() to determine if they can write: while (tty_write_room(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits } For example, caif_serial's handle_tx() enters an infinite loop when used with PORT_UNKNOWN serial ports, causing system hangs. Fix by making uart_write_room() also check xmit_buf and return 0 if it's NULL, consistent with uart_write(). Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13 Signed-off-by: Jiayuan Chen Cc: stable Link: https://patch.msgid.link/20260204074327.226165-1-jiayuan.chen@linux.dev Signed-off-by: Greg Kroah-Hartman

serial: Fix not set tty->port race condition

2026-01-23T16:23:09+00:00

Revert commit bfc467db60b7 ("serial: remove redundant tty_port_link_device()") because the tty_port_link_device() is not redundant: the tty->port has to be confured before we call uart_configure_port(), otherwise user-space can open console without TTY linked to the driver. This tty_port_link_device() was added explicitly to avoid this exact issue in commit fb2b90014d78 ("tty: link tty and port before configuring it as console"), so offending commit basically reverted the fix saying it is redundant without addressing the actual race condition presented there. Reproducible always as tty->port warning on Qualcomm SoC with most of devices disabled, so with very fast boot, and one serial device being the console: printk: legacy console [ttyMSM0] enabled printk: legacy console [ttyMSM0] enabled printk: legacy bootconsole [qcom_geni0] disabled printk: legacy bootconsole [qcom_geni0] disabled ------------[ cut here ]------------ tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver! WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1 Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6 CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. Eliza (DT) ... tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P) tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3)) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:962) vfs_open (fs/open.c:1094) do_open (fs/namei.c:4634) path_openat (fs/namei.c:4793) do_filp_open (fs/namei.c:4820) do_sys_openat2 (fs/open.c:1391 (discriminator 3)) ... Starting Network Name Resolution... Apparently the flow with this small Yocto-based ramdisk user-space is: driver (qcom_geni_serial.c): user-space: ============================ =========== qcom_geni_serial_probe() uart_add_one_port() serial_core_register_port() serial_core_add_one_port() uart_configure_port() register_console() | | open console | ... | tty_init_dev() | driver->ports[idx] is NULL | tty_port_register_device_attr_serdev() tty_port_link_device() <- set driver->ports[idx] Fixes: bfc467db60b7 ("serial: remove redundant tty_port_link_device()") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Reviewed-by: Jiri Slaby Link: https://patch.msgid.link/20260123072139.53293-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman

serial: Keep rs485 settings for devices without firmware node

2025-11-26T12:13:37+00:00

Commit fe7f0fa43cef ("serial: 8250: Support rs485 devicetree properties") retrieves rs485 properties for 8250 drivers. These properties are read from the firmware node of the device within uart_get_rs485_mode(). If the firmware node does not exist, then the rs485 flags are still reset. Thus, 8250 driver cannot set rs485 flags to enable a defined rs485 mode during driver loading. This is no problem so far, as no 8250 driver sets the rs485 flags. The default rs485 mode can also be set by firmware nodes. But for some devices a firmware node does not exist. E.g., for a PCIe based serial interface on x86 no device tree is available and the ACPI information of the BIOS often cannot by modified. In this case it shall be possible, that a driver works out of the box by setting a reasonable default rs485 mode. If no firmware node exists, then it should be possible for the driver to set a reasonable default rs485 mode. Therefore, reset rs485 flags only if a firmware node exists. Signed-off-by: Gerhard Engleder Cc: Lukas Wunner Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20251023151229.11774-2-gerhard@engleder-embedded.com Signed-off-by: Greg Kroah-Hartman

serial: serial_core: use guard()s

2025-11-21T17:30:40+00:00

Use guards in the serial_core code. This improves readability, makes error handling easier, and marks locked portions of code explicit. All that while being sure the lock is unlocked. Signed-off-by: Jiri Slaby (SUSE) Link: https://patch.msgid.link/20251119100140.830761-11-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: serial_core: simplify uart_ioctl() returns

2025-11-21T17:30:40+00:00

Neither uart_do_autoconfig(), nor uart_wait_modem_status() can return -ENOIOCTLCMD. The ENOIOCTLCMD checks are there to check if 'cmd' matched against TIOCSERCONFIG, and TIOCMIWAIT respectively. (With 0 or error in 'ret', it does not matter.) Therefore, the code can simply return from the TIOCSERCONFIG and TIOCMIWAIT spots immediately. To be more explicit, use 'if' instead of switch-case for those single values. And return without jumping to the 'out' label -- it can be removed too. Signed-off-by: Jiri Slaby (SUSE) Link: https://patch.msgid.link/20251119100140.830761-10-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: serial_core: use guard()s

2025-08-17T10:46:26+00:00

Having all the new guards, use them in the serial_core code. This improves readability, makes error handling easier, and marks locked portions of code explicit. Signed-off-by: "Jiri Slaby (SUSE)" Link: https://lore.kernel.org/r/20250814072456.182853-9-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

tty: serial: fix print format specifiers

2025-06-19T11:24:33+00:00

The serial info sometimes produces negative TX/RX counts. E.g.: 3: uart:FSL_LPUART mmio:0x02970000 irq:46 tx:-1595870545 rx:339619 RTS|CTS|DTR|DSR|CD It appears that the print format specifiers don't match with the types of the respective variables. E.g.: All of the fields in struct uart_icount are u32, but the format specifier used is %d, even though u32 is unsigned and %d is for signed integers. Update drivers/tty/serial/serial_core.c to use the proper format specifiers. Reference https://docs.kernel.org/core-api/printk-formats.html as the documentation for what format specifiers are the proper ones to use for a given C type. Signed-off-by: Joseph Tilahun Link: https://lore.kernel.org/r/20250610065653.3750067-1-jtilahun@astranis.com Signed-off-by: Greg Kroah-Hartman

serial: Remove unused uart_get_console

2025-06-19T11:24:16+00:00

uart_get_console() has been unused since 2019's commit bd0d9d159988 ("serial: remove ks8695 driver") Remove it, and it's associated docs. Signed-off-by: "Dr. David Alan Gilbert" Acked-by: Randy Dunlap Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250608154654.73994-1-linux@treblig.org Signed-off-by: Greg Kroah-Hartman

tty: introduce and use tty_port_tty_vhangup() helper

2025-06-17T11:42:33+00:00

This code (tty_get -> vhangup -> tty_put) is repeated on few places. Introduce a helper similar to tty_port_tty_hangup() (asynchronous) to handle even vhangup (synchronous). And use it on those places. In fact, reuse the tty_port_tty_hangup()'s code and call tty_vhangup() depending on a new bool parameter. Signed-off-by: "Jiri Slaby (SUSE)" Cc: Karsten Keil Cc: David Lin Cc: Johan Hovold Cc: Alex Elder Cc: Oliver Neukum Cc: Marcel Holtmann Cc: Johan Hedberg Cc: Luiz Augusto von Dentz Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20250611100319.186924-2-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: use uart_port_ref_lock() helper

2025-04-25T11:46:31+00:00

uart_get_icount() and uart_carrier_raised() open code uart_port_ref_lock(). Use the helper instead. The difference is we use _irqsave() variants of a spinlock now. But that's "safer" than _irq(). Signed-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20250425111315.1036184-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman