* [PATCH v2 2/4] MIPS: SiByte: Fix bootconsole handover lockup
From: Maciej W. Rozycki @ 2026-04-13 4:03 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: Elena Reshetova, David Windsor, Kees Cook, Hans Liljestrand,
linux-mips, linux-serial, linux-kernel
In-Reply-To: <alpine.DEB.2.21.2604130453400.29980@angie.orcam.me.uk>
Calling sbd_init_port() in the course of setting up the serial device
causes line parameters to be messed up and the transmitter disabled.
We've been lucky in that no message is usually produced to the kernel
log between this call and the later call to uart_set_options() in the
course of console setup done by sbd_serial_console_init(), or the system
would hang as the console output handler in CFE tried to access a port
whose transmitter has been disabled and line parameters messed up.
It'll change with the next change to the driver, so fix sbd_init_port()
such that line parameters are set for 115200n8 console operation as with
the CFE firmware and the transmitter re-enabled after reset.
Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Cc: stable@vger.kernel.org # v6.5+
---
No change from v1.
---
drivers/tty/serial/sb1250-duart.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
linux-serial-sb1250-duart-prom-console.diff
Index: linux-macro/drivers/tty/serial/sb1250-duart.c
===================================================================
--- linux-macro.orig/drivers/tty/serial/sb1250-duart.c
+++ linux-macro/drivers/tty/serial/sb1250-duart.c
@@ -542,14 +542,19 @@ static void sbd_init_port(struct sbd_por
/* There is no DUART reset feature, so just set some sane defaults. */
write_sbdchn(sport, R_DUART_CMD, V_DUART_MISC_CMD_RESET_TX);
write_sbdchn(sport, R_DUART_CMD, V_DUART_MISC_CMD_RESET_RX);
- write_sbdchn(sport, R_DUART_MODE_REG_1, V_DUART_BITS_PER_CHAR_8);
+ write_sbdchn(sport, R_DUART_MODE_REG_1,
+ V_DUART_PARITY_MODE_NONE | V_DUART_BITS_PER_CHAR_8);
write_sbdchn(sport, R_DUART_MODE_REG_2, 0);
+ write_sbdchn(sport, R_DUART_CLK_SEL, V_DUART_BAUD_RATE(115200));
write_sbdchn(sport, R_DUART_FULL_CTL,
V_DUART_INT_TIME(0) | V_DUART_SIG_FULL(15));
write_sbdchn(sport, R_DUART_OPCR_X, 0);
write_sbdchn(sport, R_DUART_AUXCTL_X, 0);
write_sbdshr(sport, R_DUART_IMRREG((uport->line) % 2), 0);
+ /* Re-enable transmission for the initial PROM-based console. */
+ write_sbdchn(sport, R_DUART_CMD, M_DUART_TX_EN);
+
sport->initialised = 1;
}
^ permalink raw reply
* [PATCH v2 3/4] MIPS: SiByte: Convert to use a platform device
From: Maciej W. Rozycki @ 2026-04-13 4:03 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: Elena Reshetova, David Windsor, Kees Cook, Hans Liljestrand,
linux-mips, linux-serial, linux-kernel
In-Reply-To: <alpine.DEB.2.21.2604130453400.29980@angie.orcam.me.uk>
Prevent a crash from happening as the first serial port is initialised:
pata-swarm: PATA interface at GenBus slot 4
workingset: timestamp_bits=62 max_order=18 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
CPU 1 Unable to handle kernel paging request at virtual address 0000000000000208, epc == ffffffff8067f8f8, ra == ffffffff80666330
Oops[#1]:
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-dirty #27 NONE
$ 0 : 0000000000000000 0000000014001fe0 0000000000000020 ffffffff80666130
$ 4 : 0000000000000000 a800000100e6f118 ffffffff8112cbc0 0000000000000000
$ 8 : 0000000000000002 0000000000000000 0000000000000000 0000000001a80000
$12 : 0000000000000000 ffffffff809fd488 000000004ddf14dd ffffffff00000000
$16 : a800000100e6f000 0000000000000000 ffffffff8112c1d0 a800000100e6f000
$20 : 0000000000000000 00000000000004d0 0000000000000004 ffffffff8112c1d0
$24 : 0000000000000001 0000000000000003
$28 : a80000010007c000 a80000010007fcb0 00000000000000ef ffffffff80666330
Hi : fffffffffffffdb9
Lo : 0000000000000035
epc : ffffffff8067f8f8 __dev_fwnode+0x0/0x8
ra : ffffffff80666330 serial_base_ctrl_add+0xb8/0x180
Status: 14001fe3 KX SX UX KERNEL EXL IE
Cause : 80800008 (ExcCode 02)
BadVA : 0000000000000208
PrId : 03040102 (SiByte SB1)
Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
Stack : 0000000000000000 ffffffff80cd5178 ffffffff80cd0000 ffffffff8112c1c8
0000000000000260 ffffffff806655c4 a800000100275bc0 ffffffff8064ac88
004000408112c000 0000000000000002 0000000000000000 ffffffff801965d0
a800000100786ba0 ffffffff80cd5178 a800000100786ba0 0000000000000004
a800000100275bc0 0000000000000000 0000000000000000 ffffffff80cd5178
0000000000000000 ffffffff8112c1c8 0000000000000260 00000000000004d0
0000000000000004 ffffffff80bf0000 00000000000000ef ffffffff80d171dc
ffffffff80d17120 ffffffff80d25658 0000000000000000 ffffffff80d50000
ffffffff80d2f928 ffffffff80d50000 ffffffff80d25698 ffffffff80cfcecc
00ffffff80b84428 0000000000000000 0000000000000006 0000000000000006
...
Call Trace:
[<ffffffff8067f8f8>] __dev_fwnode+0x0/0x8
[<ffffffff80666330>] serial_base_ctrl_add+0xb8/0x180
[<ffffffff806655c4>] serial_core_register_port+0x174/0x8e0
[<ffffffff80d171dc>] sbd_init+0xbc/0xf4
[<ffffffff80cfcecc>] do_one_initcall+0x64/0x150
[<ffffffff80cfd284>] kernel_init_freeable+0x25c/0x30c
[<ffffffff809ff6e4>] kernel_init+0x24/0x118
[<ffffffff80112d20>] ret_from_kernel_thread+0x14/0x1c
Code: 67bd0010 03e00008 2402ffea <03e00008> dc820208 67bdffa0 ffbe0050 ffb70048 ffb60040
---[ end trace 0000000000000000 ]---
-- where a pointer is dereferenced that has been derived from a null
pointer to the port's parent device.
Since no device is available with legacy probing and it's not anymore a
preferable way to discover devices anyway, switch the driver to using a
platform device and use it as the port's parent device.
Use platform_driver_probe() because SB1250 DUART devices are embedded
onchip the SoC and therefore not that straightforward to remove.
An unfortunate consequence of the switch to a platform device is we now
hand the console over from the bootconsole much later in the bootstrap.
The CFE console handler appears good enough though to work so late and
in particular with interrupts enabled.
Conversely only starting the console port so late lets the reset code
fully utilise our delay handlers, so switch from udelay() to fsleep()
for transmitter draining so as to avoid busy-waiting for an excessive
amount of time.
Since there is one way only remaining to reach sbd_init_port() now, drop
the port initialisation marker as no longer needed and go through the
channel resets unconditionally.
Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Cc: stable@vger.kernel.org # needs to use .remove_new for <= 6.10
---
Changes from v1:
- Remove a stray `i' variable from sbd_probe().
---
arch/mips/sibyte/swarm/platform.c | 97 +++++++++++++++++++++++--
drivers/tty/serial/sb1250-duart.c | 147 +++++++++++++-------------------------
2 files changed, 145 insertions(+), 99 deletions(-)
linux-serial-sb1250-duart-platform.diff
Index: linux-macro/arch/mips/sibyte/swarm/platform.c
===================================================================
--- linux-macro.orig/arch/mips/sibyte/swarm/platform.c
+++ linux-macro/arch/mips/sibyte/swarm/platform.c
@@ -8,7 +8,13 @@
#include <asm/sibyte/board.h>
#include <asm/sibyte/sb1250_genbus.h>
+#if defined(CONFIG_SIBYTE_BCM1x80)
+#include <asm/sibyte/bcm1480_regs.h>
+#include <asm/sibyte/bcm1480_int.h>
+#else
#include <asm/sibyte/sb1250_regs.h>
+#include <asm/sibyte/sb1250_int.h>
+#endif
#if defined(CONFIG_SIBYTE_SWARM) || defined(CONFIG_SIBYTE_LITTLESUR)
@@ -85,6 +91,82 @@ device_initcall(swarm_pata_init);
#endif /* defined(CONFIG_SIBYTE_SWARM) || defined(CONFIG_SIBYTE_LITTLESUR) */
+#if defined(CONFIG_SIBYTE_BCM1x80)
+static struct resource sb1250_duart_resources[][2] = {
+ {
+ {
+ .name = "sb1250-duart0",
+ .flags = IORESOURCE_MEM,
+ .start = A_BCM1480_DUART0,
+ .end = (A_BCM1480_DUART0 +
+ 4 * BCM1480_DUART_CHANREG_SPACING - 1),
+ },
+ {
+ .name = "sb1250-duart0",
+ .flags = IORESOURCE_IRQ,
+ .start = K_BCM1480_INT_UART_0,
+ .end = K_BCM1480_INT_UART_1,
+ },
+ },
+ {
+ {
+ .name = "sb1250-duart1",
+ .flags = IORESOURCE_MEM,
+ .start = A_BCM1480_DUART1,
+ .end = (A_BCM1480_DUART1 +
+ 4 * BCM1480_DUART_CHANREG_SPACING - 1),
+ },
+ {
+ .name = "sb1250-duart1",
+ .flags = IORESOURCE_IRQ,
+ .start = K_BCM1480_INT_UART_2,
+ .end = K_BCM1480_INT_UART_3,
+ },
+ },
+};
+#else /* !defined(CONFIG_SIBYTE_BCM1x80) */
+static struct resource sb1250_duart_resources[][2] = {
+ {
+ {
+ .name = "sb1250-duart0",
+ .flags = IORESOURCE_MEM,
+ .start = A_DUART,
+ .end = A_DUART + 4 * DUART_CHANREG_SPACING - 1,
+ },
+ {
+ .name = "sb1250-duart0",
+ .flags = IORESOURCE_IRQ,
+ .start = K_INT_UART_0,
+ .end = K_INT_UART_1,
+ },
+ },
+};
+#endif /* !defined(CONFIG_SIBYTE_BCM1x80) */
+
+static struct platform_device sb1250_duart_device[] = {
+ {
+ .name = "sb1250-duart",
+ .id = 0,
+ .resource = sb1250_duart_resources[0],
+ .num_resources = ARRAY_SIZE(sb1250_duart_resources[0]),
+ },
+#if defined(CONFIG_SIBYTE_BCM1x80)
+ {
+ .name = "sb1250-duart",
+ .id = 1,
+ .resource = sb1250_duart_resources[1],
+ .num_resources = ARRAY_SIZE(sb1250_duart_resources[1]),
+ },
+#endif
+};
+
+static struct platform_device *sb1250_duart_devices[] __initdata = {
+ &sb1250_duart_device[0],
+#if defined(CONFIG_SIBYTE_BCM1x80)
+ &sb1250_duart_device[1],
+#endif
+};
+
#define sb1250_dev_struct(num) \
static struct resource sb1250_res##num = { \
.name = "SB1250 MAC " __stringify(num), \
@@ -113,28 +195,31 @@ static struct platform_device *sb1250_de
static int __init sb1250_device_init(void)
{
- int ret;
+ int ret1, ret2;
+
+ ret1 = platform_add_devices(sb1250_duart_devices,
+ ARRAY_SIZE(sb1250_duart_devices));
/* Set the number of available units based on the SOC type. */
switch (soc_type) {
case K_SYS_SOC_TYPE_BCM1250:
case K_SYS_SOC_TYPE_BCM1250_ALT:
- ret = platform_add_devices(sb1250_devs, 3);
+ ret2 = platform_add_devices(sb1250_devs, 3);
break;
case K_SYS_SOC_TYPE_BCM1120:
case K_SYS_SOC_TYPE_BCM1125:
case K_SYS_SOC_TYPE_BCM1125H:
case K_SYS_SOC_TYPE_BCM1250_ALT2: /* Hybrid */
- ret = platform_add_devices(sb1250_devs, 2);
+ ret2 = platform_add_devices(sb1250_devs, 2);
break;
case K_SYS_SOC_TYPE_BCM1x55:
case K_SYS_SOC_TYPE_BCM1x80:
- ret = platform_add_devices(sb1250_devs, 4);
+ ret2 = platform_add_devices(sb1250_devs, 4);
break;
default:
- ret = -ENODEV;
+ ret2 = 0;
break;
}
- return ret;
+ return ret1 ? ret1 : ret2;
}
device_initcall(sb1250_device_init);
Index: linux-macro/drivers/tty/serial/sb1250-duart.c
===================================================================
--- linux-macro.orig/drivers/tty/serial/sb1250-duart.c
+++ linux-macro/drivers/tty/serial/sb1250-duart.c
@@ -3,7 +3,7 @@
* Support for the asynchronous serial interface (DUART) included
* in the BCM1250 and derived System-On-a-Chip (SOC) devices.
*
- * Copyright (c) 2007 Maciej W. Rozycki
+ * Copyright (c) 2007, 2026 Maciej W. Rozycki
*
* Derived from drivers/char/sb1250_duart.c for which the following
* copyright applies:
@@ -25,6 +25,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/major.h>
+#include <linux/platform_device.h>
#include <linux/serial.h>
#include <linux/serial_core.h>
#include <linux/spinlock.h>
@@ -45,10 +46,6 @@
#include <asm/sibyte/bcm1480_regs.h>
#include <asm/sibyte/bcm1480_int.h>
-#define SBD_CHANREGS(line) A_BCM1480_DUART_CHANREG((line), 0)
-#define SBD_CTRLREGS(line) A_BCM1480_DUART_CTRLREG((line), 0)
-#define SBD_INT(line) (K_BCM1480_INT_UART_0 + (line))
-
#define DUART_CHANREG_SPACING BCM1480_DUART_CHANREG_SPACING
#define R_DUART_IMRREG(line) R_BCM1480_DUART_IMRREG(line)
@@ -59,10 +56,6 @@
#include <asm/sibyte/sb1250_regs.h>
#include <asm/sibyte/sb1250_int.h>
-#define SBD_CHANREGS(line) A_DUART_CHANREG((line), 0)
-#define SBD_CTRLREGS(line) A_DUART_CTRLREG(0)
-#define SBD_INT(line) (K_INT_UART_0 + (line))
-
#else
#error invalid SB1250 UART configuration
@@ -85,7 +78,6 @@ struct sbd_port {
struct uart_port port;
unsigned char __iomem *memctrl;
int tx_stopped;
- int initialised;
};
/*
@@ -100,6 +92,7 @@ struct sbd_duart {
#define to_sport(uport) container_of(uport, struct sbd_port, port)
static struct sbd_duart sbd_duarts[DUART_MAX_CHIP];
+static struct uart_driver sbd_reg;
/*
@@ -514,8 +507,6 @@ static void sbd_init_port(struct sbd_por
{
struct uart_port *uport = &sport->port;
- if (sport->initialised)
- return;
/*
* Contrary to documentation, which says that the transmitter
* empty bit is set when "there are no characters to send and
@@ -537,7 +528,7 @@ static void sbd_init_port(struct sbd_por
* a standard CFE firmware compilation.
*/
sbd_line_drain(sport);
- udelay(100);
+ fsleep(100);
/* There is no DUART reset feature, so just set some sane defaults. */
write_sbdchn(sport, R_DUART_CMD, V_DUART_MISC_CMD_RESET_TX);
@@ -554,8 +545,6 @@ static void sbd_init_port(struct sbd_por
/* Re-enable transmission for the initial PROM-based console. */
write_sbdchn(sport, R_DUART_CMD, M_DUART_TX_EN);
-
- sport->initialised = 1;
}
static void sbd_set_termios(struct uart_port *uport, struct ktermios *termios,
@@ -794,50 +783,54 @@ static const struct uart_ops sbd_ops = {
};
/* Initialize SB1250 DUART port structures. */
-static void __init sbd_probe_duarts(void)
+static int __init sbd_probe(struct platform_device *pdev)
{
- static int probed;
+ struct resource *mem_resource, *irq_resource;
int chip, side;
- int max_lines, line;
- if (probed)
- return;
+ mem_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ irq_resource = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!mem_resource || !irq_resource)
+ return -ENODEV;
- /* Set the number of available units based on the SOC type. */
- switch (soc_type) {
- case K_SYS_SOC_TYPE_BCM1x55:
- case K_SYS_SOC_TYPE_BCM1x80:
- max_lines = 4;
- break;
- default:
- /* Assume at least two serial ports at the normal address. */
- max_lines = 2;
- break;
- }
+ chip = pdev->id;
+ sbd_duarts[chip].mapctrl = mem_resource->start +
+ DUART_CHANREG_SPACING * 3;
+ for (side = 0; side < DUART_MAX_SIDE; side++) {
+ struct sbd_port *sport = &sbd_duarts[chip].sport[side];
+ struct uart_port *uport = &sport->port;
- probed = 1;
+ sport->duart = &sbd_duarts[chip];
- for (chip = 0, line = 0; chip < DUART_MAX_CHIP && line < max_lines;
- chip++) {
- sbd_duarts[chip].mapctrl = SBD_CTRLREGS(line);
+ uport->dev = &pdev->dev;
+ uport->irq = irq_resource->start + side;
+ uport->uartclk = 100000000 / 20 * 16;
+ uport->fifosize = 16;
+ uport->iotype = UPIO_MEM;
+ uport->flags = UPF_BOOT_AUTOCONF;
+ uport->ops = &sbd_ops;
+ uport->line = chip * DUART_MAX_SIDE + side;
+ uport->mapbase = mem_resource->start +
+ DUART_CHANREG_SPACING * (side + 1);
+ uport->has_sysrq = IS_ENABLED(CONFIG_SERIAL_SB1250_DUART_CONSOLE);
+ if (uart_add_one_port(&sbd_reg, uport))
+ uport->dev = NULL;
+ }
- for (side = 0; side < DUART_MAX_SIDE && line < max_lines;
- side++, line++) {
- struct sbd_port *sport = &sbd_duarts[chip].sport[side];
- struct uart_port *uport = &sport->port;
+ return 0;
+}
- sport->duart = &sbd_duarts[chip];
+static void __exit sbd_remove(struct platform_device *pdev)
+{
+ int chip, side;
- uport->irq = SBD_INT(line);
- uport->uartclk = 100000000 / 20 * 16;
- uport->fifosize = 16;
- uport->iotype = UPIO_MEM;
- uport->flags = UPF_BOOT_AUTOCONF;
- uport->ops = &sbd_ops;
- uport->line = line;
- uport->mapbase = SBD_CHANREGS(line);
- uport->has_sysrq = IS_ENABLED(CONFIG_SERIAL_SB1250_DUART_CONSOLE);
- }
+ chip = pdev->id;
+ for (side = DUART_MAX_SIDE - 1; side >= 0; side--) {
+ struct sbd_port *sport = &sbd_duarts[chip].sport[side];
+ struct uart_port *uport = &sport->port;
+
+ if (uport->dev)
+ uart_remove_one_port(&sbd_reg, uport);
}
}
@@ -895,23 +888,14 @@ static int __init sbd_console_setup(stru
int bits = 8;
int parity = 'n';
int flow = 'n';
- int ret;
if (!sport->duart)
return -ENXIO;
-
- ret = sbd_map_port(uport);
- if (ret)
- return ret;
-
- sbd_init_port(sport);
-
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
return uart_set_options(uport, co, baud, parity, bits, flow);
}
-static struct uart_driver sbd_reg;
static struct console sbd_console = {
.name = "duart",
.write = sbd_console_write,
@@ -922,16 +906,6 @@ static struct console sbd_console = {
.data = &sbd_reg
};
-static int __init sbd_serial_console_init(void)
-{
- sbd_probe_duarts();
- register_console(&sbd_console);
-
- return 0;
-}
-
-console_initcall(sbd_serial_console_init);
-
#define SERIAL_SB1250_DUART_CONSOLE &sbd_console
#else
#define SERIAL_SB1250_DUART_CONSOLE NULL
@@ -948,43 +922,30 @@ static struct uart_driver sbd_reg = {
.cons = SERIAL_SB1250_DUART_CONSOLE,
};
+static struct platform_driver sbd_driver = {
+ .remove = __exit_p(sbd_remove),
+ .driver = { .name = "sb1250-duart" },
+};
+
/* Set up the driver and register it. */
static int __init sbd_init(void)
{
- int i, ret;
-
- sbd_probe_duarts();
+ int ret;
ret = uart_register_driver(&sbd_reg);
if (ret)
return ret;
+ ret = platform_driver_probe(&sbd_driver, sbd_probe);
+ if (ret)
+ uart_unregister_driver(&sbd_reg);
- for (i = 0; i < DUART_MAX_CHIP * DUART_MAX_SIDE; i++) {
- struct sbd_duart *duart = &sbd_duarts[i / DUART_MAX_SIDE];
- struct sbd_port *sport = &duart->sport[i % DUART_MAX_SIDE];
- struct uart_port *uport = &sport->port;
-
- if (sport->duart)
- uart_add_one_port(&sbd_reg, uport);
- }
-
- return 0;
+ return ret;
}
/* Unload the driver. Unregister stuff, get ready to go away. */
static void __exit sbd_exit(void)
{
- int i;
-
- for (i = DUART_MAX_CHIP * DUART_MAX_SIDE - 1; i >= 0; i--) {
- struct sbd_duart *duart = &sbd_duarts[i / DUART_MAX_SIDE];
- struct sbd_port *sport = &duart->sport[i % DUART_MAX_SIDE];
- struct uart_port *uport = &sport->port;
-
- if (sport->duart)
- uart_remove_one_port(&sbd_reg, uport);
- }
-
+ platform_driver_unregister(&sbd_driver);
uart_unregister_driver(&sbd_reg);
}
^ permalink raw reply
* [PATCH v2 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t"
From: Maciej W. Rozycki @ 2026-04-13 4:03 UTC (permalink / raw)
To: Thomas Bogendoerfer, Greg Kroah-Hartman, Jiri Slaby
Cc: Elena Reshetova, David Windsor, Kees Cook, Hans Liljestrand,
linux-mips, linux-serial, linux-kernel
In-Reply-To: <alpine.DEB.2.21.2604130453400.29980@angie.orcam.me.uk>
Revert commit 22a33651a56f ("drivers: convert sbd_duart.map_guard from
atomic_t to refcount_t"), which broke perfectly valid code:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at lib/refcount.c:114 sbd_request_port+0x54/0x140
refcount_t: increment on 0; use-after-free.
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc2+ #34
Stack : 0000000014001fe0 0000000000000000 ffffffff80830000 0000000000000000
ffffffff8127bc7a ffffffff8016fe08 ffffffff808d0000 ffffffff808d0000
ffffffff807aa828 ffffffff80822337 ffffffff808ce188 a8000001860b0000
0000000000000001 0000000000000001 00000000000001c8 ffffffff808a3090
00000000000000bb ffffffff801b09d4 a80000018609bb68 ffffffff801231cc
ffffffff812a0000 ffffffff80171388 0000000000001000 ffffffff807aa828
0000000000000001 0000000000000001 0000000000000000 0000000000000000
0000000000000000 a80000018609bab0 0000000000000000 ffffffff803c47cc
0000000000000000 0000000000000000 0000000000000000 0000000000000000
ffffffff807cb648 ffffffff8010bff8 0000000014001fe1 ffffffff803c47cc
...
Call Trace:
[<ffffffff8010bff8>] show_stack+0x28/0x88
[<ffffffff803c47cc>] dump_stack+0x8c/0xc0
[<ffffffff801aff5c>] __warn+0xe0/0x114
[<ffffffff801233f0>] warn_slowpath_fmt+0x40/0x50
[<ffffffff80455bcc>] sbd_request_port+0x54/0x140
[<ffffffff804563a4>] sbd_config_port+0x2c/0x68
---[ end trace f666d696412caa3e ]---
(report at the offending commit) -- sbd_request_port() is called twice
per DUART instance, to reserve a resource holding the control register
block shared between the two channels, so there's no slightest chance
for an overflow. Also this doesn't stop the driver from working and
it's just the reservation that is missing as a result, i.e.:
10060100-100601ff : sb1250-duart
10060200-100602ff : sb1250-duart
as from the offending change, vs:
10060100-100601ff : sb1250-duart
10060200-100602ff : sb1250-duart
10060300-100603ff : sb1250-duart
beforehand, which is surely why the breakage has gone so long unnoticed.
"If it ain't broke, don't fix it," so just revert the broken commit.
Fixes: 22a33651a56f ("drivers: convert sbd_duart.map_guard from atomic_t to refcount_t")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
No change from v1.
---
drivers/tty/serial/sb1250-duart.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
linux-serial-sb1250-duart-map-guard-atomic.diff
Index: linux-macro/drivers/tty/serial/sb1250-duart.c
===================================================================
--- linux-macro.orig/drivers/tty/serial/sb1250-duart.c
+++ linux-macro/drivers/tty/serial/sb1250-duart.c
@@ -34,8 +34,8 @@
#include <linux/tty_flip.h>
#include <linux/types.h>
-#include <linux/refcount.h>
-#include <linux/io.h>
+#include <linux/atomic.h>
+#include <asm/io.h>
#include <asm/sibyte/sb1250.h>
#include <asm/sibyte/sb1250_uart.h>
@@ -86,7 +86,7 @@ struct sbd_port {
struct sbd_duart {
struct sbd_port sport[2];
unsigned long mapctrl;
- refcount_t map_guard;
+ atomic_t map_guard;
};
#define to_sport(uport) container_of(uport, struct sbd_port, port)
@@ -662,13 +662,15 @@ static void sbd_release_port(struct uart
{
struct sbd_port *sport = to_sport(uport);
struct sbd_duart *duart = sport->duart;
+ int map_guard;
iounmap(sport->memctrl);
sport->memctrl = NULL;
iounmap(uport->membase);
uport->membase = NULL;
- if(refcount_dec_and_test(&duart->map_guard))
+ map_guard = atomic_add_return(-1, &duart->map_guard);
+ if (!map_guard)
release_mem_region(duart->mapctrl, DUART_CHANREG_SPACING);
release_mem_region(uport->mapbase, DUART_CHANREG_SPACING);
}
@@ -704,6 +706,7 @@ static int sbd_request_port(struct uart_
{
const char *err = KERN_ERR "sbd: Unable to reserve MMIO resource\n";
struct sbd_duart *duart = to_sport(uport)->duart;
+ int map_guard;
int ret = 0;
if (!request_mem_region(uport->mapbase, DUART_CHANREG_SPACING,
@@ -711,11 +714,11 @@ static int sbd_request_port(struct uart_
printk(err);
return -EBUSY;
}
- refcount_inc(&duart->map_guard);
- if (refcount_read(&duart->map_guard) == 1) {
+ map_guard = atomic_add_return(1, &duart->map_guard);
+ if (map_guard == 1) {
if (!request_mem_region(duart->mapctrl, DUART_CHANREG_SPACING,
"sb1250-duart")) {
- refcount_dec(&duart->map_guard);
+ atomic_add(-1, &duart->map_guard);
printk(err);
ret = -EBUSY;
}
@@ -723,7 +726,8 @@ static int sbd_request_port(struct uart_
if (!ret) {
ret = sbd_map_port(uport);
if (ret) {
- if (refcount_dec_and_test(&duart->map_guard))
+ map_guard = atomic_add_return(-1, &duart->map_guard);
+ if (!map_guard)
release_mem_region(duart->mapctrl,
DUART_CHANREG_SPACING);
}
^ permalink raw reply
* [PATCH v1] serial: sh-sci: fix memory region release in error path
From: zenghongling @ 2026-04-13 4:08 UTC (permalink / raw)
To: gregkh, jirislaby, geert+renesas, biju.das.jz, wsa+renesas,
thierry.bultel.yh, prabhakar.mahadev-lad.rj
Cc: linux-kernel, linux-serial, zhongling0719, Hongling Zeng,
kernel test robot, Dan Carpenter
From: Hongling Zeng <zenghongling@kylinos.cn>
The sci_request_port() function uses request_mem_region() to reserve
I/O memory, but in the error path when sci_remap_port() fails, it
incorrectly calls release_resource() instead of release_mem_region().
This mismatch can cause resource accounting issues. Fix it by using
the correct release function, consistent with sci_release_port().
Fixes: 2667bd6673eb ("serial: 8250_port: simplify serial8250_request_std_resource()")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202604032356.SzEjYkBC-lkp@intel.com/
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
Change in v1:
- Fix the commit message and change name
---
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index bd7486315338..9e619db27237 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3024,7 +3024,7 @@ int sci_request_port(struct uart_port *port)
ret = sci_remap_port(port);
if (unlikely(ret != 0)) {
- release_resource(res);
+ release_mem_region(port->mapbase, sport->reg_size);
return ret;
}
--
2.25.1
^ permalink raw reply related
* [PATCH v1] serial: qcom-geni: Avoid probing debug console UART without console support
From: Aniket Randive @ 2026-04-13 7:25 UTC (permalink / raw)
To: gregkh, jirislaby, linux-arm-msm, linux-kernel, linux-serial,
praveen.talari, anup.kulkarni, dmitry.baryshkov, viken.dadhaniya
Cc: Aniket Randive
When CONFIG_SERIAL_QCOM_GENI_CONSOLE is disabled, the driver still
advertises the debug UART compatible strings ("qcom,geni-debug-uart"
and "qcom,sa8255p-geni-debug-uart") in its of_match table. This lets the
driver match and probe console UART DT nodes even though console
support is not built. As a result, the console port is never registered
with the UART core and uart_add_one_port() fails with -EINVAL.
Fix this by only including the debug UART compatible entries in the
match table when CONFIG_SERIAL_QCOM_GENI_CONSOLE is enabled, preventing
the driver from probing console UART nodes when console support is
absent.
Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
---
drivers/tty/serial/qcom_geni_serial.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 9854bb2406e3..b756e0c07c16 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -2039,6 +2039,7 @@ static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
};
static const struct of_device_id qcom_geni_serial_match_table[] = {
+#if IS_ENABLED(CONFIG_SERIAL_QCOM_GENI_CONSOLE)
{
.compatible = "qcom,geni-debug-uart",
.data = &qcom_geni_console_data,
@@ -2047,6 +2048,7 @@ static const struct of_device_id qcom_geni_serial_match_table[] = {
.compatible = "qcom,sa8255p-geni-debug-uart",
.data = &sa8255p_qcom_geni_console_data,
},
+#endif
{
.compatible = "qcom,geni-uart",
.data = &qcom_geni_uart_data,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-13 7:54 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com>
Hi,
On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> Hi,
>
> This series is the continuation of the series [1] that added the initial support
> for the PCIe M.2 connectors. This series extends it by adding support for Key E
> connectors. These connectors are used to connect the Wireless Connectivity
> devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> interfaces are left for future improvements.
Thanks for working on this. I started playing with it now that it is in
-next. The PCIe part works fine. I'm looking into how to fit the pwrseq
A couple questions:
- Given that this connector actually represents two devices, how do I
say I want the BT part to be a wakeup source, but not the WiFi part?
Does wakeup-source even work at this point?
- Are there plans to do the SDIO part?
- The matching done in the M.2 connector driver for pwrseq_get() seems a
bit naive. It simply checks if the remote device in the OF graph is
the same as the requesting device.
I think this would run into issues with USB hubs. If I have a USB hub
and two M.2 connectors, with both connectors connected to the same
hub, pwrseq_get() is going to always return only one of the instances.
This is because the USB hub has one device node with multiple OF graph
ports.
Thanks
ChenYu
> Serdev device support for BT
> ============================
>
> Adding support for the PCIe interface was mostly straightforward and a lot
> similar to the previous Key M connector. But adding UART interface has proved to
> be tricky. This is mostly because of the fact UART is a non-discoverable bus,
> unlike PCIe which is discoverable. So this series relied on the PCI notifier to
> create the serdev device for UART/BT. This means the PCIe interface will be
> brought up first and after the PCIe device enumeration, the serdev device will
> be created by the pwrseq driver. This logic is necessary since the connector
> driver and DT node don't describe the device, but just the connector. So to make
> the connector interface Plug and Play, the connector driver uses the PCIe device
> ID to identify the card and creates the serdev device. This logic could be
> extended in the future to support more M.2 cards. Even if the M.2 card uses SDIO
> interface for connecting WLAN, a SDIO notifier could be added to create the
> serdev device.
>
> Testing
> =======
>
> This series, together with the devicetree changes [2] was tested on the
> Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> 1620 LGA card connected over PCIe and UART.
>
> Merge Strategy
> ==============
>
> Due to the API dependency, both the serdev and pwrseq patches need to go through
> a single tree, maybe through pwrseq tree. So the serdev patches need Ack from
> Greg. But Bluetooth patch can be merged separately.
>
> NOTE
> ====
>
> This series is based on bluetooth-next/master to resolve the conflict with the
> Bluetooth patch. Other pathces should apply cleanly on top of v7.0-rc1.
>
> [1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
> [2] https://github.com/Mani-Sadhasivam/linux/commit/b50f8386900990eed3dce8d91c3b643fb0e8739d
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> Changes in v7:
> - Dropped the LGA binding change due to vendor prefix concern. This will be
> submitted later once I get clarity.
> - Fixed several issues in the cleanup path of the pwrseq-pci-m2 driver which
> includes adding the .remove() callback.
> - Rebased on top of bluetooth-next/master to resolve conflict with bluetooth
> patch.
> - Link to v6: https://lore.kernel.org/r/20260317-pci-m2-e-v6-0-9c898f108d3d@oss.qualcomm.com
>
> Changes in v6:
> - Added a check to bail out if the serdev device was already added during notifier.
> - Collected tags
> - Link to v5: https://lore.kernel.org/r/20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com
>
> Changes in v5:
> - Incorporated comments in the binding patch by using single endpoint per port,
> reordering port nodes, adding missing properties and using a complete example.
> - Incorporated comments in the pwrseq patch (nothing major)
> - Fixed the build issue in patch 2
> - Collected tags
> - Rebased on top of 7.0-rc1
> - Link to v4: https://lore.kernel.org/r/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com
>
> Changes in v4:
> - Switched to dynamic OF node for serdev instead of swnode and dropped all
> swnode related patches
> - Link to v3: https://lore.kernel.org/r/20260110-pci-m2-e-v3-0-4faee7d0d5ae@oss.qualcomm.com
>
> Changes in v3:
> - Switched to swnode for the serdev device and dropped the custom
> serdev_device_id related patches
> - Added new swnode APIs to match the swnode with existing of_device_id
> - Incorporated comments in the bindings patch
> - Dropped the UIM interface from binding since it is not clear how it should get
> wired
> - Incorporated comments in the pwrseq driver patch
> - Splitted the pwrseq patch into two
> - Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
> - Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com
>
> Changes in v2:
> - Used '-' for GPIO names in the binding and removed led*-gpios properties
> - Described the endpoint nodes for port@0 and port@1 nodes
> - Added the OF graph port to the serial binding
> - Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
> - Incorporated various review comments in pwrseq driver
> - Collected Ack
> - Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com
>
> ---
> Manivannan Sadhasivam (8):
> serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
> serdev: Add an API to find the serdev controller associated with the devicetree node
> serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
> dt-bindings: serial: Document the graph port
> dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
> Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
> power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
> power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
>
> .../bindings/connector/pcie-m2-e-connector.yaml | 184 +++++++++++
> .../devicetree/bindings/serial/serial.yaml | 3 +
> MAINTAINERS | 1 +
> drivers/bluetooth/hci_qca.c | 9 +
> drivers/power/sequencing/Kconfig | 3 +-
> drivers/power/sequencing/pwrseq-pcie-m2.c | 346 ++++++++++++++++++++-
> drivers/tty/serdev/core.c | 28 +-
> include/linux/serdev.h | 24 +-
> 8 files changed, 570 insertions(+), 28 deletions(-)
> ---
> base-commit: 559f264e403e4d58d56a17595c60a1de011c5e20
> change-id: 20251112-pci-m2-e-94695ac9d657
>
> Best regards,
> --
> Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] serial: sh-sci: Avoid divide-by-zero fault
From: Geert Uytterhoeven @ 2026-04-13 10:24 UTC (permalink / raw)
To: Biju Das
Cc: Hugo Villeneuve, biju.das.au, Greg Kroah-Hartman, Jiri Slaby,
Thierry Bultel, wsa+renesas, Prabhakar Mahadev Lad,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB11332859E901171C91C543061865B2@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Hi Biju,
On Wed, 8 Apr 2026 at 19:25, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > On Wed, 8 Apr 2026 16:35:44 +0000
> > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > Biju <biju.das.au@gmail.com> wrote:
> > > > > From: Biju Das <biju.das.jz@bp.renesas.com>
> > > > >
> > > > > uart_update_timeout() computes a timeout value by dividing by the
> > > > > baud rate. If baud is zero — which can occur when the hardware
> > > > > returns an unsupported or invalid rate — this results in a divide-by-zero fault.
> > > >
> > > > baud is returned by uart_get_baud_rate(), so this is not returned by the hardware?
> > >
> > > You are tight, Will update commit description.
> >
> > How can uart_get_baud_rate() return a zero value? If I am not mistaken even for the B0 case, it will
> > return 9600?
>
> As per the comment and code, this API can return 0.
>
> * If the new baud rate is invalid, try the @old termios setting. If it's still
> * invalid, we try 9600 baud. If that is also invalid 0 is returned.
>
> In drives/tty currently only 1 driver is checking the return value
> and it calls panic
>
> https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/tty/serial/apbuart.c#L214
>
>
> I believe we should call panic, if baud =0, instead of proceeding.
>
> Geert, any thoughts??
IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
system, where the serial console should just keep on using the settings
programmed by the firmware. So any config register writes should
be skipped.
On DT systems, even earlycon uses the bitrate from chosen/stdout-path.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [syzbot] [serial?] KCSAN: data-race in serial8250_do_startup / serial8250_modem_status (4)
From: syzbot @ 2026-04-13 12:59 UTC (permalink / raw)
To: gregkh, jirislaby, linux-kernel, linux-serial, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 7c6c4ed80b87 Merge tag 'vfs-7.0-rc8.fixes' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11711106580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3a78dd265deac3a9
dashboard link: https://syzkaller.appspot.com/bug?extid=a12081a388b863499373
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/952ebc34a0d7/disk-7c6c4ed8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d3c6b295fa45/vmlinux-7c6c4ed8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/6cbdb6b4817a/bzImage-7c6c4ed8.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a12081a388b863499373@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in serial8250_do_startup / serial8250_modem_status
write to 0xffffffff893ff4c6 of 1 bytes by task 7024 on cpu 1:
serial8250_do_startup+0x1628/0x1d50 drivers/tty/serial/8250/8250_port.c:2334
serial8250_startup+0x41/0x50 drivers/tty/serial/8250/8250_port.c:2354
uart_port_startup drivers/tty/serial/serial_core.c:321 [inline]
uart_startup+0x464/0xae0 drivers/tty/serial/serial_core.c:365
uart_port_activate+0x67/0xc0 drivers/tty/serial/serial_core.c:1949
tty_port_open+0x196/0x270 drivers/tty/tty_port.c:747
uart_open+0x30/0x40 drivers/tty/serial/serial_core.c:1929
tty_open+0x3d4/0xaf0 drivers/tty/tty_io.c:2137
chrdev_open+0x2eb/0x3a0 fs/char_dev.c:411
do_dentry_open+0x4ca/0xa90 fs/open.c:949
vfs_open+0x37/0x1e0 fs/open.c:1081
do_open fs/namei.c:4677 [inline]
path_openat+0x1b70/0x2050 fs/namei.c:4836
do_file_open+0x16c/0x290 fs/namei.c:4865
do_sys_openat2+0x94/0x130 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0xf2/0x120 fs/open.c:1383
x64_sys_call+0x1e39/0x3020 arch/x86/include/generated/asm/syscalls_64.h:258
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffffffff893ff4c6 of 1 bytes by interrupt on cpu 0:
serial8250_modem_status+0x6a/0x1e0 drivers/tty/serial/8250/8250_port.c:1742
serial8250_handle_irq_locked+0x331/0x420 drivers/tty/serial/8250/8250_port.c:1822
serial8250_handle_irq+0xad/0x280 drivers/tty/serial/8250/8250_port.c:1841
serial8250_default_handle_irq+0x8e/0x170 drivers/tty/serial/8250/8250_port.c:1855
serial8250_interrupt+0x63/0x130 drivers/tty/serial/8250/8250_core.c:86
__handle_irq_event_percpu+0x9c/0x4d0 kernel/irq/handle.c:209
handle_irq_event_percpu kernel/irq/handle.c:246 [inline]
handle_irq_event+0x64/0xf0 kernel/irq/handle.c:263
handle_edge_irq+0x154/0x470 kernel/irq/chip.c:855
generic_handle_irq_desc include/linux/irqdesc.h:186 [inline]
handle_irq arch/x86/kernel/irq.c:262 [inline]
call_irq_handler arch/x86/kernel/irq.c:-1 [inline]
__common_interrupt+0x60/0xb0 arch/x86/kernel/irq.c:333
common_interrupt+0x7e/0x90 arch/x86/kernel/irq.c:326
asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:688
__skb_datagram_iter+0x194/0x680 net/core/datagram.c:415
skb_copy_datagram_iter+0x3f/0x120 net/core/datagram.c:535
skb_copy_datagram_msg include/linux/skbuff.h:4218 [inline]
__unix_dgram_recvmsg+0x4b0/0x870 net/unix/af_unix.c:2615
unix_dgram_recvmsg+0x81/0x90 net/unix/af_unix.c:2672
sock_recvmsg_nosec+0xc2/0xf0 net/socket.c:1078
____sys_recvmsg+0x26f/0x280 net/socket.c:2810
___sys_recvmsg+0x11f/0x3b0 net/socket.c:2854
do_recvmmsg+0x1ef/0x560 net/socket.c:2949
__sys_recvmmsg net/socket.c:3023 [inline]
__do_sys_recvmmsg net/socket.c:3046 [inline]
__se_sys_recvmmsg net/socket.c:3039 [inline]
__x64_sys_recvmmsg+0xe5/0x170 net/socket.c:3039
x64_sys_call+0x80f/0x3020 arch/x86/include/generated/asm/syscalls_64.h:300
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00 -> 0x05
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 6993 Comm: syz.3.814 Tainted: G W syzkaller #0 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
==================================================================
EXT4-fs (loop7): error count since last fsck: 1
EXT4-fs (loop7): initial error at time 1775890841: ext4_free_branches:1023: inode 11
EXT4-fs (loop7): last error at time 1775890841: ext4_free_branches:1023: inode 11
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam @ 2026-04-13 14:02 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Manivannan Sadhasivam, Krzysztof Kozlowski,
Conor Dooley, Marcel Holtmann, Luiz Augusto von Dentz,
Bartosz Golaszewski, Andy Shevchenko, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <20260413075459.GA2626902@google.com>
On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > Hi,
> >
> > This series is the continuation of the series [1] that added the initial support
> > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > connectors. These connectors are used to connect the Wireless Connectivity
> > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > interfaces are left for future improvements.
>
> Thanks for working on this. I started playing with it now that it is in
> -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
>
> A couple questions:
>
> - Given that this connector actually represents two devices, how do I
> say I want the BT part to be a wakeup source, but not the WiFi part?
> Does wakeup-source even work at this point?
>
You can't use the DT property since the devices are not described in DT
statically. But you can still use the per-device 'wakeup' sysfs knob to enable
wakeup.
> - Are there plans to do the SDIO part?
>
No, not at the moment. Feel free to take it up if you have the hardware and
motivation :)
> - The matching done in the M.2 connector driver for pwrseq_get() seems a
> bit naive. It simply checks if the remote device in the OF graph is
> the same as the requesting device.
>
> I think this would run into issues with USB hubs. If I have a USB hub
> and two M.2 connectors, with both connectors connected to the same
> hub, pwrseq_get() is going to always return only one of the instances.
> This is because the USB hub has one device node with multiple OF graph
> ports.
>
Yeah, this is a known limitation. I'm trying to improve this part now and have
the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
Once the merge window closes, I'll submit these.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam @ 2026-04-13 16:08 UTC (permalink / raw)
To: Chen-Yu Tsai, Manivannan Sadhasivam
Cc: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Andy Shevchenko, Bartosz Golaszewski, linux-serial, linux-kernel,
linux-kbuild, platform-driver-x86, linux-pci, devicetree,
linux-arm-msm, linux-bluetooth, linux-pm, Stephan Gerhold,
Dmitry Baryshkov, linux-acpi, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <fpcs4p62f35a5qyqwgm5ysa73stbysxcr62tkmmkrrcvsuf4t4@4ivukyqjey57>
[Resending as my previous reply got bounced]
On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > > Hi,
> > >
> > > This series is the continuation of the series [1] that added the initial support
> > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > connectors. These connectors are used to connect the Wireless Connectivity
> > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > interfaces are left for future improvements.
> >
> > Thanks for working on this. I started playing with it now that it is in
> > -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
> >
> > A couple questions:
> >
> > - Given that this connector actually represents two devices, how do I
> > say I want the BT part to be a wakeup source, but not the WiFi part?
> > Does wakeup-source even work at this point?
> >
>
> You can't use the DT property since the devices are not described in DT
> statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> wakeup.
>
> > - Are there plans to do the SDIO part?
> >
>
> No, not at the moment. Feel free to take it up if you have the hardware and
> motivation :)
>
> > - The matching done in the M.2 connector driver for pwrseq_get() seems a
> > bit naive. It simply checks if the remote device in the OF graph is
> > the same as the requesting device.
> >
> > I think this would run into issues with USB hubs. If I have a USB hub
> > and two M.2 connectors, with both connectors connected to the same
> > hub, pwrseq_get() is going to always return only one of the instances.
> > This is because the USB hub has one device node with multiple OF graph
> > ports.
> >
>
> Yeah, this is a known limitation. I'm trying to improve this part now and have
> the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
>
> Once the merge window closes, I'll submit these.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-14 5:03 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Andy Shevchenko,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <eeytuhqpgdz4do4tgtbmfntub2femtyq7bij7svhodpyjwaylx@j3gmvq2a2zqc>
On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> [Resending as my previous reply got bounced]
>
> On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
> > > > Hi,
> > > >
> > > > This series is the continuation of the series [1] that added the initial support
> > > > for the PCIe M.2 connectors. This series extends it by adding support for Key E
> > > > connectors. These connectors are used to connect the Wireless Connectivity
> > > > devices such as WiFi, BT, NFC and GNSS devices to the host machine over
> > > > interfaces such as PCIe/SDIO, USB/UART and NFC. This series adds support for
> > > > connectors that expose PCIe interface for WiFi and UART interface for BT. Other
> > > > interfaces are left for future improvements.
> > >
> > > Thanks for working on this. I started playing with it now that it is in
> > > -next. The PCIe part works fine. I'm looking into how to fit the pwrseq
> > >
> > > A couple questions:
> > >
> > > - Given that this connector actually represents two devices, how do I
> > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > Does wakeup-source even work at this point?
> > >
> >
> > You can't use the DT property since the devices are not described in DT
> > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > wakeup.
I see. I think not being able to specify generic properties for the devices
on the connector is going to be a bit problematic. Another use case I have
requires specifying a bounce buffer / SWIOTLB for the PCIe WiFi card. The
PCIe controller does not have an IOMMU behind it.
> > > - Are there plans to do the SDIO part?
> > >
> >
> > No, not at the moment. Feel free to take it up if you have the hardware and
> > motivation :)
Ack. I think I still need to figure out what the plan is after mmc-pwrseq
is deprecated.
> > > - The matching done in the M.2 connector driver for pwrseq_get() seems a
> > > bit naive. It simply checks if the remote device in the OF graph is
> > > the same as the requesting device.
> > >
> > > I think this would run into issues with USB hubs. If I have a USB hub
> > > and two M.2 connectors, with both connectors connected to the same
> > > hub, pwrseq_get() is going to always return only one of the instances.
> > > This is because the USB hub has one device node with multiple OF graph
> > > ports.
> > >
> >
> > Yeah, this is a known limitation. I'm trying to improve this part now and have
> > the WIP commits here: https://github.com/Mani-Sadhasivam/linux/tree/pwrseq-bt-en-fixes
> >
> > Once the merge window closes, I'll submit these.
I couldn't tell which commit would help with this.
In my head I think we would need to extend pwrseq_get() to add something
like an index parameter that the provider is free to interpret. The M.2
connector driver could interpret it as the USB port number on the remote
end.
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-04-14 8:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <CAGXv+5E=tujhtZjwi6Qm7hk3Ks74UzTQHWq82NiTEw1+vYod5g@mail.gmail.com>
On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
...
> > > > - Given that this connector actually represents two devices, how do I
> > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > Does wakeup-source even work at this point?
> > >
> > > You can't use the DT property since the devices are not described in DT
> > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > wakeup.
>
> I see. I think not being able to specify generic properties for the devices
> on the connector is going to be a bit problematic.
This is nature of the open-connectors, especially on the busses that are
hotpluggable, like PCIe. We never know what is connected there _ahead_.
In other words you can't describe in DT something that may not exist.
> requires specifying a bounce buffer / SWIOTLB for the PCIe WiFi card. The
> PCIe controller does not have an IOMMU behind it.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-14 10:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <ad36pIu-0dutL7Nk@ashevche-desk.local>
On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
>
> ...
>
> > > > > - Given that this connector actually represents two devices, how do I
> > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > Does wakeup-source even work at this point?
> > > >
> > > > You can't use the DT property since the devices are not described in DT
> > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > wakeup.
> >
> > I see. I think not being able to specify generic properties for the devices
> > on the connector is going to be a bit problematic.
>
> This is nature of the open-connectors, especially on the busses that are
> hotpluggable, like PCIe. We never know what is connected there _ahead_.
I believe what you mean by "hotpluggable" is "user replaceable".
> In other words you can't describe in DT something that may not exist.
But this is actually doable with the PCIe slot representation. The
properties are put in the device node for the slot. If no card is
actually inserted in the slot, then no device is created, and the
device node is left as not associated with anything.
It's just that for this new M.2 E-key connector, there aren't separate
nodes for each interface. And the system doesn't associate the device
node with the device, because it's no longer a child node of the
controller or hierarchy, but connected over the OF graph.
Moving over to the E-key connector representation seems like one step
forward and one step backward in descriptive ability. We gain proper
power sequencing, but lose generic properties.
The latter part is solvable, but we likely need child nodes under the
connector for the different interfaces. Properties that make sense for
one type might not make sense for another.
Thanks
ChenYu
P.S. We could also just add child device nodes under the controller to
put the generic properties, but that's splitting the description into
multiple parts. Let's not go there if at all possible.
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-04-14 12:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <CAGXv+5EGe59nJctLweEdZjb3MNmMvjuCHngGSfptzN985OiLdg@mail.gmail.com>
On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
...
> > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > Does wakeup-source even work at this point?
> > > > >
> > > > > You can't use the DT property since the devices are not described in DT
> > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > wakeup.
> > >
> > > I see. I think not being able to specify generic properties for the devices
> > > on the connector is going to be a bit problematic.
> >
> > This is nature of the open-connectors, especially on the busses that are
> > hotpluggable, like PCIe. We never know what is connected there _ahead_.
>
> I believe what you mean by "hotpluggable" is "user replaceable".
From the OS perspective it's the same. From platform perspective
there is a difference, granted.
> > In other words you can't describe in DT something that may not exist.
>
> But this is actually doable with the PCIe slot representation. The
> properties are put in the device node for the slot. If no card is
> actually inserted in the slot, then no device is created, and the
> device node is left as not associated with anything.
But you need to list all devices in the world if you want to support this
somehow. Yes, probably many of them (or majority) will be enumerated as is,
but some may need an assistance via (dynamic) properties or similar mechanisms.
> It's just that for this new M.2 E-key connector, there aren't separate
> nodes for each interface. And the system doesn't associate the device
> node with the device, because it's no longer a child node of the
> controller or hierarchy, but connected over the OF graph.
>
> Moving over to the E-key connector representation seems like one step
> forward and one step backward in descriptive ability. We gain proper
> power sequencing, but lose generic properties.
The "key" is property of the connector. Hence if you have an idea what can be
common for ALL "key":s, that's probably can be abstracted. Note, I'm not
familiar with the connector framework in the Linux kernel, perhaps it's already
that kind of abstraction.
> The latter part is solvable, but we likely need child nodes under the
> connector for the different interfaces. Properties that make sense for
> one type might not make sense for another.
>
> P.S. We could also just add child device nodes under the controller to
> put the generic properties, but that's splitting the description into
> multiple parts. Let's not go there if at all possible.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] tty: serial: pch_uart: add check for dma_alloc_coherent()
From: Andy Shevchenko @ 2026-04-14 17:13 UTC (permalink / raw)
To: Zhaoyang Yu
Cc: gregkh, jirislaby, kees, fourier.thomas, linux-serial,
linux-kernel, gszhai, 23120469, stable
In-Reply-To: <tencent_E328416B7CFD436F6029F2DF02AD7ED89C08@qq.com>
On Thu, Apr 09, 2026 at 01:41:58PM +0800, Zhaoyang Yu wrote:
> Add a check for dma_alloc_coherent() failure to prevent a potential
> NULL pointer dereference in dma_handle_rx(). Properly release DMA
> channels and the PCI device reference using a goto ladder if the
> allocation fails.
As a fix for backporting it's good enough, ideally should be converted to one
from 8250 family as it was done, for example, for Intel MID (see a history of
8250_mid.c for the details).
FWIW, the HW one may test this on is Intel Minnowboard v1 which uses EG20T PCH.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC] tty: n_gsm: fix use-after-free in gsmtty_install
From: Kito Xu (veritas501) @ 2026-04-15 2:48 UTC (permalink / raw)
To: gregkh, jirislaby; +Cc: linux-serial, linux-kernel, Kito Xu (veritas501)
gsmtty_install() reads gsm_mux[] without holding gsm_mux_lock and
defers mux_get() about 40 lines later. A concurrent gsmld_close() can
free the mux through gsm_cleanup_mux() -> mux_put() -> kfree(gsm) in
that window, leading to a use-after-free when gsmtty_install() later
dereferences the stale pointer.
race condition:
cpu 0 | cpu 1
gsmtty_install() | gsmld_close()
gsm = gsm_mux[mux] // no lock |
// CFS preempts here | gsm_cleanup_mux(gsm)
| gsm->dead = true
| mux_put(gsm)
| -> kfree(gsm)
gsm->dead // UAF! |
mutex_lock(&gsm->mutex) // UAF! |
Acquire gsm_mux_lock before reading gsm_mux[] and take the refcount
via kref_get() while still holding the lock, so the mux cannot be
freed between lookup and refcount increment.
Fixes: 86176ed90545 ("TTY: n_gsm, use tty_port_install")
Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
---
drivers/tty/n_gsm.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b..6519f1c92fc5 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -4288,14 +4288,20 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (mux >= MAX_MUX)
return -ENXIO;
- /* FIXME: we need to lock gsm_mux for lifetimes of ttys eventually */
- if (gsm_mux[mux] == NULL)
- return -EUNATCH;
if (line == 0 || line > 61) /* 62/63 reserved */
return -ECHRNG;
+
+ /* Acquire gsm_mux_lock to prevent concurrent gsmld_close() from
+ * freeing the mux between reading gsm_mux[] and taking a refcount.
+ */
+ spin_lock(&gsm_mux_lock);
gsm = gsm_mux[mux];
- if (gsm->dead)
- return -EL2HLT;
+ if (!gsm || gsm->dead) {
+ spin_unlock(&gsm_mux_lock);
+ return gsm ? -EL2HLT : -EUNATCH;
+ }
+ kref_get(&gsm->ref);
+ spin_unlock(&gsm_mux_lock);
/* If DLCI 0 is not yet fully open return an error.
This is ok from a locking
perspective as we don't have to worry about this
@@ -4309,8 +4315,10 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (dlci0->state == DLCI_OPENING)
wait_event(gsm->event, dlci0->state != DLCI_OPENING);
- if (dlci0->state != DLCI_OPEN)
+ if (dlci0->state != DLCI_OPEN) {
+ mux_put(gsm);
return -EL2NSYNC;
+ }
mutex_lock(&gsm->mutex);
}
@@ -4322,6 +4330,7 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
}
if (dlci == NULL) {
mutex_unlock(&gsm->mutex);
+ mux_put(gsm);
return -ENOMEM;
}
ret = tty_port_install(&dlci->port, driver, tty);
@@ -4329,12 +4338,12 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (alloc)
dlci_put(dlci);
mutex_unlock(&gsm->mutex);
+ mux_put(gsm);
return ret;
}
dlci_get(dlci);
dlci_get(gsm->dlci[0]);
- mux_get(gsm);
tty->driver_data = dlci;
mutex_unlock(&gsm->mutex);
--
2.43.0
^ permalink raw reply related
* [PATCH] tty: n_gsm: fix use-after-free in gsmtty_install
From: Kito Xu (veritas501) @ 2026-04-15 3:17 UTC (permalink / raw)
To: gregkh, jirislaby; +Cc: linux-serial, linux-kernel, Kito Xu (veritas501)
In-Reply-To: <20260415024846.2918702-1-hxzene@gmail.com>
gsmtty_install() reads gsm_mux[] without holding gsm_mux_lock and
defers mux_get() about 40 lines later. A concurrent gsmld_close() can
free the mux through gsm_cleanup_mux() -> mux_put() -> kfree(gsm) in
that window, leading to a use-after-free when gsmtty_install() later
dereferences the stale pointer.
race condition:
cpu 0 | cpu 1
gsmtty_install() | gsmld_close()
gsm = gsm_mux[mux] // no lock |
// CFS preempts here | gsm_cleanup_mux(gsm)
| gsm->dead = true
| mux_put(gsm)
| -> kfree(gsm)
gsm->dead // UAF! |
mutex_lock(&gsm->mutex) // UAF! |
KASAN report:
BUG: KASAN: slab-use-after-free in gsmtty_install+0x6cf/0x830
Read of size 1 at addr ffff88800fd440ac by task poc/170
CPU: 0 UID: 0 PID: 170 Comm: poc Not tainted 7.0.0-rc7-next-20260410+ #20
Call Trace:
<TASK>
dump_stack_lvl+0x64/0x80
print_report+0xd0/0x5e0
kasan_report+0xce/0x100
gsmtty_install+0x6cf/0x830
tty_init_dev.part.0+0x92/0x4a0
tty_open+0x8ab/0x1050
chrdev_open+0x1ec/0x5e0
do_dentry_open+0x419/0x1260
vfs_open+0x79/0x350
path_openat+0x212c/0x3a70
do_file_open+0x1d2/0x400
do_sys_openat2+0xdc/0x170
__x64_sys_openat+0x122/0x1e0
do_syscall_64+0x64/0x680
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Allocated by task 169 on cpu 0 at 3.824684s:
Freed by task 169 on cpu 0 at 3.892012s:
The buggy address belongs to the object at ffff88800fd44000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 172 bytes inside of
freed 1024-byte region [ffff88800fd44000, ffff88800fd44400)
Acquire gsm_mux_lock before reading gsm_mux[] and take the refcount
via kref_get() while still holding the lock, so the mux cannot be
freed between lookup and refcount increment.
Fixes: 86176ed90545 ("TTY: n_gsm, use tty_port_install")
Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
---
drivers/tty/n_gsm.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b..6519f1c92fc5 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -4288,14 +4288,20 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (mux >= MAX_MUX)
return -ENXIO;
- /* FIXME: we need to lock gsm_mux for lifetimes of ttys eventually */
- if (gsm_mux[mux] == NULL)
- return -EUNATCH;
if (line == 0 || line > 61) /* 62/63 reserved */
return -ECHRNG;
+
+ /* Acquire gsm_mux_lock to prevent concurrent gsmld_close() from
+ * freeing the mux between reading gsm_mux[] and taking a refcount.
+ */
+ spin_lock(&gsm_mux_lock);
gsm = gsm_mux[mux];
- if (gsm->dead)
- return -EL2HLT;
+ if (!gsm || gsm->dead) {
+ spin_unlock(&gsm_mux_lock);
+ return gsm ? -EL2HLT : -EUNATCH;
+ }
+ kref_get(&gsm->ref);
+ spin_unlock(&gsm_mux_lock);
/* If DLCI 0 is not yet fully open return an error.
This is ok from a locking
perspective as we don't have to worry about this
@@ -4309,8 +4315,10 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (dlci0->state == DLCI_OPENING)
wait_event(gsm->event, dlci0->state != DLCI_OPENING);
- if (dlci0->state != DLCI_OPEN)
+ if (dlci0->state != DLCI_OPEN) {
+ mux_put(gsm);
return -EL2NSYNC;
+ }
mutex_lock(&gsm->mutex);
}
@@ -4322,6 +4330,7 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
}
if (dlci == NULL) {
mutex_unlock(&gsm->mutex);
+ mux_put(gsm);
return -ENOMEM;
}
ret = tty_port_install(&dlci->port, driver, tty);
@@ -4329,12 +4338,12 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
if (alloc)
dlci_put(dlci);
mutex_unlock(&gsm->mutex);
+ mux_put(gsm);
return ret;
}
dlci_get(dlci);
dlci_get(gsm->dlci[0]);
- mux_get(gsm);
tty->driver_data = dlci;
mutex_unlock(&gsm->mutex);
--
2.43.0
^ permalink raw reply related
* [PATCH] serial: base: do not disable TX on hangup for console ports
From: kpursoty @ 2026-04-15 8:01 UTC (permalink / raw)
To: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
jirislaby@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
tsbogend@alpha.franken.de
serial_base_port_shutdown() calls serial_base_port_set_tx(false)
unconditionally. When a TTY hangup occurs on a port that is also a
registered kernel console, this permanently disables the console
transmitter.
uart_hangup() already guards against uart_change_pm(PM_OFF) for console
ports (see the uart_console() check in uart_hangup()). Apply the same
guard in serial_base_port_shutdown(): skip TX-disable if the port is a
registered console.
Without this fix, any path that calls uart_shutdown() on a console port
- including TIOCSCTTY with force=1 (as used by init systems such as
procd) - permanently silences all subsequent kernel console output.
Signed-off-by: Kervin Pursoty <kpursoty@proton.me>
---
drivers/tty/serial/serial_port.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_port.c b/drivers/tty/serial/serial_port.c
--- a/drivers/tty/serial/serial_port.c
+++ b/drivers/tty/serial/serial_port.c
@@ -110,5 +110,14 @@
{
struct serial_port_device *port_dev = port->port_dev;
- serial_base_port_set_tx(port, port_dev, false);
+ /*
+ * Do not disable TX on a console port. When an init system calls
+ * TIOCSCTTY with force=1, the kernel hangs up the previous session,
+ * triggering uart_hangup() -> uart_shutdown() -> here. Stopping TX
+ * kills all kernel console output permanently.
+ * uart_hangup() already skips uart_change_pm(PM_OFF) for consoles
+ * via uart_console(); apply the same guard here.
+ */
+ if (!uart_console(port))
+ serial_base_port_set_tx(port, port_dev, false);
}
static DEFINE_RUNTIME_DEV_PM_OPS(serial_port_pm,
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-15 8:31 UTC (permalink / raw)
To: Andy Shevchenko, Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <ad4tJN27opdEooA7@ashevche-desk.local>
On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
>
> ...
>
> > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > Does wakeup-source even work at this point?
> > > > > >
> > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > wakeup.
> > > >
> > > > I see. I think not being able to specify generic properties for the devices
> > > > on the connector is going to be a bit problematic.
> > >
> > > This is nature of the open-connectors, especially on the busses that are
> > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> >
> > I believe what you mean by "hotpluggable" is "user replaceable".
>
> From the OS perspective it's the same. From platform perspective
> there is a difference, granted.
Yes. I just wanted to clarify.
> > > In other words you can't describe in DT something that may not exist.
> >
> > But this is actually doable with the PCIe slot representation. The
> > properties are put in the device node for the slot. If no card is
> > actually inserted in the slot, then no device is created, and the
> > device node is left as not associated with anything.
>
> But you need to list all devices in the world if you want to support this
Why would I need to? The PCIe slot representation just describes a
PCIe bridge. Granted this might not be entirely correct, but it's
what we currently have.
And even then, there are properties like memory-region or wakeup-source
that are generic and aren't tied to specific devices.
> somehow. Yes, probably many of them (or majority) will be enumerated as is,
> but some may need an assistance via (dynamic) properties or similar mechanisms.
Even if we wanted to add dynamic properties, there is currently no proper
device node to attach them to.
> > It's just that for this new M.2 E-key connector, there aren't separate
> > nodes for each interface. And the system doesn't associate the device
> > node with the device, because it's no longer a child node of the
> > controller or hierarchy, but connected over the OF graph.
> >
> > Moving over to the E-key connector representation seems like one step
> > forward and one step backward in descriptive ability. We gain proper
> > power sequencing, but lose generic properties.
>
> The "key" is property of the connector. Hence if you have an idea what can be
> common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> familiar with the connector framework in the Linux kernel, perhaps it's already
> that kind of abstraction.
I'm not arguing for a even more generic "M.2" connector. The "key" is
already described in the compatible. I'm saying we should have some way
of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
on the connector so further nodes or properties can be attached to them,
either with overlays or dynamically within the kernel. Right now the
are only described as individual ports, but we can't actually tie a
device to a OF graph port.
But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
UART-based BT bit part, Mani just had the driver create a device node
under the UART (by traversing the OF graph to find the UART). If that's
the desired way then the connector binding should mention it. And that
works for me. But I think it's messier and also we're missing an
opportunity to make the M.2 connector a standardized attachment point
for overlays.
Mani, could you also chime in a bit on what you envisioned?
(Added Luca from Bootlin to CC, as I think there are parallels to the
"Hotplug of Non-discoverable Hardware" work)
Thanks
ChenYu
> > The latter part is solvable, but we likely need child nodes under the
> > connector for the different interfaces. Properties that make sense for
> > one type might not make sense for another.
> >
> > P.S. We could also just add child device nodes under the controller to
> > put the generic properties, but that's splitting the description into
> > multiple parts. Let's not go there if at all possible.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-04-15 9:07 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
On Wed, Apr 15, 2026 at 04:31:24PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
...
> > > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > > Does wakeup-source even work at this point?
> > > > > > >
> > > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > > wakeup.
> > > > >
> > > > > I see. I think not being able to specify generic properties for the devices
> > > > > on the connector is going to be a bit problematic.
> > > >
> > > > This is nature of the open-connectors, especially on the busses that are
> > > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> > >
> > > I believe what you mean by "hotpluggable" is "user replaceable".
> >
> > From the OS perspective it's the same. From platform perspective
> > there is a difference, granted.
>
> Yes. I just wanted to clarify.
>
> > > > In other words you can't describe in DT something that may not exist.
> > >
> > > But this is actually doable with the PCIe slot representation. The
> > > properties are put in the device node for the slot. If no card is
> > > actually inserted in the slot, then no device is created, and the
> > > device node is left as not associated with anything.
> >
> > But you need to list all devices in the world if you want to support this
>
> Why would I need to? The PCIe slot representation just describes a
> PCIe bridge. Granted this might not be entirely correct, but it's
> what we currently have.
>
> And even then, there are properties like memory-region or wakeup-source
> that are generic and aren't tied to specific devices.
Yes, see below what I replied...
> > somehow. Yes, probably many of them (or majority) will be enumerated as is,
^^^ "the majority" will work without any assistance.
> > but some may need an assistance via (dynamic) properties or similar mechanisms.
> Even if we wanted to add dynamic properties, there is currently no proper
> device node to attach them to.
Isn't that's node created dynamically as well and attached to the PCI bus?
> > > It's just that for this new M.2 E-key connector, there aren't separate
> > > nodes for each interface. And the system doesn't associate the device
> > > node with the device, because it's no longer a child node of the
> > > controller or hierarchy, but connected over the OF graph.
> > >
> > > Moving over to the E-key connector representation seems like one step
> > > forward and one step backward in descriptive ability. We gain proper
> > > power sequencing, but lose generic properties.
> >
> > The "key" is property of the connector. Hence if you have an idea what can be
> > common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> > familiar with the connector framework in the Linux kernel, perhaps it's already
> > that kind of abstraction.
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
Shouldn't it be described as a DT subtree? Sorry, I am not familiar with DT
enough to understand the issue you have.
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
Okay, now it might get clearer to me, but still, I am not an expert.
> Mani, could you also chime in a bit on what you envisioned?
+1, please elaborate to me as well.
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-04-15 14:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andy Shevchenko, Manivannan Sadhasivam, Manivannan Sadhasivam,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede, Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
Hi Chen, all,
...
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
>
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
>
> Mani, could you also chime in a bit on what you envisioned?
>
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
Related to "Hotplug of Non-discoverable Hardware",
I would add entries for busses in the connector without using an OF graph.
For I2C and later SPI, this was is done.
You already have an i2c-parent property but no node where an i2c device
can be added.
The last discussion related to hotplug, connectors and DT led to the RFC
series [1].
It is a huge series. The last patch give a real example of representation:
https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/
In your case I would see some thing like:
connector {
compatible = "pcie-m2-e-connector";
vpcie3v3-supply = <&vreg_wcn_3p3>;
vpcie1v8-supply = <&vreg_l15b_1p8>;
/*
* If those GPIOs have to be used by components available in
* the connected board, a Nexus node should be used.
*/
w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;
conn-i2c {
i2c-parent = <&i2c0>;
/*
* Here i2c devices available on the board
* connected to the connector can be described.
*/
};
/* Same kind to description for other busses */
conn-pcie {
pci-parent = <&xxxxx>;
/*
* The PCIe bus has abilities to discover devices.
* Not sure this node is needed.
*
* If a PCI device need a DT description to describe
* stuffs behind the device, what has been done for LAN966x
* could be re-used [2] and [3]
*/
};
conn_uart {
uart-parent = <&uart-ctrl>;
/* uart child (maybe a serdes) should be describe here
};
...
};
Of course, some DT symbols need to be exported in order to have them usable from
the DT describing the connected board.
This notion of exported symbol is not yet available upstream and is the purpose of
the RFC series [1].
[1] https://lore.kernel.org/all/20260112142009.1006236-1-herve.codina@bootlin.com/
[2] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.c
[3] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.dtso
Feel free to ask for more specific question if needed.
Best regards,
Hervé
>
> Thanks
> ChenYu
>
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] serial: 8250_accent: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 18:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
Cc: stable
When platform_device_register() fails in accent_init(), the embedded
struct device in accent_device has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
accent_init()
-> platform_device_register(&accent_device)
-> device_initialize(&accent_device.dev)
-> setup_pdev_dma_masks(&accent_device)
-> platform_device_add(&accent_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/tty/serial/8250/8250_accent.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_accent.c b/drivers/tty/serial/8250/8250_accent.c
index 1691f1a57f89..e9cf40268c0e 100644
--- a/drivers/tty/serial/8250/8250_accent.c
+++ b/drivers/tty/serial/8250/8250_accent.c
@@ -25,7 +25,13 @@ static struct platform_device accent_device = {
static int __init accent_init(void)
{
- return platform_device_register(&accent_device);
+ int ret;
+
+ ret = platform_device_register(&accent_device);
+ if (ret)
+ platform_device_put(&accent_device);
+
+ return ret;
}
module_init(accent_init);
--
2.43.0
^ permalink raw reply related
* [PATCH] serial: 8250_boca: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 18:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
Cc: stable
When platform_device_register() fails in boca_init(), the embedded
struct device in boca_device has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
boca_init()
-> platform_device_register(&boca_device)
-> device_initialize(&boca_device.dev)
-> setup_pdev_dma_masks(&boca_device)
-> platform_device_add(&boca_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/tty/serial/8250/8250_boca.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_boca.c b/drivers/tty/serial/8250/8250_boca.c
index a9b97c034653..70ea8e30ae80 100644
--- a/drivers/tty/serial/8250/8250_boca.c
+++ b/drivers/tty/serial/8250/8250_boca.c
@@ -39,7 +39,13 @@ static struct platform_device boca_device = {
static int __init boca_init(void)
{
- return platform_device_register(&boca_device);
+ int ret;
+
+ ret = platform_device_register(&boca_device);
+ if (ret)
+ platform_device_put(&boca_device);
+
+ return ret;
}
module_init(boca_init);
--
2.43.0
^ permalink raw reply related
* [PATCH] serial: 8250_exar_st16c554: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 18:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Paul B Schroeder,
Andrew Morton, linux-kernel, linux-serial
Cc: stable
When platform_device_register() fails in exar_init(), the embedded
struct device in exar_device has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
exar_init()
-> platform_device_register(&exar_device)
-> device_initialize(&exar_device.dev)
-> setup_pdev_dma_masks(&exar_device)
-> platform_device_add(&exar_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: e0980dafa329d ("[PATCH] Exar quad port serial")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/tty/serial/8250/8250_exar_st16c554.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_exar_st16c554.c b/drivers/tty/serial/8250/8250_exar_st16c554.c
index 933811ebfaac..b2c37f0c52aa 100644
--- a/drivers/tty/serial/8250/8250_exar_st16c554.c
+++ b/drivers/tty/serial/8250/8250_exar_st16c554.c
@@ -30,7 +30,13 @@ static struct platform_device exar_device = {
static int __init exar_init(void)
{
- return platform_device_register(&exar_device);
+ int ret;
+
+ ret = platform_device_register(&exar_device);
+ if (ret)
+ platform_device_put(&exar_device);
+
+ return ret;
}
module_init(exar_init);
--
2.43.0
^ permalink raw reply related
* [PATCH] serial: 8250_fourport: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 18:48 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
Cc: stable
When platform_device_register() fails in fourport_init(), the embedded
struct device in fourport_device has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
fourport_init()
-> platform_device_register(&fourport_device)
-> device_initialize(&fourport_device.dev)
-> setup_pdev_dma_masks(&fourport_device)
-> platform_device_add(&fourport_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/tty/serial/8250/8250_fourport.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_fourport.c b/drivers/tty/serial/8250/8250_fourport.c
index 3215b9b7afde..a65bc7316655 100644
--- a/drivers/tty/serial/8250/8250_fourport.c
+++ b/drivers/tty/serial/8250/8250_fourport.c
@@ -34,7 +34,13 @@ static struct platform_device fourport_device = {
static int __init fourport_init(void)
{
- return platform_device_register(&fourport_device);
+ int ret;
+
+ ret = platform_device_register(&fourport_device);
+ if (ret)
+ platform_device_put(&fourport_device);
+
+ return ret;
}
module_init(fourport_init);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox