kernel/git/next/linux-next.git/drivers/tty/serial, branch master

Merge branch 'tty-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git

2026-07-10T12:28:39+00:00

Merge branch 'tty-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git

2026-07-10T10:46:21+00:00

serial: msm: Disable DMA for kernel console UART

2026-07-07T15:24:42+00:00

At the moment, concurrent writes from userspace and the kernel to the console can trigger a race condition that results in an infinite loop of the same messages printed over and over again. This is most likely to happen during system startup or shutdown when the init system starts/stops a large number of system services that interact with various kernel code. When userspace writes to the TTY device, the driver initiates an asynchronous DMA transfer and releases the port lock. At the same moment, the kernel printk path might grab the port lock and re-configure the UART controller for PIO, without waiting for the DMA operation to complete. It seems like this collision results in zero progress being reported for the DMA engine, so the same text is printed to the console over and over again. For the kernel console, we want a reliable output path that will be functional even during crashes etc. So rather than implementing complex code to synchronize the kernel console write routines with the userspace DMA write routines, simply disable DMA for the console UART instance. Similar checks exist in many other serial drivers, e.g. 8250_port.c, imx.c, sh-sci.c etc. Cc: stable Fixes: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") Signed-off-by: Stephan Gerhold Acked-by: Konrad Dybcio Link: https://patch.msgid.link/20260706-serial-msm-console-dma-collision-v1-1-3179b8cb1d89@linaro.org Signed-off-by: Greg Kroah-Hartman

serial: max310x: implement gpio_chip::get_direction()

2026-07-07T15:24:08+00:00

It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit selects output), which the existing direction_input/output callbacks already program, so the current direction can be read back directly. Fixes: f65444187a66 ("serial: New serial driver MAX310X") Cc: stable Signed-off-by: Tapio Reijonen Reviewed-by: Linus Walleij Reviewed-by: Bartosz Golaszewski Reviewed-by: Hugo Villeneuve Link: https://patch.msgid.link/20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com Signed-off-by: Greg Kroah-Hartman

serial: max310x: honour rs485 properties from per-channel DT subnode

2026-07-07T15:22:34+00:00

The MAX310x DT binding pulls in /schemas/serial/rs485.yaml via its allOf list, advertising the rs485-* properties defined there - none of which were honoured at runtime, because the driver never called uart_get_rs485_mode(). All channels share the parent SPI/I2C device, so uart_get_rs485_mode() called directly on each port would read the same chip-level fwnode for every call. Walk dev->of_node's children for the "serial@N" subnode with matching reg, and temporarily retarget the parent device's fwnode while uart_get_rs485_mode() runs, so each channel picks up its own subnode's properties. Probe is serialised, so the swap is safe. For single-channel variants (max3107, max3108), fall back to the chip's own fwnode when no subnode is present, so existing DTs that declare rs485 properties at the top level keep working. Signed-off-by: Tapio Reijonen Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-3-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman

serial: max310x: register GPIO controller before adding UART ports

2026-07-07T15:22:34+00:00

The MAX310x exposes four GPIOs per UART port via an in-driver gpio_chip. devm_gpiochip_add_data() used to run after the per-port uart_add_one_port() loop, so a device-tree consumer referencing one of the chip's own GPIOs (for example rs485-term-gpios = <&max310x 0 ...>) could not resolve it during port registration: the GPIO provider it waits for is the very driver still trying to register, and the lookup returns -EPROBE_DEFER on its own provider, deferring probe forever. Split the per-port setup into two passes around the gpio_chip registration: 1. Initialise per-port state - port struct fields, regmap binding, IRQ disable, work queues. The gpio_chip callbacks dereference s->p[i].regmap via to_max310x_port() and become callable as soon as the chip is visible to gpiolib, so every entry must be populated first. 2. devm_gpiochip_add_data() - register the gpio_chip. 3. Allocate a line, uart_add_one_port(), set_bit(), max310x_power(). Keeping line allocation, registration and set_bit() together preserves the existing "bit set <=> port registered" rollback invariant that out_uart relies on. Signed-off-by: Tapio Reijonen Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-1-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman

tty: serial: men_z135_uart: replace __get_free_page() with kmalloc()

2026-07-07T15:22:10+00:00

men_z135_probe() allocates a receive staging buffer filled by the CPU via memcpy_fromio() from the device MMIO region. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) Link: https://patch.msgid.link/20260528-b4-tty-v1-3-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: pch: replace __get_free_page() with kmalloc()

2026-07-07T15:21:31+00:00

pch_uart_init_port() allocates a staging buffer for non-DMA receive path using __get_free_page(). This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) Link: https://patch.msgid.link/20260528-b4-tty-v1-1-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman

tty: serial: rp2: Use named initializer for pci_device_id::driver_data

2026-07-07T12:27:24+00:00

The .driver_data member of the struct pci_device_id array were initialized by list expressions relying on hidden assignment of .class and .class_mask in PCI_VDEVICE(). Make the initialization more robust by using a named initializer. This robustness is relevant for a planned change to struct pci_device_id that replaces .driver_data by an anonymous union. This change doesn't introduce changes to the compiled pci_device_id array. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260524131905.871222-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_exar: Consistently define pci_device_ids using named initializers

2026-07-07T12:27:21+00:00

The .driver_data member of the struct pci_device_id array were initialized by list expressions. This isn't easily readable if you're not into PCI, still more given that it's hidden in macros. Using named initializers is more explicit and thus easier to parse for a human. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct pci_device_id that replaces .driver_data by an anonymous union. Also drop a few explicit zeros that are not needed and improve indention. This change doesn't introduce changes to the compiled pci_device_id array. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://patch.msgid.link/20260522140103.769262-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman