* Re: [PATCH] serial: base: do not disable TX on hangup for console ports
From: kpursoty @ 2026-04-16 7:19 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
In-Reply-To: <1fpGAFo1KYyRDeGSGmaDWx6gXbV00C83qU_tep62Zu_cl9JfjpjWg8SKhw6z0owZ9eEMzXR2GnZ_U3V2PVi2R1fuGAmzgK43GYbWkCIBFf8=@proton.me>
Thanks for your notes. Patch withdrawn.
On Wednesday, 15 April 2026 at 09:01, kpursoty@proton.me <kpursoty@proton.me> wrote:
> 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] serial: 8250_accent: fix reference leak on failed device registration
From: Jiri Slaby @ 2026-04-16 6:13 UTC (permalink / raw)
To: Guangshuo Li, Greg Kroah-Hartman, Russell King, linux-kernel,
linux-serial
Cc: stable
In-Reply-To: <20260415183436.3763871-1-lgs201920130244@gmail.com>
Hi,
On 15. 04. 26, 20:34, Guangshuo Li wrote:
> 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.
What reference exactly?
> 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.
How did you verify you did the right change?
> 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);
In particular, what does put_device() do on a static device, even
initialized, ie. with no device::release? Try it...
IMO, all the patches are bogus.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Rob Herring (Arm) @ 2026-04-15 22:10 UTC (permalink / raw)
To: Douglas Anderson
Cc: astewart, linux-arm-kernel, Mark Brown, bhelgaas, maz, linux,
kees, Alan Stern, Saravana Kannan, netdev, linux-serial, davem,
andrew, Greg Kroah-Hartman, brgl, jirislaby, mani, Johan Hovold,
linux-aspeed, linux-pci, kuba, Alexander Lobakin, Leon Romanovsky,
andriy.shevchenko, Rafael J . Wysocki, Alexey Kardashevskiy,
lgirdwood, andrew, hkallweit1, linux-kernel, Danilo Krummrich,
Eric Dumazet, linux-usb, alexander.stein, Robin Murphy, pabeni,
devicetree, driver-core, joel, Christoph Hellwig
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, 06 Apr 2026 16:23:01 -0700, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
>
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
>
> (no changes since v4)
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - New
>
> drivers/base/core.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +++---
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 7 ++++---
> 12 files changed, 17 insertions(+), 16 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH] serial: 8250_hub6: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 18:53 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 hub6_init(), the embedded
struct device in hub6_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:
hub6_init()
-> platform_device_register(&hub6_device)
-> device_initialize(&hub6_device.dev)
-> setup_pdev_dma_masks(&hub6_device)
-> platform_device_add(&hub6_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_hub6.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_hub6.c b/drivers/tty/serial/8250/8250_hub6.c
index 273f59b9bca5..005dd6bec3da 100644
--- a/drivers/tty/serial/8250/8250_hub6.c
+++ b/drivers/tty/serial/8250/8250_hub6.c
@@ -43,9 +43,14 @@ static struct platform_device hub6_device = {
static int __init hub6_init(void)
{
- return platform_device_register(&hub6_device);
-}
+ int ret;
+
+ ret = platform_device_register(&hub6_device);
+ if (ret)
+ platform_device_put(&hub6_device);
+ return ret;
+}
module_init(hub6_init);
MODULE_AUTHOR("Russell King");
--
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
* [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_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_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
* 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
* 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: 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
* [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
* [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
* [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
* 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
* 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 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 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 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: 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: 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
* [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 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
* 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
* [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
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