kernel/linux.git/drivers/tty/serial/serial_core.c, branch v7.1-rc5

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

2026-03-12T14:31:41+00:00

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

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

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