* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Shawn Lin @ 2026-02-24 8:21 UTC (permalink / raw)
To: phasta
Cc: shawn.lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, netdev, nic_swsd, linux-arm-msm, dri-devel, linux-usb,
iommu, linux-riscv, David Airlie, Simona Vetter, linux-cxl,
linux-crypto, platform-driver-x86, linux-serial, mhi,
Andy Shevchenko, Jan Dabros, linux-i2c, Daniel Mack,
Haojian Zhuang, linux-spi, Jonathan Derrick, linux-pci,
linux-gpio, Mauro Carvalho Chehab, linux-media, linux-mmc,
Jakub Kicinski
In-Reply-To: <07fc896007d86b731cbfb3cf6bbdf4e5315d7a77.camel@mailbox.org>
在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
>> 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
>>> On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
>>>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
>>>> pci device drivers which rely on the devres machinery to help cleanup the IRQ
>>>> vectors.
>>>
>>> If you can please add this API with just a few users, and then convert
>>> remaining users via the subsystem trees in the next cycle.
>>> There's no need to risk wasting maintainer time on conflicts with
>>> conversions like this.
>>
>> Thanks for the suggestion, Jakub. I have little experience with
>> cross-subsystem cleanups like this, so your suggestion is very helpful.
>
>
> When I removed the hybrid nature of pci_request_region() et al., I
> concluded that there were so few users that doing them all in one run
> was sufficient.
>
> For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> step strategy is necessary for the reasons that Jakub details.
>
> It is then smart to omit an easy to port subsystem / driver for the
> ultimate patch series where one then removes the hybrid behavior from
> PCI itself, after porting the last driver.
>
> In general, as Jakub details, those step-by-step cleanups are a bit
> safer, since you can proof valid behavior early on and in case of an
> explosion they are very easy to revert.
>
Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
removing pcim_iomap_table earlier. This first version was perhaps a bit
too aggressive. For v2, I think the plan should start with addressing
the switchtec and vmd drivers, since both of those, along with the new
API additions, can be handled entirely within the PCI subsystem scope.
>
> P.
>
^ permalink raw reply
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Philipp Stanner @ 2026-02-24 7:47 UTC (permalink / raw)
To: Shawn Lin, Jakub Kicinski
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, Philipp Stanner, netdev,
nic_swsd, linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <ec226aa1-5cc8-855f-8f90-1d7f89efe766@rock-chips.com>
On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
> 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> > > pci device drivers which rely on the devres machinery to help cleanup the IRQ
> > > vectors.
> >
> > If you can please add this API with just a few users, and then convert
> > remaining users via the subsystem trees in the next cycle.
> > There's no need to risk wasting maintainer time on conflicts with
> > conversions like this.
>
> Thanks for the suggestion, Jakub. I have little experience with
> cross-subsystem cleanups like this, so your suggestion is very helpful.
When I removed the hybrid nature of pci_request_region() et al., I
concluded that there were so few users that doing them all in one run
was sufficient.
For larger reworks, like removing pcim_iomap_table(), a slower step-by-
step strategy is necessary for the reasons that Jakub details.
It is then smart to omit an easy to port subsystem / driver for the
ultimate patch series where one then removes the hybrid behavior from
PCI itself, after porting the last driver.
In general, as Jakub details, those step-by-step cleanups are a bit
safer, since you can proof valid behavior early on and in case of an
explosion they are very easy to revert.
P.
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Philipp Stanner @ 2026-02-24 7:39 UTC (permalink / raw)
To: Simon Richter, Shawn Lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc
In-Reply-To: <6223f3cb-693f-42e7-9147-30f659f08563@hogyros.de>
On Tue, 2026-02-24 at 13:14 +0900, Simon Richter wrote:
> Hi,
>
> On 2/24/26 12:29 AM, Shawn Lin wrote:
>
> > When such a driver also uses `pcim_enable_device()`, the devres framework may
> > attempt to free the IRQ vectors a second time upon device release, leading to
> > a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> > while 35 other drivers correctly rely solely on the implicit cleanup.
>
> Would it make sense to have a function pcim_free_irq_vectors(), to allow
> explicit freeing even if the device is otherwise managed, analogous to
> pcim_iounmap()?
We used to add those. In part because it is easier to port old users.
Nowadays I tend to think that those APIs were more on the too-complex
than too-simple side for a long time. As an expert or as the API
designer you wouldn't expect it, but there are actually far too many
users who came to believe they always have to use pcim_iounmap() and
counter parts.
If I could design it from scratch I would probably try to tell users to
use the unmanaged versions instead of revoking the devres consequence.
Devres is actually about your consequence always happening whenever the
driver unloads, for whatever reason.
P.
^ permalink raw reply
* Re: [PATCH v5 4/9] dt-bindings: serial: Document the graph port
From: Manivannan Sadhasivam @ 2026-02-24 7:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
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: <20260224-peacock-of-improbable-poetry-b4cfdc@quoll>
On Tue, Feb 24, 2026 at 08:09:17AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Feb 24, 2026 at 11:00:50AM +0530, Manivannan Sadhasivam wrote:
> > A serial controller could be connected to an external connector like PCIe
> > M.2 for controlling the serial interface of the card. Hence, document the
> > OF graph port.
> >
> > Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
>
> Please drop. The binding is not being sent to the device during testing,
> thus it is impossible to test it.
>
b4 picked it up since the tag was given in the cover letter and I forgot to
remove it while sending.
If I happen to send next version, I will drop it from all bindings patches.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v5 4/9] dt-bindings: serial: Document the graph port
From: Krzysztof Kozlowski @ 2026-02-24 7:09 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: <20260224-pci-m2-e-v5-4-dd9b9501d33c@oss.qualcomm.com>
On Tue, Feb 24, 2026 at 11:00:50AM +0530, Manivannan Sadhasivam wrote:
> A serial controller could be connected to an external connector like PCIe
> M.2 for controlling the serial interface of the card. Hence, document the
> OF graph port.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Please drop. The binding is not being sent to the device during testing,
thus it is impossible to test it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Krzysztof Kozlowski @ 2026-02-24 7:08 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
In-Reply-To: <20260224-pci-m2-e-v5-5-dd9b9501d33c@oss.qualcomm.com>
On Tue, Feb 24, 2026 at 11:00:51AM +0530, Manivannan Sadhasivam wrote:
> Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
> in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
> provides interfaces like PCIe or SDIO to attach the WiFi devices to the
> host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
> devices. Spec also provides an optional interface to connect the UIM card,
> but that is not covered in this binding.
>
> The connector provides a primary power supply of 3.3v, along with an
> optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
> 1.8v sideband signaling.
>
> The connector also supplies optional signals in the form of GPIOs for fine
> grained power management.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Please drop, cannot and did not happen.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Krzysztof Kozlowski @ 2026-02-24 7:08 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
In-Reply-To: <20260224-pci-m2-e-v5-6-dd9b9501d33c@oss.qualcomm.com>
On Tue, Feb 24, 2026 at 11:00:52AM +0530, Manivannan Sadhasivam wrote:
> Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
> LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
> spec, it looks very similar to the M.2 Key E connector. So add the
> "pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
> to reuse the Key E binding.
>
> Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Please drop. You cannot test a binding. It's IMPOSSIBLE.
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 8/9] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add support for handling the power sequence of the PCIe M.2 Key E
connectors. These connectors are used to attach the Wireless Connectivity
devices to the host machine including combinations of WiFi, BT, NFC using
interfaces such as PCIe/SDIO for WiFi, USB/UART for BT and I2C for NFC.
Currently, this driver supports only the PCIe interface for WiFi and UART
interface for BT. The driver also only supports driving the 3.3v/1.8v power
supplies and W_DISABLE{1/2}# GPIOs. The optional signals of the Key E
connectors are not currently supported.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 107 ++++++++++++++++++++++++++++--
1 file changed, 101 insertions(+), 6 deletions(-)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index d31a7dd8b35c..3507cdcb1e7b 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -5,10 +5,13 @@
*/
#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_graph.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pwrseq/provider.h>
#include <linux/regulator/consumer.h>
@@ -25,16 +28,18 @@ struct pwrseq_pcie_m2_ctx {
struct regulator_bulk_data *regs;
size_t num_vregs;
struct notifier_block nb;
+ struct gpio_desc *w_disable1_gpio;
+ struct gpio_desc *w_disable2_gpio;
};
-static int pwrseq_pcie_m2_m_vregs_enable(struct pwrseq_device *pwrseq)
+static int pwrseq_pcie_m2_vregs_enable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
return regulator_bulk_enable(ctx->num_vregs, ctx->regs);
}
-static int pwrseq_pcie_m2_m_vregs_disable(struct pwrseq_device *pwrseq)
+static int pwrseq_pcie_m2_vregs_disable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
@@ -43,18 +48,84 @@ static int pwrseq_pcie_m2_m_vregs_disable(struct pwrseq_device *pwrseq)
static const struct pwrseq_unit_data pwrseq_pcie_m2_vregs_unit_data = {
.name = "regulators-enable",
- .enable = pwrseq_pcie_m2_m_vregs_enable,
- .disable = pwrseq_pcie_m2_m_vregs_disable,
+ .enable = pwrseq_pcie_m2_vregs_enable,
+ .disable = pwrseq_pcie_m2_vregs_disable,
};
-static const struct pwrseq_unit_data *pwrseq_pcie_m2_m_unit_deps[] = {
+static const struct pwrseq_unit_data *pwrseq_pcie_m2_unit_deps[] = {
&pwrseq_pcie_m2_vregs_unit_data,
NULL
};
+static int pwrseq_pci_m2_e_uart_enable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);
+}
+
+static int pwrseq_pci_m2_e_uart_disable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 1);
+}
+
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_uart_unit_data = {
+ .name = "uart-enable",
+ .deps = pwrseq_pcie_m2_unit_deps,
+ .enable = pwrseq_pci_m2_e_uart_enable,
+ .disable = pwrseq_pci_m2_e_uart_disable,
+};
+
+static int pwrseq_pci_m2_e_pcie_enable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 0);
+}
+
+static int pwrseq_pci_m2_e_pcie_disable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 1);
+}
+
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_pcie_unit_data = {
+ .name = "pcie-enable",
+ .deps = pwrseq_pcie_m2_unit_deps,
+ .enable = pwrseq_pci_m2_e_pcie_enable,
+ .disable = pwrseq_pci_m2_e_pcie_disable,
+};
+
static const struct pwrseq_unit_data pwrseq_pcie_m2_m_pcie_unit_data = {
.name = "pcie-enable",
- .deps = pwrseq_pcie_m2_m_unit_deps,
+ .deps = pwrseq_pcie_m2_unit_deps,
+};
+
+static int pwrseq_pcie_m2_e_pwup_delay(struct pwrseq_device *pwrseq)
+{
+ /*
+ * FIXME: This delay is only required for some Qcom WLAN/BT cards like
+ * WCN7850 and not for all devices. But currently, there is no way to
+ * identify the device model before enumeration.
+ */
+ msleep(50);
+
+ return 0;
+}
+
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_uart_target_data = {
+ .name = "uart",
+ .unit = &pwrseq_pcie_m2_e_uart_unit_data,
+ .post_enable = pwrseq_pcie_m2_e_pwup_delay,
+};
+
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_pcie_target_data = {
+ .name = "pcie",
+ .unit = &pwrseq_pcie_m2_e_pcie_unit_data,
+ .post_enable = pwrseq_pcie_m2_e_pwup_delay,
};
static const struct pwrseq_target_data pwrseq_pcie_m2_m_pcie_target_data = {
@@ -62,11 +133,21 @@ static const struct pwrseq_target_data pwrseq_pcie_m2_m_pcie_target_data = {
.unit = &pwrseq_pcie_m2_m_pcie_unit_data,
};
+static const struct pwrseq_target_data *pwrseq_pcie_m2_e_targets[] = {
+ &pwrseq_pcie_m2_e_pcie_target_data,
+ &pwrseq_pcie_m2_e_uart_target_data,
+ NULL
+};
+
static const struct pwrseq_target_data *pwrseq_pcie_m2_m_targets[] = {
&pwrseq_pcie_m2_m_pcie_target_data,
NULL
};
+static const struct pwrseq_pcie_m2_pdata pwrseq_pcie_m2_e_of_data = {
+ .targets = pwrseq_pcie_m2_e_targets,
+};
+
static const struct pwrseq_pcie_m2_pdata pwrseq_pcie_m2_m_of_data = {
.targets = pwrseq_pcie_m2_m_targets,
};
@@ -125,6 +206,16 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
return dev_err_probe(dev, ret,
"Failed to get all regulators\n");
+ ctx->w_disable1_gpio = devm_gpiod_get_optional(dev, "w-disable1", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->w_disable1_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->w_disable1_gpio),
+ "Failed to get the W_DISABLE_1# GPIO\n");
+
+ ctx->w_disable2_gpio = devm_gpiod_get_optional(dev, "w-disable2", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->w_disable2_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->w_disable2_gpio),
+ "Failed to get the W_DISABLE_2# GPIO\n");
+
ctx->num_vregs = ret;
ret = devm_add_action_or_reset(dev, pwrseq_pcie_m2_free_regulators, ctx);
@@ -150,6 +241,10 @@ static const struct of_device_id pwrseq_pcie_m2_of_match[] = {
.compatible = "pcie-m2-m-connector",
.data = &pwrseq_pcie_m2_m_of_data,
},
+ {
+ .compatible = "pcie-m2-e-connector",
+ .data = &pwrseq_pcie_m2_e_of_data,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, pwrseq_pcie_m2_of_match);
--
2.51.0
^ permalink raw reply related
* [PATCH v5 7/9] Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Power supply to the M.2 Bluetooth device attached to the host using M.2
connector is controlled using the 'uart' pwrseq device. So add support for
getting the pwrseq device if the OF graph link is present. Once obtained,
the existing pwrseq APIs can be used to control the power supplies of the
M.2 card.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/bluetooth/hci_qca.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 5b02e7c3f56d..0454c2318461 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -26,6 +26,7 @@
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/acpi.h>
#include <linux/platform_device.h>
#include <linux/pwrseq/consumer.h>
@@ -2421,6 +2422,14 @@ static int qca_serdev_probe(struct serdev_device *serdev)
case QCA_WCN6855:
case QCA_WCN7850:
case QCA_WCN6750:
+ if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
+ qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
+ "uart");
+ if (IS_ERR(qcadev->bt_power->pwrseq))
+ return PTR_ERR(qcadev->bt_power->pwrseq);
+ break;
+ }
+
if (!device_property_present(&serdev->dev, "enable-gpios")) {
/*
* Backward compatibility with old DT sources. If the
--
2.51.0
^ permalink raw reply related
* [PATCH v5 9/9] power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
For supporting bluetooth over the non-discoverable UART interface of
WCN7850, create the serdev device after enumerating the PCIe interface.
This is mandatory since the device ID is only known after the PCIe
enumeration and the ID is used for creating the serdev device.
Since by default there is no OF or ACPI node for the created serdev,
create a dynamic OF 'bluetooth' node with the 'compatible' property and
attach it to the serdev device. This will allow the serdev device to bind
to the existing bluetooth driver.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/power/sequencing/Kconfig | 3 +-
drivers/power/sequencing/pwrseq-pcie-m2.c | 171 +++++++++++++++++++++++++++++-
2 files changed, 170 insertions(+), 4 deletions(-)
diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index f5fff84566ba..55aeef125e6f 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -37,7 +37,8 @@ config POWER_SEQUENCING_TH1520_GPU
config POWER_SEQUENCING_PCIE_M2
tristate "PCIe M.2 connector power sequencing driver"
- depends on OF || COMPILE_TEST
+ depends on (PCI && OF) || COMPILE_TEST
+ select OF_DYNAMIC
help
Say Y here to enable the power sequencing driver for PCIe M.2
connectors. This driver handles the power sequencing for the M.2
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index 3507cdcb1e7b..d398487202b9 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -12,9 +12,11 @@
#include <linux/of.h>
#include <linux/of_graph.h>
#include <linux/of_platform.h>
+#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/pwrseq/provider.h>
#include <linux/regulator/consumer.h>
+#include <linux/serdev.h>
#include <linux/slab.h>
struct pwrseq_pcie_m2_pdata {
@@ -30,6 +32,9 @@ struct pwrseq_pcie_m2_ctx {
struct notifier_block nb;
struct gpio_desc *w_disable1_gpio;
struct gpio_desc *w_disable2_gpio;
+ struct serdev_device *serdev;
+ struct of_changeset *ocs;
+ struct device *dev;
};
static int pwrseq_pcie_m2_vregs_enable(struct pwrseq_device *pwrseq)
@@ -172,13 +177,169 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
return PWRSEQ_NO_MATCH;
}
-static void pwrseq_pcie_m2_free_regulators(void *data)
+static void pwrseq_pcie_m2_free_resources(void *data)
{
struct pwrseq_pcie_m2_ctx *ctx = data;
+ serdev_device_remove(ctx->serdev);
+ bus_unregister_notifier(&pci_bus_type, &ctx->nb);
+ of_changeset_revert(ctx->ocs);
+ of_changeset_destroy(ctx->ocs);
regulator_bulk_free(ctx->num_vregs, ctx->regs);
}
+static int pwrseq_m2_pcie_create_bt_node(struct pwrseq_pcie_m2_ctx *ctx,
+ struct device_node *parent)
+{
+ struct device *dev = ctx->dev;
+ struct device_node *np;
+ int ret;
+
+ ctx->ocs = devm_kzalloc(dev, sizeof(*ctx->ocs), GFP_KERNEL);
+ if (!ctx->ocs)
+ return -ENOMEM;
+
+ of_changeset_init(ctx->ocs);
+
+ np = of_changeset_create_node(ctx->ocs, parent, "bluetooth");
+ if (!np) {
+ dev_err(dev, "Failed to create bluetooth node\n");
+ ret = -ENODEV;
+ goto err_destroy_changeset;
+ }
+
+ ret = of_changeset_add_prop_string(ctx->ocs, np, "compatible", "qcom,wcn7850-bt");
+ if (ret) {
+ dev_err(dev, "Failed to add bluetooth compatible: %d\n", ret);
+ goto err_destroy_changeset;
+ }
+
+ ret = of_changeset_apply(ctx->ocs);
+ if (ret) {
+ dev_err(dev, "Failed to apply changeset: %d\n", ret);
+ goto err_destroy_changeset;
+ }
+
+ ret = device_add_of_node(&ctx->serdev->dev, np);
+ if (ret) {
+ dev_err(dev, "Failed to add OF node: %d\n", ret);
+ goto err_revert_changeset;
+ }
+
+ return 0;
+
+err_revert_changeset:
+ of_changeset_revert(ctx->ocs);
+err_destroy_changeset:
+ of_changeset_destroy(ctx->ocs);
+
+ return ret;
+}
+
+static int pwrseq_m2_pcie_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct pwrseq_pcie_m2_ctx *ctx = container_of(nb, struct pwrseq_pcie_m2_ctx, nb);
+ struct pci_dev *pdev = to_pci_dev(data);
+ struct serdev_controller *serdev_ctrl;
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+ * Check whether the PCI device is associated with this M.2 connector or
+ * not, by comparing the OF node of the PCI device parent and the Port 0
+ * (PCIe) remote node parent OF node.
+ */
+ struct device_node *pci_parent __free(device_node) =
+ of_graph_get_remote_node(dev_of_node(ctx->dev), 0, 0);
+ if (!pci_parent || (pci_parent != pdev->dev.parent->of_node))
+ return NOTIFY_DONE;
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ /* Create serdev device for WCN7850 */
+ if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
+ struct device_node *serdev_parent __free(device_node) =
+ of_graph_get_remote_node(dev_of_node(ctx->dev), 1, 1);
+ if (!serdev_parent)
+ return NOTIFY_DONE;
+
+ serdev_ctrl = of_find_serdev_controller_by_node(serdev_parent);
+ if (!serdev_ctrl)
+ return NOTIFY_DONE;
+
+ ctx->serdev = serdev_device_alloc(serdev_ctrl);
+ if (!ctx->serdev)
+ return NOTIFY_BAD;
+
+ ret = pwrseq_m2_pcie_create_bt_node(ctx, serdev_parent);
+ if (ret) {
+ serdev_device_put(ctx->serdev);
+ return notifier_from_errno(ret);
+ }
+
+ ret = serdev_device_add(ctx->serdev);
+ if (ret) {
+ dev_err(dev, "Failed to add serdev for WCN7850: %d\n", ret);
+ of_changeset_revert(ctx->ocs);
+ of_changeset_destroy(ctx->ocs);
+ serdev_device_put(ctx->serdev);
+ return notifier_from_errno(ret);
+ }
+ }
+ break;
+ case BUS_NOTIFY_REMOVED_DEVICE:
+ /* Destroy serdev device for WCN7850 */
+ if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
+ serdev_device_remove(ctx->serdev);
+ of_changeset_revert(ctx->ocs);
+ of_changeset_destroy(ctx->ocs);
+ }
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static bool pwrseq_pcie_m2_check_remote_node(struct device *dev, u8 port, u8 endpoint,
+ const char *node)
+{
+ struct device_node *remote __free(device_node) =
+ of_graph_get_remote_node(dev_of_node(dev), port, endpoint);
+
+ if (remote && of_node_name_eq(remote, node))
+ return true;
+
+ return false;
+}
+
+/*
+ * If the connector exposes a non-discoverable bus like UART, the respective
+ * protocol device needs to be created manually with the help of the notifier
+ * of the discoverable bus like PCIe.
+ */
+static int pwrseq_pcie_m2_register_notifier(struct pwrseq_pcie_m2_ctx *ctx, struct device *dev)
+{
+ int ret;
+
+ /*
+ * Register a PCI notifier for Key E connector that has PCIe as Port
+ * 0/Endpoint 0 interface and Serial as Port 3/Endpoint 0 interface.
+ */
+ if (pwrseq_pcie_m2_check_remote_node(dev, 3, 0, "serial")) {
+ if (pwrseq_pcie_m2_check_remote_node(dev, 0, 0, "pcie")) {
+ ctx->dev = dev;
+ ctx->nb.notifier_call = pwrseq_m2_pcie_notify;
+ ret = bus_register_notifier(&pci_bus_type, &ctx->nb);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to register notifier for serdev\n");
+ }
+ }
+
+ return 0;
+}
+
static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -218,7 +379,7 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
ctx->num_vregs = ret;
- ret = devm_add_action_or_reset(dev, pwrseq_pcie_m2_free_regulators, ctx);
+ ret = devm_add_action_or_reset(dev, pwrseq_pcie_m2_free_resources, ctx);
if (ret)
return ret;
@@ -233,7 +394,11 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(ctx->pwrseq),
"Failed to register the power sequencer\n");
- return 0;
+ /*
+ * Register a notifier for creating protocol devices for
+ * non-discoverable busses like UART.
+ */
+ return pwrseq_pcie_m2_register_notifier(ctx, dev);
}
static const struct of_device_id pwrseq_pcie_m2_of_match[] = {
--
2.51.0
^ permalink raw reply related
* [PATCH v5 6/9] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
spec, it looks very similar to the M.2 Key E connector. So add the
"pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
to reuse the Key E binding.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
.../devicetree/bindings/connector/pcie-m2-e-connector.yaml | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
index 82dfd776d480..48fe80846cb4 100644
--- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -17,7 +17,14 @@ description:
properties:
compatible:
- const: pcie-m2-e-connector
+ oneOf:
+ - items:
+ - enum:
+ - pcie-m2-1620-lga-connector
+ - const: pcie-m2-e-connector
+ - items:
+ - enum:
+ - pcie-m2-e-connector
vpcie3v3-supply:
description: A phandle to the regulator for 3.3v supply.
--
2.51.0
^ permalink raw reply related
* [PATCH v5 5/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add the devicetree binding for PCIe M.2 Mechanical Key E connector defined
in the PCI Express M.2 Specification, r4.0, sec 5.1.2. This connector
provides interfaces like PCIe or SDIO to attach the WiFi devices to the
host machine, USB or UART+PCM interfaces to attach the Bluetooth (BT)
devices. Spec also provides an optional interface to connect the UIM card,
but that is not covered in this binding.
The connector provides a primary power supply of 3.3v, along with an
optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
1.8v sideband signaling.
The connector also supplies optional signals in the form of GPIOs for fine
grained power management.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
.../bindings/connector/pcie-m2-e-connector.yaml | 184 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 185 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
new file mode 100644
index 000000000000..82dfd776d480
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCIe M.2 Mechanical Key E Connector
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
+
+description:
+ A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E
+ connector. Mechanical Key E connectors are used to connect Wireless
+ Connectivity devices including combinations of Wi-Fi, BT, NFC to the host
+ machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C.
+
+properties:
+ compatible:
+ const: pcie-m2-e-connector
+
+ vpcie3v3-supply:
+ description: A phandle to the regulator for 3.3v supply.
+
+ vpcie1v8-supply:
+ description: A phandle to the regulator for VIO 1.8v supply.
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: I2C interface
+
+ clocks:
+ description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to
+ the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for
+ more details.
+ maxItems: 1
+
+ w-disable1-gpios:
+ description: GPIO output to W_DISABLE1# signal. This signal is used by the
+ host system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
+ Specification r4.0, sec 3.1.12.3 for more details.
+ maxItems: 1
+
+ w-disable2-gpios:
+ description: GPIO output to W_DISABLE2# signal. This signal is used by the
+ host system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2
+ Specification r4.0, sec 3.1.12.3 for more details.
+ maxItems: 1
+
+ viocfg-gpios:
+ description: GPIO input to IO voltage configuration (VIO_CFG) signal. The
+ card drives this signal to indicate to the host system whether the card
+ supports an independent IO voltage domain for sideband signals. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details.
+ maxItems: 1
+
+ uart-wake-gpios:
+ description: GPIO input to UART_WAKE# signal. The card asserts this signal
+ to wake the host system and initiate UART interface communication. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.8.1 for more details.
+ maxItems: 1
+
+ sdio-wake-gpios:
+ description: GPIO input to SDIO_WAKE# signal. The card asserts this signal
+ to wake the host system and initiate SDIO interface communication. Refer,
+ PCI Express M.2 Specification r4.0, sec 3.1.7 for more details.
+ maxItems: 1
+
+ sdio-reset-gpios:
+ description: GPIO output to SDIO_RESET# signal. This signal is used by the
+ host system to reset SDIO interface of the M.2 card. Refer, PCI Express
+ M.2 Specification r4.0, sec 3.1.7 for more details.
+ maxItems: 1
+
+ vendor-porta-gpios:
+ description: GPIO for the first vendor specific signal (VENDOR_PORTA). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ vendor-portb-gpios:
+ description: GPIO for the second vendor specific signal (VENDOR_PORTB). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ vendor-portc-gpios:
+ description: GPIO for the third vendor specific signal (VENDOR_PORTC). This
+ signal's functionality is defined by the card manufacturer and may be
+ used for proprietary features. Refer the card vendor's documentation for
+ details.
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: OF graph bindings modeling the interfaces exposed on the
+ connector. Since a single connector can have multiple interfaces, every
+ interface has an assigned OF graph port number as described below.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: PCIe interface for Wi-Fi
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: SDIO interface for Wi-Fi
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: USB 2.0 interface for BT
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UART interface for BT
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: PCM/I2S interface
+
+ anyOf:
+ - anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+ - anyOf:
+ - required:
+ - port@2
+ - required:
+ - port@3
+
+required:
+ - compatible
+ - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+ # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <&vreg_wcn_3p3>;
+ vpcie1v8-supply = <&vreg_l15b_1p8>;
+ i2c-parent = <&i2c0>;
+ 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>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie4_port0_ep>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&uart14_ep>;
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 55af015174a5..565198d3b500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21044,6 +21044,7 @@ PCIE M.2 POWER SEQUENCING
M: Manivannan Sadhasivam <mani@kernel.org>
L: linux-pci@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
F: Documentation/devicetree/bindings/connector/pcie-m2-m-connector.yaml
F: drivers/power/sequencing/pwrseq-pcie-m2.c
--
2.51.0
^ permalink raw reply related
* [PATCH v5 4/9] dt-bindings: serial: Document the graph port
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
A serial controller could be connected to an external connector like PCIe
M.2 for controlling the serial interface of the card. Hence, document the
OF graph port.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/serial/serial.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 6aa9cfae417b..96eb1de8771e 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -87,6 +87,9 @@ properties:
description:
TX FIFO threshold configuration (in bytes).
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
patternProperties:
"^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$":
if:
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/9] serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If an external connector like M.2 is connected to the serdev controller
in DT, then the serdev devices may be created dynamically by the connector
driver. So do not return -ENODEV from of_serdev_register_devices() if the
static nodes are not found and the graph node is used.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index bf88b95f7458..e9d044a331b0 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/of_device.h>
#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
@@ -561,7 +562,13 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
} else
found = true;
}
- if (!found)
+
+ /*
+ * When the serdev controller is connected to an external connector like
+ * M.2 in DT, then the serdev devices may be created dynamically by the
+ * connector driver.
+ */
+ if (!found && !of_graph_is_present(dev_of_node(&ctrl->dev)))
return -ENODEV;
return 0;
--
2.51.0
^ permalink raw reply related
* [PATCH v5 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski,
Bartosz Golaszewski
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.
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.
Open questions
==============
Though this series adds the relevant functionality for handling the M.2 Key M
connectors, there are still a few open questions exists on the design.
1. Created a dynamic 'bluetooth' node with the compatible property matching the
WCN7850 device and attached it to the serdev device. This allowed reusing the
existing OF based BT driver without much modifications.
2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
the PCIe device DT node to extract properties such as
'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
add the PCIe DT node in the Root Port in conjunction with the Port node as
below?
pcie@0 {
wifi@0 {
compatible = "pci17cb,1103";
...
qcom,calibration-variant = "LE_X13S";
};
port {
pcie4_port0_ep: endpoint {
remote-endpoint = <&m2_e_pcie_ep>;
};
};
};
This will also require marking the PMU supplies optional in the relevant ath
bindings for M.2 cards.
3. Some M.2 cards require specific power up sequence like delays between
regulator/GPIO and such. For instance, the WCN7850 card supported in this series
requires 50ms delay between powering up an interface and driving it. I've just
hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
driver doesn't know anything about the device it is dealing with before powering
it ON, how should it handle the device specific power requirements? Should we
hardcode the device specific property in the connector node? But then, it will
no longer become a generic M.2 connector and sort of defeats the purpose of the
connector binding.
I hope to address these questions with the help of the relevant subsystem
maintainers and the community.
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.
Dependency
==========
This series is dependent on the M.2 Key M series [1] on top of v6.19-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 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 (9):
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
dt-bindings: connector: m2: Add M.2 1620 LGA soldered down 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 | 191 ++++++++++++++
.../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 | 278 ++++++++++++++++++++-
drivers/tty/serdev/core.c | 28 ++-
include/linux/serdev.h | 24 +-
8 files changed, 514 insertions(+), 23 deletions(-)
---
base-commit: 559f264e403e4d58d56a17595c60a1de011c5e20
change-id: 20251112-pci-m2-e-94695ac9d657
Best regards,
--
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v5 1/9] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede, Bartosz Golaszewski
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
If these helpers receive the 'const struct device' pointer, then the const
qualifier will get dropped, leading to below warning:
warning: passing argument 1 of ‘to_serdev_device_driver’ discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
This is not an issue as of now, but with the future commits adding serdev
device based driver matching, this warning will get triggered. Hence,
convert these helpers to macros so that the qualifier get preserved and
also use container_of_const() as container_of() is deprecated.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
include/linux/serdev.h | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 5654c58eb73c..0c7d3c27d1f8 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -49,10 +49,7 @@ struct serdev_device {
struct mutex write_lock;
};
-static inline struct serdev_device *to_serdev_device(struct device *d)
-{
- return container_of(d, struct serdev_device, dev);
-}
+#define to_serdev_device(d) container_of_const(d, struct serdev_device, dev)
/**
* struct serdev_device_driver - serdev slave device driver
@@ -68,10 +65,7 @@ struct serdev_device_driver {
void (*shutdown)(struct serdev_device *);
};
-static inline struct serdev_device_driver *to_serdev_device_driver(struct device_driver *d)
-{
- return container_of(d, struct serdev_device_driver, driver);
-}
+#define to_serdev_device_driver(d) container_of_const(d, struct serdev_device_driver, driver)
enum serdev_parity {
SERDEV_PARITY_NONE,
@@ -112,10 +106,7 @@ struct serdev_controller {
const struct serdev_controller_ops *ops;
};
-static inline struct serdev_controller *to_serdev_controller(struct device *d)
-{
- return container_of(d, struct serdev_controller, dev);
-}
+#define to_serdev_controller(d) container_of_const(d, struct serdev_controller, dev)
static inline void *serdev_device_get_drvdata(const struct serdev_device *serdev)
{
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/9] serdev: Add an API to find the serdev controller associated with the devicetree node
From: Manivannan Sadhasivam via B4 Relay @ 2026-02-24 5:30 UTC (permalink / raw)
To: 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
Cc: 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,
Manivannan Sadhasivam, Hans de Goede
In-Reply-To: <20260224-pci-m2-e-v5-0-dd9b9501d33c@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add of_find_serdev_controller_by_node() API to find the serdev controller
device associated with the devicetree node.
Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> # ThinkPad T14s gen6 (arm64)
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
drivers/tty/serdev/core.c | 19 +++++++++++++++++++
include/linux/serdev.h | 9 +++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 8f25510f89b6..bf88b95f7458 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -514,6 +514,25 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
}
EXPORT_SYMBOL_GPL(serdev_controller_alloc);
+#ifdef CONFIG_OF
+/**
+ * of_find_serdev_controller_by_node() - Find the serdev controller associated
+ * with the devicetree node
+ * @node: Devicetree node
+ *
+ * Return: Pointer to the serdev controller associated with the node. NULL if
+ * the controller is not found. Caller is responsible for calling
+ * serdev_controller_put() to drop the reference.
+ */
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+ struct device *dev = bus_find_device_by_of_node(&serdev_bus_type, node);
+
+ return (dev && dev->type == &serdev_ctrl_type) ? to_serdev_controller(dev) : NULL;
+}
+EXPORT_SYMBOL_GPL(of_find_serdev_controller_by_node);
+#endif
+
static int of_serdev_register_devices(struct serdev_controller *ctrl)
{
struct device_node *node;
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 0c7d3c27d1f8..188c0ba62d50 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -334,4 +334,13 @@ static inline bool serdev_acpi_get_uart_resource(struct acpi_resource *ares,
}
#endif /* CONFIG_ACPI */
+#ifdef CONFIG_OF
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node);
+#else
+static inline struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#endif /*_LINUX_SERDEV_H */
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Simon Richter @ 2026-02-24 4:14 UTC (permalink / raw)
To: Shawn Lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
Hi,
On 2/24/26 12:29 AM, Shawn Lin wrote:
> When such a driver also uses `pcim_enable_device()`, the devres framework may
> attempt to free the IRQ vectors a second time upon device release, leading to
> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
> while 35 other drivers correctly rely solely on the implicit cleanup.
Would it make sense to have a function pcim_free_irq_vectors(), to allow
explicit freeing even if the device is otherwise managed, analogous to
pcim_iounmap()?
Simon
^ permalink raw reply
* [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
This patch series addresses a long-standing design issue in the PCI/MSI
subsystem where the implicit, automatic management of IRQ vectors by
the devres framework conflicts with explicit driver cleanup, creating
ambiguity and potential resource management bugs.
==== The Problem: Implicit vs. Explicit Management ====
Historically, `pcim_enable_device()` not only manages standard PCI resources
(BARs) via devres but also implicitly triggers automatic IRQ vector management
by setting a flag that registers `pcim_msi_release()` as a cleanup action.
This creates an ambiguous ownership model. Many drivers follow a pattern of:
1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
When such a driver also uses `pcim_enable_device()`, the devres framework may
attempt to free the IRQ vectors a second time upon device release, leading to
a double-free. Analysis of the tree shows this hazardous pattern exists widely,
while 35 other drivers correctly rely solely on the implicit cleanup.
==== The Solution: Making Management Explicit ====
This series enforces a clear, predictable model:
1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
vectors should use these functions, which set the is_msi_managed flag and
ensure automatic cleanup.
2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
make an explicit call to pcim_alloc_irq_vectors().
3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
are now solely the driver's responsibility to free with pci_free_irq_vectors().
With these changes, we clear ownership model: Explicit resource management eliminates
ambiguity and follows the "principle of least surprise." New drivers choose one model and
be consistent.
- Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
- Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
==== Testing And Review ====
1. This series is only compiled test with allmodconfig.
2. Given the substantial size of this patch series, I have structured the mailing
to facilitate efficient review. The cover letter, the first patch and the last one will be sent
to all relevant mailing lists and key maintainers to ensure broad visibility and
initial feedback on the overall approach. The remaining subsystem-specific patches
will be sent only to the respective subsystem maintainers and their associated
mailing lists, reducing noise.
Please help review it, much thanks!
Shawn Lin (37):
PCI/MSI: Add Devres managed IRQ vectors allocation
mmc: cavium: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
media: ipu6: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
gpio: merrifield: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
PCI: switchtec: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
PCI: vmd: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
spi: spi-pci1xxxx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
spi: pxa2xx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
i2c: amd-mp2: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
i2c: mchp-pci1xxxx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
i2c: thunderx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
i2c: designware: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
bus: mhi: host: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
serial: 8250_mid: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
serial: 8250_exar: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
platform/x86/intel: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
crypto: safexcel: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
crypto: octeontx2: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
cxl/pci: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
drm/hisilicon/hibmc: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
iommu/riscv: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
thunderbolt: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
accel/amdxdna: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
accel/ivpu: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
accel/qaic: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
net: stmmac: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
r8169: Replace pci_alloc_irq_vectors() with pcim_alloc_irq_vectors()
net: thunder_bgx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
net: hibmcge: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
mfd: intel-lpss: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
dmaengine: hsu: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
dmaengine: hisilicon: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
i3c: mipi-i3c-hci-pci: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
HID: intel-ish-ipc: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
HID: Intel-thc-hid: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
misc: microchip: pci1xxxx: Replace pci_alloc_irq_vectors() with
pcim_alloc_irq_vectors()
PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()
drivers/accel/amdxdna/aie2_pci.c | 2 +-
drivers/accel/ivpu/ivpu_drv.c | 2 +-
drivers/accel/qaic/qaic_drv.c | 4 ++--
drivers/bus/mhi/host/pci_generic.c | 3 ++-
drivers/crypto/inside-secure/safexcel.c | 8 +++----
drivers/crypto/marvell/octeontx2/otx2_cptpf_main.c | 2 +-
drivers/crypto/marvell/octeontx2/otx2_cptvf_main.c | 4 ++--
drivers/cxl/pci.c | 8 ++-----
drivers/dma/hisi_dma.c | 3 +--
drivers/dma/hsu/pci.c | 2 +-
drivers/gpio/gpio-merrifield.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 ++--
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
.../intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 2 +-
drivers/i2c/busses/i2c-amd-mp2-pci.c | 2 +-
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-mchp-pci1xxxx.c | 2 +-
drivers/i2c/busses/i2c-thunderx-pcidrv.c | 2 +-
drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c | 2 +-
drivers/iommu/riscv/iommu-pci.c | 4 ++--
drivers/media/pci/intel/ipu6/ipu6.c | 2 +-
drivers/mfd/intel-lpss-pci.c | 2 +-
drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 2 +-
drivers/mmc/host/cavium-thunderx.c | 2 +-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 4 ++--
drivers/net/ethernet/hisilicon/hibmcge/hbg_irq.c | 4 ++--
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 6 ++---
drivers/pci/controller/vmd.c | 4 ++--
drivers/pci/msi/api.c | 26 ++++++++++++++++++++++
drivers/pci/msi/msi.c | 4 +---
drivers/pci/switch/switchtec.c | 6 ++---
drivers/platform/x86/intel/ehl_pse_io.c | 2 +-
drivers/spi/spi-pci1xxxx.c | 4 ++--
drivers/spi/spi-pxa2xx-pci.c | 2 +-
drivers/thunderbolt/nhi.c | 6 ++---
drivers/tty/serial/8250/8250_exar.c | 2 +-
drivers/tty/serial/8250/8250_mid.c | 2 +-
include/linux/pci.h | 22 ++++++++++++++++++
39 files changed, 104 insertions(+), 62 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 0/37] PCI/MSI: Enforce explicit IRQ vector management by removing devres auto-free
From: Shawn Lin @ 2026-02-24 2:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: shawn.lin, Andy Shevchenko, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Jan Dabros, linux-i2c, Daniel Mack,
Haojian Zhuang, linux-spi, Jonathan Derrick, linux-pci,
linux-gpio, Mauro Carvalho Chehab, linux-media, linux-mmc
In-Reply-To: <aZyQmc7nOt87jitX@smile.fi.intel.com>
在 2026/02/24 星期二 1:38, Andy Shevchenko 写道:
> On Tue, Feb 24, 2026 at 12:09:37AM +0800, Shawn Lin wrote:
>> 在 2026/02/23 星期一 23:50, Andy Shevchenko 写道:
>>> On Mon, Feb 23, 2026 at 5:32 PM Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>>>
>>>> This patch series addresses a long-standing design issue in the PCI/MSI
>>>> subsystem where the implicit, automatic management of IRQ vectors by
>>>> the devres framework conflicts with explicit driver cleanup, creating
>>>> ambiguity and potential resource management bugs.
>>>>
>>>> ==== The Problem: Implicit vs. Explicit Management ====
>>>> Historically, `pcim_enable_device()` not only manages standard PCI resources
>>>> (BARs) via devres but also implicitly triggers automatic IRQ vector management
>>>> by setting a flag that registers `pcim_msi_release()` as a cleanup action.
>>>>
>>>> This creates an ambiguous ownership model. Many drivers follow a pattern of:
>>>> 1. Calling `pci_alloc_irq_vectors()` to allocate interrupts.
>>>> 2. Also calling `pci_free_irq_vectors()` in their error paths or remove routines.
>>>>
>>>> When such a driver also uses `pcim_enable_device()`, the devres framework may
>>>> attempt to free the IRQ vectors a second time upon device release, leading to
>>>> a double-free. Analysis of the tree shows this hazardous pattern exists widely,
>>>> while 35 other drivers correctly rely solely on the implicit cleanup.
>>>
>>> Is this confirmed? What I read from the cover letter, this series was
>>> only compile-tested, so how can you prove the problem exists in the
>>> first place?
>>
>> Yes, it's confirmed. My debug of a double free issue of a out-of-tree
>> PCIe wifi driver which uses
>> pcim_enable_device + pci_alloc_irq_vectors + pci_free_irq_vectors expose
>> it. And we did have a TODO to cleanup this hybrid usage, targeted in
>> this cycle[1] suggested by Philipp:
>
> Okay, fair enough. I think this bit was missing in the cover letter.
>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=msi
>
>>>> ==== The Solution: Making Management Explicit ====
>>>> This series enforces a clear, predictable model:
>>>> 1. New Managed API (Patch 1/37): Introduces pcim_alloc_irq_vectors() and
>>>> pcim_alloc_irq_vectors_affinity(). Drivers that desire devres-managed IRQ
>>>> vectors should use these functions, which set the is_msi_managed flag and
>>>> ensure automatic cleanup.
>>>> 2. Patches 2 through 36 convert each driver that uses pcim_enable_device() alongside
>>>> pci_alloc_irq_vectors() and relies on devres for IRQ vector cleanup to instead
>>>> make an explicit call to pcim_alloc_irq_vectors().
>>>> 3. Core Change (Patch 37/37): With the former cleanup, now modifies pcim_setup_msi_release()
>>>> to check only the is_msi_managed flag. This decouples automatic IRQ cleanup from
>>>> pcim_enable_device(). IRQ vectors allocated via pci_alloc_irq_vectors*()
>>>> are now solely the driver's responsibility to free with pci_free_irq_vectors().
>>>>
>>>> With these changes, we clear ownership model: Explicit resource management eliminates
>>>> ambiguity and follows the "principle of least surprise." New drivers choose one model and
>>>> be consistent.
>>>> - Use `pci_alloc_irq_vectors()` + `pci_free_irq_vectors()` for explicit control.
>>>> - Use `pcim_alloc_irq_vectors()` for devres-managed, automatic cleanup.
>>>
>>> Have you checked previous attempts? Why is your series better than those?
>>
Thanks for sharing this 5-years-old discusstion, I totally missed it.
I read the V7 discussion, and it seems to have disappeared without much
follow-up, like a stone dropped into the ocean. For five years, newly
added drivers have continued to misuse these APIs incorrectly, and
we’ve been watching it happen. I can’t really claim this patch series
is inherently better than Dejin’s earlier work at its core, this is
just about fixing one entire category of misuse in a single pass.
According to Bjorn's final search and reply, if we include the removal
of deprecated APIs, it would require a massive amount of work and might
span many release cycles. Unfortunately, the work never began, and the
cleanup might never be completed. I’m not sure if folks have changed
their minds now. Can we at least start by completing the changes for the
pci_alloc_irq_vectors category?
>> There seems not previous attempts.
>
> Maybe we are looking to the different projects...
>
> https://lore.kernel.org/all/?q=pcim_alloc_irq_vectors
>
>>>> ==== Testing And Review ====
>>>> 1. This series is only compiled test with allmodconfig.
>>>> 2. Given the substantial size of this patch series, I have structured the mailing
>>>> to facilitate efficient review. The cover letter, the first patch and the last one will be sent
>>>> to all relevant mailing lists and key maintainers to ensure broad visibility and
>>>> initial feedback on the overall approach. The remaining subsystem-specific patches
>>>> will be sent only to the respective subsystem maintainers and their associated
>>>> mailing lists, reducing noise.
>
^ permalink raw reply
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Shawn Lin @ 2026-02-24 2:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: shawn.lin, Bjorn Helgaas, Vaibhaav Ram T . L,
Kumaravel Thiagarajan, Even Xu, Xinpeng Sun, Srinivas Pandruvada,
Jiri Kosina, Alexandre Belloni, Zhou Wang, Longfang Liu,
Vinod Koul, Lee Jones, Jijie Shao, Jian Shen, Sunil Goutham,
Andrew Lunn, Heiner Kallweit, David S . Miller, Jeff Hugo,
Oded Gabbay, Maciej Falkowski, Karol Wachowski, Min Ma, Lizhi Hou,
Andreas Noever, Mika Westerberg, Tomasz Jeznach, Will Deacon,
Xinliang Liu, Tian Tao, Davidlohr Bueso, Jonathan Cameron,
Srujana Challa, Bharat Bhushan, Antoine Tenart, Herbert Xu,
Raag Jadav, Hans de Goede, Greg Kroah-Hartman, Jiri Slaby,
Andy Shevchenko, Manivannan Sadhasivam, Mika Westerberg,
Andi Shyti, Robert Richter, Mark Brown, Nirmal Patel,
Kurt Schwemmer, Logan Gunthorpe, Linus Walleij,
Bartosz Golaszewski, Sakari Ailus, Bingbu Cao, Ulf Hansson,
Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc
In-Reply-To: <20260223160402.3ad8f079@kernel.org>
在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
>> pci device drivers which rely on the devres machinery to help cleanup the IRQ
>> vectors.
>
> If you can please add this API with just a few users, and then convert
> remaining users via the subsystem trees in the next cycle.
> There's no need to risk wasting maintainer time on conflicts with
> conversions like this.
Thanks for the suggestion, Jakub. I have little experience with
cross-subsystem cleanups like this, so your suggestion is very helpful.
>
^ permalink raw reply
* Re: Seeking help diagnosing serial port failure to transmit (while receive works)
From: Greg KH @ 2026-02-24 0:39 UTC (permalink / raw)
To: Forest; +Cc: linux-serial
In-Reply-To: <7imppktb51fdnlm8jaovts1tkhr6r1751c@sonic.net>
On Mon, Feb 23, 2026 at 03:19:03PM -0800, Forest wrote:
> Hi, folks.
>
> I'm seeing puzzling behavior from a recent AMD motherboard serial port:
> It receives data, but doesn't appear to send, and doesn't report any
> errors. Does this problem ring a bell for anyone here?
>
> dmesg reports this:
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>
> The /proc/tty/driver/serial tx count rises as I type in picocom, but the
> terminal at the other end of a null-modem cable (a laptop with a
> USB/serial adapter) doesn't see the typed characters. The other
> direction of the same connection works just fine.
>
> Things that have not helped:
> - Replacing the motherboard's cables and connectors
> - Replacing the null modem adapter with a different model
> - Replacing the remote USB/serial adapter with a different model
> - Switching picocom's flow control between RTS/CTS, xon/xoff, none
> - Changing the serial port's IRQ and address in the BIOS
> - Changing between 9600 and 115200 bps
>
> I'm approaching my wit's end. Could this be a known problem with the
> kernel's serial driver and the B650 chipset (socket AM5), or with recent
> AGESA versions?
Based on experience, it's always flow control being set somewhere (on
one side or the other), so watch out for that.
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation
From: Jakub Kicinski @ 2026-02-24 0:04 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson, Arnd Bergmann, Benjamin Tissoires,
linux-input, linux-i3c, dmaengine, Philipp Stanner, netdev,
nic_swsd, linux-arm-msm, dri-devel, linux-usb, iommu, linux-riscv,
David Airlie, Simona Vetter, linux-cxl, linux-crypto,
platform-driver-x86, linux-serial, mhi, Andy Shevchenko,
Jan Dabros, linux-i2c, Daniel Mack, Haojian Zhuang, linux-spi,
Jonathan Derrick, linux-pci, linux-gpio, Mauro Carvalho Chehab,
linux-media, linux-mmc
In-Reply-To: <1771860581-82092-2-git-send-email-shawn.lin@rock-chips.com>
On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> pci device drivers which rely on the devres machinery to help cleanup the IRQ
> vectors.
If you can please add this API with just a few users, and then convert
remaining users via the subsystem trees in the next cycle.
There's no need to risk wasting maintainer time on conflicts with
conversions like this.
^ permalink raw reply
* Seeking help diagnosing serial port failure to transmit (while receive works)
From: Forest @ 2026-02-23 23:19 UTC (permalink / raw)
To: linux-serial
Hi, folks.
I'm seeing puzzling behavior from a recent AMD motherboard serial port:
It receives data, but doesn't appear to send, and doesn't report any
errors. Does this problem ring a bell for anyone here?
dmesg reports this:
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
The /proc/tty/driver/serial tx count rises as I type in picocom, but the
terminal at the other end of a null-modem cable (a laptop with a
USB/serial adapter) doesn't see the typed characters. The other
direction of the same connection works just fine.
Things that have not helped:
- Replacing the motherboard's cables and connectors
- Replacing the null modem adapter with a different model
- Replacing the remote USB/serial adapter with a different model
- Switching picocom's flow control between RTS/CTS, xon/xoff, none
- Changing the serial port's IRQ and address in the BIOS
- Changing between 9600 and 115200 bps
I'm approaching my wit's end. Could this be a known problem with the
kernel's serial driver and the B650 chipset (socket AM5), or with recent
AGESA versions?
Thanks for your thoughts.
^ permalink raw reply
* [PATCH 37/37] PCI/MSI: Only check is_msi_managed in pcim_setup_msi_release()
From: Shawn Lin @ 2026-02-23 15:29 UTC (permalink / raw)
To: Bjorn Helgaas, Vaibhaav Ram T . L, Kumaravel Thiagarajan, Even Xu,
Xinpeng Sun, Srinivas Pandruvada, Jiri Kosina, Alexandre Belloni,
Zhou Wang, Longfang Liu, Vinod Koul, Lee Jones, Jijie Shao,
Jian Shen, Sunil Goutham, Andrew Lunn, Heiner Kallweit,
David S . Miller, Jeff Hugo, Oded Gabbay, Maciej Falkowski,
Karol Wachowski, Min Ma, Lizhi Hou, Andreas Noever,
Mika Westerberg, Tomasz Jeznach, Will Deacon, Xinliang Liu,
Tian Tao, Davidlohr Bueso, Jonathan Cameron, Srujana Challa,
Bharat Bhushan, Antoine Tenart, Herbert Xu, Raag Jadav,
Hans de Goede, Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko,
Manivannan Sadhasivam, Mika Westerberg, Andi Shyti,
Robert Richter, Mark Brown, Nirmal Patel, Kurt Schwemmer,
Logan Gunthorpe, Linus Walleij, Bartosz Golaszewski, Sakari Ailus,
Bingbu Cao, Ulf Hansson
Cc: Arnd Bergmann, Benjamin Tissoires, linux-input, linux-i3c,
dmaengine, Philipp Stanner, netdev, nic_swsd, linux-arm-msm,
dri-devel, linux-usb, iommu, linux-riscv, David Airlie,
Simona Vetter, linux-cxl, linux-crypto, platform-driver-x86,
linux-serial, mhi, Andy Shevchenko, Jan Dabros, linux-i2c,
Daniel Mack, Haojian Zhuang, linux-spi, Jonathan Derrick,
linux-pci, linux-gpio, Mauro Carvalho Chehab, linux-media,
linux-mmc, Shawn Lin
In-Reply-To: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com>
The function pcim_enable_device() sets the is_managed flag, which
causes the device's IRQ vectors to be automatically managed and released
by the devres framework. If a driver subsequently calls
pci_free_irq_vectors() manually, it can lead to a double-free of the
interrupt resources.
Analysis reveals most PCI drivers call pci_free_irq_vectors()
while also using pcim_enable_device(), making them susceptible to this
double-free issue. In contrast, 35 drivers follow the pattern of
relying on devres to handle the cleanup.
To address this inconsistency and enforce explicit, driver-managed
control of IRQ vectors, this patch removes the pci_is_managed() check
from pcim_setup_msi_release() and let devres help cleanup if is_msi_managed
is true. This change ensures that interrupt vectors are not automatically
freed by the devres machinery when pcim_enable_device() is used, placing
the responsibility for their release squarely on the driver logic via
pci_free_irq_vectors(). If the driver need devres to help cleanup, newly added
pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() helpers could be used.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---
drivers/pci/msi/msi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c
index 81d24a2..0727a0a 100644
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -70,7 +70,6 @@ static void pcim_msi_release(void *pcidev)
{
struct pci_dev *dev = pcidev;
- dev->is_msi_managed = false;
pci_free_irq_vectors(dev);
}
@@ -92,14 +91,13 @@ static int pcim_setup_msi_release(struct pci_dev *dev)
{
int ret;
- if (!pci_is_managed(dev) || dev->is_msi_managed)
+ if (!dev->is_msi_managed)
return 0;
ret = devm_add_action(&dev->dev, pcim_msi_release, dev);
if (ret)
return ret;
- dev->is_msi_managed = true;
return 0;
}
--
2.7.4
^ 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