[PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree

[PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree

[Manivannan Sadhasivam via B4 Relay]

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. I've used the M.2 card model name as the serdev device name. This is found
out by comparing the PCIe VID:PID in the notifier. Is this approach acceptable?
I did not use the PID as the serdev name since it will vary if the SDIO
interface is used in the future.

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. Until then, this series is *not* mergeable as a
whole.

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 M.2
card connected over PCIe and UART.

[1] https://lore.kernel.org/linux-pci/20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com
[2] https://github.com/Mani-Sadhasivam/linux/commit/d39b81b3ff1ecfb0d423b4da0771925d41648b5a

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Manivannan Sadhasivam (9):
      serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros
      serdev: Add serdev device based driver match support
      serdev: Allow passing the serdev device name to serdev_device_add()
      serdev: Add an API to find the serdev controller associated with the devicetree node
      serdev: Add modalias support for serdev client devices
      serdev: Skip registering serdev devices from DT is external connector is used
      dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
      Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card
      power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors

 .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++
 MAINTAINERS                                        |   1 +
 drivers/bluetooth/hci_qca.c                        |  20 ++
 drivers/platform/x86/dell/dell-uart-backlight.c    |   2 +-
 .../x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |   2 +-
 drivers/platform/x86/x86-android-tablets/core.c    |   2 +-
 drivers/power/sequencing/Kconfig                   |   1 +
 drivers/power/sequencing/pwrseq-pcie-m2.c          | 218 ++++++++++++++++++++-
 drivers/tty/serdev/core.c                          |  77 +++++++-
 include/linux/mod_devicetable.h                    |   8 +
 include/linux/serdev.h                             |  25 ++-
 scripts/mod/devicetable-offsets.c                  |   3 +
 scripts/mod/file2alias.c                           |   8 +
 13 files changed, 494 insertions(+), 27 deletions(-)
---
base-commit: db81ec30672bb228cd7cd809edeeae661d621f2d
change-id: 20251112-pci-m2-e-94695ac9d657

Best regards,
-- 
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

[PATCH 1/9] serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros

[Manivannan Sadhasivam via B4 Relay]

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.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 include/linux/serdev.h | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 34562eb99931d808e885ce5022b8aa4577566885..ab185cac556380dfa3cdf94b7af6ee168b677587 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(d, struct serdev_device, dev)
 
 /**
  * struct serdev_device_driver - serdev slave device driver
@@ -67,10 +64,7 @@ struct serdev_device_driver {
 	void	(*remove)(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(d, struct serdev_device_driver, driver)
 
 enum serdev_parity {
 	SERDEV_PARITY_NONE,

-- 
2.48.1

Re: [PATCH 1/9] serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros

[Rob Herring]

On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
>
> 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.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  include/linux/serdev.h | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> index 34562eb99931d808e885ce5022b8aa4577566885..ab185cac556380dfa3cdf94b7af6ee168b677587 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);

See container_of_const()

> -}
> +#define to_serdev_device(d) container_of(d, struct serdev_device, dev)

Re: [PATCH 1/9] serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros

[Manivannan Sadhasivam]

On Wed, Nov 12, 2025 at 03:13:54PM -0600, Rob Herring wrote:
> On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> >
> > 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.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  include/linux/serdev.h | 10 ++--------
> >  1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> > index 34562eb99931d808e885ce5022b8aa4577566885..ab185cac556380dfa3cdf94b7af6ee168b677587 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);
> 
> See container_of_const()
> 

Ah, didn't know about it. Will use it in v2.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH 2/9] serdev: Add serdev device based driver match support

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Add support to match serdev devices with serdev drivers based on the serdev
ID table defined in serdev_device_driver::id_table.

The matching function, serdev_driver_match_device() uses the serdev device
name to match against the entries in serdev_device_driver::id_table.

If there is no serdev id_table for the driver, then serdev_device_match()
will fallback to ACPI and DT based matching.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/tty/serdev/core.c         | 23 ++++++++++++++++++++++-
 include/linux/mod_devicetable.h   |  7 +++++++
 include/linux/serdev.h            |  4 ++++
 scripts/mod/devicetable-offsets.c |  3 +++
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index b33e708cb2455fc144a9fd4ac40ce9118e1a8faa..2b5582cd5063a87c9a6c99f83a8ab071637eae57 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -85,12 +85,33 @@ static const struct device_type serdev_ctrl_type = {
 	.release	= serdev_ctrl_release,
 };
 
+static int serdev_driver_match_device(struct device *dev, const struct device_driver *drv)
+{
+	const struct serdev_device_driver *serdev_drv = to_serdev_device_driver(drv);
+	struct serdev_device *serdev = to_serdev_device(dev);
+	const struct serdev_device_id *id;
+
+	if (!serdev_drv->id_table)
+		return 0;
+
+	for (id = serdev_drv->id_table; id->name[0]; id++) {
+		if (!strcmp(dev_name(dev), id->name)) {
+			serdev->id = id;
+			return 1;
+		}
+	}
+
+	return 0;
+}
+
 static int serdev_device_match(struct device *dev, const struct device_driver *drv)
 {
 	if (!is_serdev_device(dev))
 		return 0;
 
-	/* TODO: platform matching */
+	if (serdev_driver_match_device(dev, drv))
+		return 1;
+
 	if (acpi_driver_match_device(dev, drv))
 		return 1;
 
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 6077972e8b45de3d07881c0226459d815dd1f83d..70c54c4bedba2fcb8f5eb37c2d9ede05d5d91188 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -976,4 +976,11 @@ struct coreboot_device_id {
 	kernel_ulong_t driver_data;
 };
 
+#define SERDEV_NAME_SIZE 32
+
+struct serdev_device_id {
+	const char name[SERDEV_NAME_SIZE];
+	kernel_ulong_t driver_data;
+};
+
 #endif /* LINUX_MOD_DEVICETABLE_H */
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index ab185cac556380dfa3cdf94b7af6ee168b677587..ee42e293445d928a311bd3c120e609214f89a5dd 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -39,6 +39,7 @@ struct serdev_device_ops {
  * @ops:	Device operations.
  * @write_comp	Completion used by serdev_device_write() internally
  * @write_lock	Lock to serialize access when writing data
+ * @id:		serdev device ID entry
  */
 struct serdev_device {
 	struct device dev;
@@ -47,6 +48,7 @@ struct serdev_device {
 	const struct serdev_device_ops *ops;
 	struct completion write_comp;
 	struct mutex write_lock;
+	const struct serdev_device_id *id;
 };
 
 #define to_serdev_device(d) container_of(d, struct serdev_device, dev)
@@ -55,11 +57,13 @@ struct serdev_device {
  * struct serdev_device_driver - serdev slave device driver
  * @driver:	serdev device drivers should initialize name field of this
  *		structure.
+ * @id_table:	serdev device ID table
  * @probe:	binds this driver to a serdev device.
  * @remove:	unbinds this driver from the serdev device.
  */
 struct serdev_device_driver {
 	struct device_driver driver;
+	const struct serdev_device_id *id_table;
 	int	(*probe)(struct serdev_device *);
 	void	(*remove)(struct serdev_device *);
 };
diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-offsets.c
index d3d00e85edf73553ba3d9b5f9fccf1ff61c99026..c1bfa8eddc4d638c55db54cfd9b6407f47594b4c 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -280,5 +280,8 @@ int main(void)
 	DEVID(coreboot_device_id);
 	DEVID_FIELD(coreboot_device_id, tag);
 
+	DEVID(serdev_device_id);
+	DEVID_FIELD(serdev_device_id, name);
+
 	return 0;
 }

-- 
2.48.1

[PATCH 3/9] serdev: Allow passing the serdev device name to serdev_device_add()

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Instead of always setting the serdev device name from 'struct device' name,
allow the callers to pass an optional name and set it as the serdev device
name.

This will be used by the future callers passing the serdev device ID as the
name.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/platform/x86/dell/dell-uart-backlight.c             |  2 +-
 .../platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |  2 +-
 drivers/platform/x86/x86-android-tablets/core.c             |  2 +-
 drivers/tty/serdev/core.c                                   | 13 +++++++++----
 include/linux/serdev.h                                      |  2 +-
 5 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/dell/dell-uart-backlight.c b/drivers/platform/x86/dell/dell-uart-backlight.c
index f323a667dc2d2c7dec9fb284515bc3b6b984b7b9..f076cfac2bc5ec14899d6622d084bae2ffecfa3c 100644
--- a/drivers/platform/x86/dell/dell-uart-backlight.c
+++ b/drivers/platform/x86/dell/dell-uart-backlight.c
@@ -354,7 +354,7 @@ static int dell_uart_bl_pdev_probe(struct platform_device *pdev)
 	if (!serdev)
 		return -ENOMEM;
 
-	ret = serdev_device_add(serdev);
+	ret = serdev_device_add(serdev, NULL);
 	if (ret) {
 		dev_err(&pdev->dev, "error %d adding serdev\n", ret);
 		serdev_device_put(serdev);
diff --git a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
index 8551ab4d2c7dbc3a8d0b2f50071d4460a3ee65e9..5e568fe1162d1563183713f8d5c71c59ff7667a1 100644
--- a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
+++ b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
@@ -260,7 +260,7 @@ static int yt2_1380_fc_pdev_probe(struct platform_device *pdev)
 	/* The fwnode is a managed node, so it will be auto-put on serdev_device_put() */
 	fwnode_handle_get(dev_fwnode(&serdev->dev));
 
-	ret = serdev_device_add(serdev);
+	ret = serdev_device_add(serdev, NULL);
 	if (ret) {
 		serdev_device_put(serdev);
 		return dev_err_probe(&pdev->dev, ret, "adding serdev\n");
diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
index 6588fae303562b7dc9a1a8d281b167e44f0d3e84..96140f5d4f79240f44cb4530ee63777f783c6aaf 100644
--- a/drivers/platform/x86/x86-android-tablets/core.c
+++ b/drivers/platform/x86/x86-android-tablets/core.c
@@ -316,7 +316,7 @@ static __init int x86_instantiate_serdev(const struct x86_dev_info *dev_info, in
 	ACPI_COMPANION_SET(&serdev->dev, serdev_adev);
 	acpi_device_set_enumerated(serdev_adev);
 
-	ret = serdev_device_add(serdev);
+	ret = serdev_device_add(serdev, NULL);
 	if (ret) {
 		dev_err(&serdev->dev, "error %d adding serdev\n", ret);
 		serdev_device_put(serdev);
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 2b5582cd5063a87c9a6c99f83a8ab071637eae57..76b89dd0720f89dbe34e205b905ef24d9f94d770 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -121,14 +121,19 @@ static int serdev_device_match(struct device *dev, const struct device_driver *d
 /**
  * serdev_device_add() - add a device previously constructed via serdev_device_alloc()
  * @serdev:	serdev_device to be added
+ * @name:	name of the serdev device (optional)
  */
-int serdev_device_add(struct serdev_device *serdev)
+int serdev_device_add(struct serdev_device *serdev, const char *name)
+
 {
 	struct serdev_controller *ctrl = serdev->ctrl;
 	struct device *parent = serdev->dev.parent;
 	int err;
 
-	dev_set_name(&serdev->dev, "%s-%d", dev_name(parent), serdev->nr);
+	if (name)
+		dev_set_name(&serdev->dev, "%s", name);
+	else
+		dev_set_name(&serdev->dev, "%s-%d", dev_name(parent), serdev->nr);
 
 	/* Only a single slave device is currently supported. */
 	if (ctrl->serdev) {
@@ -544,7 +549,7 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
 
 		device_set_node(&serdev->dev, of_fwnode_handle(node));
 
-		err = serdev_device_add(serdev);
+		err = serdev_device_add(serdev, NULL);
 		if (err) {
 			dev_err(&serdev->dev,
 				"failure adding device. status %pe\n",
@@ -692,7 +697,7 @@ static acpi_status acpi_serdev_register_device(struct serdev_controller *ctrl,
 	ACPI_COMPANION_SET(&serdev->dev, adev);
 	acpi_device_set_enumerated(adev);
 
-	err = serdev_device_add(serdev);
+	err = serdev_device_add(serdev, NULL);
 	if (err) {
 		dev_err(&serdev->dev,
 			"failure adding ACPI serdev device. status %pe\n",
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index ee42e293445d928a311bd3c120e609214f89a5dd..3b87909b199af74d619b4fe548c5c9c994e7bc15 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -163,7 +163,7 @@ static inline void serdev_controller_put(struct serdev_controller *ctrl)
 }
 
 struct serdev_device *serdev_device_alloc(struct serdev_controller *);
-int serdev_device_add(struct serdev_device *);
+int serdev_device_add(struct serdev_device *serdev, const char *name);
 void serdev_device_remove(struct serdev_device *);
 
 struct serdev_controller *serdev_controller_alloc(struct device *host,

-- 
2.48.1

Re: [PATCH 3/9] serdev: Allow passing the serdev device name to serdev_device_add()

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 5682 bytes --]

On Wed, 12 Nov 2025, Manivannan Sadhasivam via B4 Relay wrote:

> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> Instead of always setting the serdev device name from 'struct device' name,
> allow the callers to pass an optional name and set it as the serdev device
> name.
> 
> This will be used by the future callers passing the serdev device ID as the
> name.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/platform/x86/dell/dell-uart-backlight.c             |  2 +-
>  .../platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |  2 +-
>  drivers/platform/x86/x86-android-tablets/core.c             |  2 +-
>  drivers/tty/serdev/core.c                                   | 13 +++++++++----
>  include/linux/serdev.h                                      |  2 +-
>  5 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell/dell-uart-backlight.c b/drivers/platform/x86/dell/dell-uart-backlight.c
> index f323a667dc2d2c7dec9fb284515bc3b6b984b7b9..f076cfac2bc5ec14899d6622d084bae2ffecfa3c 100644
> --- a/drivers/platform/x86/dell/dell-uart-backlight.c
> +++ b/drivers/platform/x86/dell/dell-uart-backlight.c
> @@ -354,7 +354,7 @@ static int dell_uart_bl_pdev_probe(struct platform_device *pdev)
>  	if (!serdev)
>  		return -ENOMEM;
>  
> -	ret = serdev_device_add(serdev);
> +	ret = serdev_device_add(serdev, NULL);
>  	if (ret) {
>  		dev_err(&pdev->dev, "error %d adding serdev\n", ret);
>  		serdev_device_put(serdev);
> diff --git a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
> index 8551ab4d2c7dbc3a8d0b2f50071d4460a3ee65e9..5e568fe1162d1563183713f8d5c71c59ff7667a1 100644
> --- a/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
> +++ b/drivers/platform/x86/lenovo/yoga-tab2-pro-1380-fastcharger.c
> @@ -260,7 +260,7 @@ static int yt2_1380_fc_pdev_probe(struct platform_device *pdev)
>  	/* The fwnode is a managed node, so it will be auto-put on serdev_device_put() */
>  	fwnode_handle_get(dev_fwnode(&serdev->dev));
>  
> -	ret = serdev_device_add(serdev);
> +	ret = serdev_device_add(serdev, NULL);
>  	if (ret) {
>  		serdev_device_put(serdev);
>  		return dev_err_probe(&pdev->dev, ret, "adding serdev\n");
> diff --git a/drivers/platform/x86/x86-android-tablets/core.c b/drivers/platform/x86/x86-android-tablets/core.c
> index 6588fae303562b7dc9a1a8d281b167e44f0d3e84..96140f5d4f79240f44cb4530ee63777f783c6aaf 100644
> --- a/drivers/platform/x86/x86-android-tablets/core.c
> +++ b/drivers/platform/x86/x86-android-tablets/core.c
> @@ -316,7 +316,7 @@ static __init int x86_instantiate_serdev(const struct x86_dev_info *dev_info, in
>  	ACPI_COMPANION_SET(&serdev->dev, serdev_adev);
>  	acpi_device_set_enumerated(serdev_adev);
>  
> -	ret = serdev_device_add(serdev);
> +	ret = serdev_device_add(serdev, NULL);
>  	if (ret) {
>  		dev_err(&serdev->dev, "error %d adding serdev\n", ret);
>  		serdev_device_put(serdev);
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index 2b5582cd5063a87c9a6c99f83a8ab071637eae57..76b89dd0720f89dbe34e205b905ef24d9f94d770 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -121,14 +121,19 @@ static int serdev_device_match(struct device *dev, const struct device_driver *d
>  /**
>   * serdev_device_add() - add a device previously constructed via serdev_device_alloc()
>   * @serdev:	serdev_device to be added
> + * @name:	name of the serdev device (optional)
>   */
> -int serdev_device_add(struct serdev_device *serdev)
> +int serdev_device_add(struct serdev_device *serdev, const char *name)
> +
>  {
>  	struct serdev_controller *ctrl = serdev->ctrl;
>  	struct device *parent = serdev->dev.parent;
>  	int err;
>  
> -	dev_set_name(&serdev->dev, "%s-%d", dev_name(parent), serdev->nr);
> +	if (name)
> +		dev_set_name(&serdev->dev, "%s", name);
> +	else
> +		dev_set_name(&serdev->dev, "%s-%d", dev_name(parent), serdev->nr);
>  
>  	/* Only a single slave device is currently supported. */
>  	if (ctrl->serdev) {
> @@ -544,7 +549,7 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
>  
>  		device_set_node(&serdev->dev, of_fwnode_handle(node));
>  
> -		err = serdev_device_add(serdev);
> +		err = serdev_device_add(serdev, NULL);
>  		if (err) {
>  			dev_err(&serdev->dev,
>  				"failure adding device. status %pe\n",
> @@ -692,7 +697,7 @@ static acpi_status acpi_serdev_register_device(struct serdev_controller *ctrl,
>  	ACPI_COMPANION_SET(&serdev->dev, adev);
>  	acpi_device_set_enumerated(adev);
>  
> -	err = serdev_device_add(serdev);
> +	err = serdev_device_add(serdev, NULL);
>  	if (err) {
>  		dev_err(&serdev->dev,
>  			"failure adding ACPI serdev device. status %pe\n",
> diff --git a/include/linux/serdev.h b/include/linux/serdev.h
> index ee42e293445d928a311bd3c120e609214f89a5dd..3b87909b199af74d619b4fe548c5c9c994e7bc15 100644
> --- a/include/linux/serdev.h
> +++ b/include/linux/serdev.h
> @@ -163,7 +163,7 @@ static inline void serdev_controller_put(struct serdev_controller *ctrl)
>  }
>  
>  struct serdev_device *serdev_device_alloc(struct serdev_controller *);
> -int serdev_device_add(struct serdev_device *);
> +int serdev_device_add(struct serdev_device *serdev, const char *name);
>  void serdev_device_remove(struct serdev_device *);
>  
>  struct serdev_controller *serdev_controller_alloc(struct device *host,
> 
> 

Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

[PATCH 4/9] serdev: Add an API to find the serdev controller associated with the devicetree node

[Manivannan Sadhasivam via B4 Relay]

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.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/tty/serdev/core.c | 16 ++++++++++++++++
 include/linux/serdev.h    |  9 +++++++++
 2 files changed, 25 insertions(+)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 76b89dd0720f89dbe34e205b905ef24d9f94d770..f90095cb778f2374303f98809d1639a000e0d9e0 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -530,6 +530,22 @@ struct serdev_controller *serdev_controller_alloc(struct device *host,
 }
 EXPORT_SYMBOL_GPL(serdev_controller_alloc);
 
+/**
+ * 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.
+ */
+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);
+
 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 3b87909b199af74d619b4fe548c5c9c994e7bc15..ee483f6b11b09ef4c8ad6f98718aa79afda6e826 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -340,4 +340,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
+struct serdev_controller *of_find_serdev_controller_by_node(struct device_node *node)
+{
+	return NULL;
+}
+#endif /* CONFIG_OF */
+
 #endif /*_LINUX_SERDEV_H */

-- 
2.48.1

[PATCH 5/9] serdev: Add modalias support for serdev client devices

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Add modlias support to serdev so that the serdev client driver can be
autoloaded by udev when the serdev client device gets created.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/tty/serdev/core.c       | 15 +++++++++++----
 include/linux/mod_devicetable.h |  1 +
 scripts/mod/file2alias.c        |  8 ++++++++
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index f90095cb778f2374303f98809d1639a000e0d9e0..8c2a40a537d93f4b9353a2f128cdf51b521929b1 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -34,7 +34,11 @@ static ssize_t modalias_show(struct device *dev,
 	if (len != -ENODEV)
 		return len;
 
-	return of_device_modalias(dev, buf, PAGE_SIZE);
+	len = of_device_modalias(dev, buf, PAGE_SIZE);
+	if (len != -ENODEV)
+		return len;
+
+	return sysfs_emit(buf, SERDEV_DEVICE_MODALIAS_FMT "\n", dev_name(dev));
 }
 static DEVICE_ATTR_RO(modalias);
 
@@ -48,13 +52,16 @@ static int serdev_device_uevent(const struct device *dev, struct kobj_uevent_env
 {
 	int rc;
 
-	/* TODO: platform modalias */
-
 	rc = acpi_device_uevent_modalias(dev, env);
 	if (rc != -ENODEV)
 		return rc;
 
-	return of_device_uevent_modalias(dev, env);
+	rc = of_device_uevent_modalias(dev, env);
+	if (rc != -ENODEV)
+		return rc;
+
+	return add_uevent_var(env, "MODALIAS=" SERDEV_DEVICE_MODALIAS_FMT,
+					dev_name(dev));
 }
 
 static void serdev_device_release(struct device *dev)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 70c54c4bedba2fcb8f5eb37c2d9ede05d5d91188..dad9637cf28552c3423affc4eb249efa6ba05514 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -976,6 +976,7 @@ struct coreboot_device_id {
 	kernel_ulong_t driver_data;
 };
 
+#define SERDEV_DEVICE_MODALIAS_FMT "serdev:%s"
 #define SERDEV_NAME_SIZE 32
 
 struct serdev_device_id {
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index b3333560b95ee998fbe5bdc9ed380847962d1bd1..27e9f7c718c4d48ca5dbd5538490529119df9509 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1371,6 +1371,13 @@ static void do_coreboot_entry(struct module *mod, void *symval)
 	module_alias_printf(mod, false, "coreboot:t%08X", tag);
 }
 
+/* Looks like: serdev:S */
+static void do_serdev_entry(struct module *mod, void *symval)
+{
+	DEF_FIELD_ADDR(symval, serdev_device_id, name);
+	module_alias_printf(mod, false, SERDEV_DEVICE_MODALIAS_FMT, *name);
+}
+
 /* Does namelen bytes of name exactly match the symbol? */
 static bool sym_is(const char *name, unsigned namelen, const char *symbol)
 {
@@ -1467,6 +1474,7 @@ static const struct devtable devtable[] = {
 	{"usb", SIZE_usb_device_id, do_usb_entry_multi},
 	{"pnp", SIZE_pnp_device_id, do_pnp_device_entry},
 	{"pnp_card", SIZE_pnp_card_device_id, do_pnp_card_entry},
+	{"serdev", SIZE_serdev_device_id, do_serdev_entry},
 };
 
 /* Create MODULE_ALIAS() statements.

-- 
2.48.1

[PATCH 6/9] serdev: Skip registering serdev devices from DT is external connector is used

[Manivannan Sadhasivam via B4 Relay]

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 will be created dynamically by the connector
driver. So skip registering devices from DT node as there will be no
statically defined devices.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/tty/serdev/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 8c2a40a537d93f4b9353a2f128cdf51b521929b1..1378587d386356ca4415fa455b2ee722b5e44d3e 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>
@@ -560,6 +561,15 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
 	int err;
 	bool found = false;
 
+	/*
+	 * When the serdev controller is connected to an external connector like
+	 * M.2 in DT, then the serdev devices will be created dynamically by the
+	 * connector driver. So skip looking for devices in DT node as there will
+	 * be no statically defined devices.
+	 */
+	if (of_graph_is_present(ctrl->dev.of_node))
+		return 0;
+
 	for_each_available_child_of_node(ctrl->dev.of_node, node) {
 		if (!of_property_present(node, "compatible"))
 			continue;

-- 
2.48.1

Re: [PATCH 6/9] serdev: Skip registering serdev devices from DT is external connector is used

[Rob Herring]

On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
>
> 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 will be created dynamically by the connector
> driver. So skip registering devices from DT node as there will be no
> statically defined devices.

You could still have statically defined devices. You are just choosing
to probe them later from the connector driver.

>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/tty/serdev/core.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index 8c2a40a537d93f4b9353a2f128cdf51b521929b1..1378587d386356ca4415fa455b2ee722b5e44d3e 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>
> @@ -560,6 +561,15 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
>         int err;
>         bool found = false;
>
> +       /*
> +        * When the serdev controller is connected to an external connector like
> +        * M.2 in DT, then the serdev devices will be created dynamically by the
> +        * connector driver. So skip looking for devices in DT node as there will
> +        * be no statically defined devices.
> +        */
> +       if (of_graph_is_present(ctrl->dev.of_node))
> +               return 0;

Where's the schema that allows graph nodes?

Rob

Re: [PATCH 6/9] serdev: Skip registering serdev devices from DT is external connector is used

[Manivannan Sadhasivam]

On Tue, Nov 18, 2025 at 07:03:51AM -0600, Rob Herring wrote:
> On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> >
> > 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 will be created dynamically by the connector
> > driver. So skip registering devices from DT node as there will be no
> > statically defined devices.
> 
> You could still have statically defined devices. You are just choosing
> to probe them later from the connector driver.
> 

The point of coming up with the M.2 binding is to avoid hardcoding the devices
in DT. So static devices are ruled out IMO.

> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  drivers/tty/serdev/core.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> > index 8c2a40a537d93f4b9353a2f128cdf51b521929b1..1378587d386356ca4415fa455b2ee722b5e44d3e 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>
> > @@ -560,6 +561,15 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
> >         int err;
> >         bool found = false;
> >
> > +       /*
> > +        * When the serdev controller is connected to an external connector like
> > +        * M.2 in DT, then the serdev devices will be created dynamically by the
> > +        * connector driver. So skip looking for devices in DT node as there will
> > +        * be no statically defined devices.
> > +        */
> > +       if (of_graph_is_present(ctrl->dev.of_node))
> > +               return 0;
> 
> Where's the schema that allows graph nodes?
> 

Err... I missed updating it. Will do it in v2.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 6/9] serdev: Skip registering serdev devices from DT is external connector is used

[Rob Herring]

On Wed, Nov 19, 2025 at 7:33 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Tue, Nov 18, 2025 at 07:03:51AM -0600, Rob Herring wrote:
> > On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
> > <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> > >
> > > 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 will be created dynamically by the connector
> > > driver. So skip registering devices from DT node as there will be no
> > > statically defined devices.
> >
> > You could still have statically defined devices. You are just choosing
> > to probe them later from the connector driver.
> >
>
> The point of coming up with the M.2 binding is to avoid hardcoding the devices
> in DT. So static devices are ruled out IMO.

Until you have any one of the reasons we have PCIe devices described
even when in a standard slot. Take your pick. An ethernet adapter that
omits an EEPROM for the MAC address.

Rob

Re: [PATCH 6/9] serdev: Skip registering serdev devices from DT is external connector is used

[Manivannan Sadhasivam]

On Thu, Nov 20, 2025 at 10:22:16AM -0600, Rob Herring wrote:
> On Wed, Nov 19, 2025 at 7:33 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Tue, Nov 18, 2025 at 07:03:51AM -0600, Rob Herring wrote:
> > > On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
> > > <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> > > >
> > > > 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 will be created dynamically by the connector
> > > > driver. So skip registering devices from DT node as there will be no
> > > > statically defined devices.
> > >
> > > You could still have statically defined devices. You are just choosing
> > > to probe them later from the connector driver.
> > >
> >
> > The point of coming up with the M.2 binding is to avoid hardcoding the devices
> > in DT. So static devices are ruled out IMO.
> 
> Until you have any one of the reasons we have PCIe devices described
> even when in a standard slot. Take your pick. An ethernet adapter that
> omits an EEPROM for the MAC address.
> 

Hmm, I didn't envision the need to have static and dynamic devices at the same
time. So you are suggesting to first look for the static devices and then look
for graph port at the end?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Manivannan Sadhasivam via B4 Relay]

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 along with additional interfaces like I2C for NFC solution. At any
point of time, the connector can only support either PCIe or SDIO as the
WiFi interface and USB or UART as the BT interface.

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.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
 MAINTAINERS                                        |   1 +
 2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -0,0 +1,154 @@
+# 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.
+
+  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/SDIO interface
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: USB 2.0/UART interface
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: PCM/I2S interface
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: I2C interface
+
+    oneOf:
+      - required:
+          - port@0
+
+  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 controlled connection to W_DISABLE1# signal. This signal
+      is used by the 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 controlled connection to W_DISABLE2# signal. This signal
+      is used by the system to disable BT radio in the M.2 card. Refer, PCI
+      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
+    maxItems: 1
+
+  led1-gpios:
+    description: GPIO controlled connection to LED_1# signal. This signal is
+      used by the M.2 card to indicate the card status via the system mounted
+      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
+      details.
+    maxItems: 1
+
+  led2-gpios:
+    description: GPIO controlled connection to LED_2# signal. This signal is
+      used by the M.2 card to indicate the card status via the system mounted
+      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
+      details.
+    maxItems: 1
+
+  viocfg-gpios:
+    description: GPIO controlled connection to IO voltage configuration
+      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
+      host system that the card supports an independent IO voltage domain for
+      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
+      3.1.15.1 for more details.
+    maxItems: 1
+
+  uim_power_src-gpios:
+    description: GPIO controlled connection to UIM_POWER_SRC signal. This signal
+      is used when the NFC solution is implemented and receives the power output
+      from WWAN_UIM_PWR signal of the another WWAN M.2 card. Refer, PCI Express
+      M.2 Specification r4.0, sec 3.1.11.1 for more details.
+    maxItems: 1
+
+  uim_power_snk-gpios:
+    description: GPIO controlled connection to UIM_POWER_SNK signal. This signal
+      is used when the NFC solution is implemented and supplies power to the
+      Universal Integrated Circuit Card (UICC). Refer, PCI Express M.2
+      Specification r4.0, sec 3.1.11.2 for more details.
+    maxItems: 1
+
+  uim_swp-gpios:
+    description: GPIO controlled connection to UIM_SWP signal. This signal is
+      used when the NFC solution is implemented and implements the Single Wire
+      Protocol (SWP) interface to the UICC. Refer, PCI Express M.2 Specification
+      r4.0, sec 3.1.11.3 for more details.
+    maxItems: 1
+
+required:
+  - compatible
+  - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+  # PCI M.2 Key E connector for WLAN/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>;
+        w_disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
+        w_disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+
+                endpoint {
+                    remote-endpoint = <&pcie4_port0_ep>;
+                };
+            };
+
+            port@3 {
+                reg = <3>;
+
+                endpoint {
+                    remote-endpoint = <&uart14_ep>;
+                };
+            };
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b3f689d1f50c62afa3772a0c6802f99a98ac2de..f707f29d0a37f344d8dd061b7e49dbb807933c9f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20478,6 +20478,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.48.1

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Frank Li]

On Wed, Nov 12, 2025 at 08:15:19PM +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 along with additional interfaces like I2C for NFC solution. At any
> point of time, the connector can only support either PCIe or SDIO as the
> WiFi interface and USB or UART as the BT interface.
>
> 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.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
>  MAINTAINERS                                        |   1 +
>  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -0,0 +1,154 @@
> +# 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.
> +
> +  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/SDIO interface


PCIe and SDIO is difference signal at key E. why combine to one port? The
similar case is USB2.0/UART

> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: USB 2.0/UART interface
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: PCM/I2S interface
> +
> +      port@3:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: I2C interface
> +
> +    oneOf:
> +      - required:
> +          - port@0
> +
> +  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

Do we need add pciref clock here?

> +
> +  w_disable1-gpios:

use "-"

w-disable1-gpios

> +    description: GPIO controlled connection to W_DISABLE1# signal. This signal
> +      is used by the 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 controlled connection to W_DISABLE2# signal. This signal
> +      is used by the system to disable BT radio in the M.2 card. Refer, PCI
> +      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
> +    maxItems: 1
> +
> +  led1-gpios:
> +    description: GPIO controlled connection to LED_1# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  led2-gpios:
> +    description: GPIO controlled connection to LED_2# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  viocfg-gpios:
> +    description: GPIO controlled connection to IO voltage configuration
> +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> +      host system that the card supports an independent IO voltage domain for
> +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> +      3.1.15.1 for more details.
> +    maxItems: 1
> +
> +  uim_power_src-gpios:

property use -

Frank
> +    description: GPIO controlled connection to UIM_POWER_SRC signal. This signal
> +      is used when the NFC solution is implemented and receives the power output
> +      from WWAN_UIM_PWR signal of the another WWAN M.2 card. Refer, PCI Express
> +      M.2 Specification r4.0, sec 3.1.11.1 for more details.
> +    maxItems: 1
> +
> +  uim_power_snk-gpios:
> +    description: GPIO controlled connection to UIM_POWER_SNK signal. This signal
> +      is used when the NFC solution is implemented and supplies power to the
> +      Universal Integrated Circuit Card (UICC). Refer, PCI Express M.2
> +      Specification r4.0, sec 3.1.11.2 for more details.
> +    maxItems: 1
> +
> +  uim_swp-gpios:
> +    description: GPIO controlled connection to UIM_SWP signal. This signal is
> +      used when the NFC solution is implemented and implements the Single Wire
> +      Protocol (SWP) interface to the UICC. Refer, PCI Express M.2 Specification
> +      r4.0, sec 3.1.11.3 for more details.
> +    maxItems: i1
> +
> +required:
> +  - compatible
> +  - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  # PCI M.2 Key E connector for WLAN/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>;
> +        w_disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> +        w_disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                endpoint {
> +                    remote-endpoint = <&pcie4_port0_ep>;
> +                };
> +            };
> +
> +            port@3 {
> +                reg = <3>;
> +
> +                endpoint {
> +                    remote-endpoint = <&uart14_ep>;
> +                };
> +            };
> +        };
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9b3f689d1f50c62afa3772a0c6802f99a98ac2de..f707f29d0a37f344d8dd061b7e49dbb807933c9f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20478,6 +20478,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.48.1
>

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Manivannan Sadhasivam]

On Wed, Nov 12, 2025 at 12:11:56PM -0500, Frank Li wrote:
> On Wed, Nov 12, 2025 at 08:15:19PM +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 along with additional interfaces like I2C for NFC solution. At any
> > point of time, the connector can only support either PCIe or SDIO as the
> > WiFi interface and USB or UART as the BT interface.
> >
> > 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.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
> >  MAINTAINERS                                        |   1 +
> >  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > @@ -0,0 +1,154 @@
> > +# 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.
> > +
> > +  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/SDIO interface
> 
> 
> PCIe and SDIO is difference signal at key E. why combine to one port? The
> similar case is USB2.0/UART
> 

They will be defined as separate endpoints in the next version.

> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: USB 2.0/UART interface
> > +
> > +      port@2:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: PCM/I2S interface
> > +
> > +      port@3:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: I2C interface
> > +
> > +    oneOf:
> > +      - required:
> > +          - port@0
> > +
> > +  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
> 
> Do we need add pciref clock here?
> 
> > +
> > +  w_disable1-gpios:
> 
> use "-"
> 
> w-disable1-gpios
> 

I just went with the spec that defines the signal as W_DISABLE.

> > +    description: GPIO controlled connection to W_DISABLE1# signal. This signal
> > +      is used by the 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 controlled connection to W_DISABLE2# signal. This signal
> > +      is used by the system to disable BT radio in the M.2 card. Refer, PCI
> > +      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
> > +    maxItems: 1
> > +
> > +  led1-gpios:
> > +    description: GPIO controlled connection to LED_1# signal. This signal is
> > +      used by the M.2 card to indicate the card status via the system mounted
> > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > +      details.
> > +    maxItems: 1
> > +
> > +  led2-gpios:
> > +    description: GPIO controlled connection to LED_2# signal. This signal is
> > +      used by the M.2 card to indicate the card status via the system mounted
> > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > +      details.
> > +    maxItems: 1
> > +
> > +  viocfg-gpios:
> > +    description: GPIO controlled connection to IO voltage configuration
> > +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> > +      host system that the card supports an independent IO voltage domain for
> > +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> > +      3.1.15.1 for more details.
> > +    maxItems: 1
> > +
> > +  uim_power_src-gpios:
> 
> property use -
> 

Again, this is as per the spec. If DT maintainers object to it, I'll change it.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Rob Herring]

On Thu, Nov 13, 2025 at 10:30:42AM +0530, Manivannan Sadhasivam wrote:
> On Wed, Nov 12, 2025 at 12:11:56PM -0500, Frank Li wrote:
> > On Wed, Nov 12, 2025 at 08:15:19PM +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 along with additional interfaces like I2C for NFC solution. At any
> > > point of time, the connector can only support either PCIe or SDIO as the
> > > WiFi interface and USB or UART as the BT interface.
> > >
> > > 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.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > ---
> > >  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
> > >  MAINTAINERS                                        |   1 +
> > >  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > @@ -0,0 +1,154 @@
> > > +# 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.
> > > +
> > > +  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/SDIO interface
> > 
> > 
> > PCIe and SDIO is difference signal at key E. why combine to one port? The
> > similar case is USB2.0/UART
> > 
> 
> They will be defined as separate endpoints in the next version.
> 
> > > +
> > > +      port@1:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: USB 2.0/UART interface
> > > +
> > > +      port@2:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: PCM/I2S interface
> > > +
> > > +      port@3:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: I2C interface
> > > +
> > > +    oneOf:
> > > +      - required:
> > > +          - port@0
> > > +
> > > +  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
> > 
> > Do we need add pciref clock here?
> > 
> > > +
> > > +  w_disable1-gpios:
> > 
> > use "-"
> > 
> > w-disable1-gpios
> > 
> 
> I just went with the spec that defines the signal as W_DISABLE.
> 
> > > +    description: GPIO controlled connection to W_DISABLE1# signal. This signal
> > > +      is used by the 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 controlled connection to W_DISABLE2# signal. This signal
> > > +      is used by the system to disable BT radio in the M.2 card. Refer, PCI
> > > +      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
> > > +    maxItems: 1
> > > +
> > > +  led1-gpios:
> > > +    description: GPIO controlled connection to LED_1# signal. This signal is
> > > +      used by the M.2 card to indicate the card status via the system mounted
> > > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > > +      details.
> > > +    maxItems: 1
> > > +
> > > +  led2-gpios:
> > > +    description: GPIO controlled connection to LED_2# signal. This signal is
> > > +      used by the M.2 card to indicate the card status via the system mounted
> > > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > > +      details.
> > > +    maxItems: 1
> > > +
> > > +  viocfg-gpios:
> > > +    description: GPIO controlled connection to IO voltage configuration
> > > +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> > > +      host system that the card supports an independent IO voltage domain for
> > > +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> > > +      3.1.15.1 for more details.
> > > +    maxItems: 1
> > > +
> > > +  uim_power_src-gpios:
> > 
> > property use -
> > 
> 
> Again, this is as per the spec. If DT maintainers object to it, I'll change it.

Use '-'.

Rob

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Manivannan Sadhasivam]

On Wed, Nov 19, 2025 at 05:59:05PM -0600, Rob Herring wrote:
> On Thu, Nov 13, 2025 at 10:30:42AM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Nov 12, 2025 at 12:11:56PM -0500, Frank Li wrote:
> > > On Wed, Nov 12, 2025 at 08:15:19PM +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 along with additional interfaces like I2C for NFC solution. At any
> > > > point of time, the connector can only support either PCIe or SDIO as the
> > > > WiFi interface and USB or UART as the BT interface.
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > ---
> > > >  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
> > > >  MAINTAINERS                                        |   1 +
> > > >  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > > > @@ -0,0 +1,154 @@
> > > > +# 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.
> > > > +
> > > > +  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/SDIO interface
> > > 
> > > 
> > > PCIe and SDIO is difference signal at key E. why combine to one port? The
> > > similar case is USB2.0/UART
> > > 
> > 
> > They will be defined as separate endpoints in the next version.
> > 
> > > > +
> > > > +      port@1:
> > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > +        description: USB 2.0/UART interface
> > > > +
> > > > +      port@2:
> > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > +        description: PCM/I2S interface
> > > > +
> > > > +      port@3:
> > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > +        description: I2C interface
> > > > +
> > > > +    oneOf:
> > > > +      - required:
> > > > +          - port@0
> > > > +
> > > > +  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
> > > 
> > > Do we need add pciref clock here?
> > > 
> > > > +
> > > > +  w_disable1-gpios:
> > > 
> > > use "-"
> > > 
> > > w-disable1-gpios
> > > 
> > 
> > I just went with the spec that defines the signal as W_DISABLE.
> > 
> > > > +    description: GPIO controlled connection to W_DISABLE1# signal. This signal
> > > > +      is used by the 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 controlled connection to W_DISABLE2# signal. This signal
> > > > +      is used by the system to disable BT radio in the M.2 card. Refer, PCI
> > > > +      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
> > > > +    maxItems: 1
> > > > +
> > > > +  led1-gpios:
> > > > +    description: GPIO controlled connection to LED_1# signal. This signal is
> > > > +      used by the M.2 card to indicate the card status via the system mounted
> > > > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > > > +      details.
> > > > +    maxItems: 1
> > > > +
> > > > +  led2-gpios:
> > > > +    description: GPIO controlled connection to LED_2# signal. This signal is
> > > > +      used by the M.2 card to indicate the card status via the system mounted
> > > > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > > > +      details.
> > > > +    maxItems: 1
> > > > +
> > > > +  viocfg-gpios:
> > > > +    description: GPIO controlled connection to IO voltage configuration
> > > > +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> > > > +      host system that the card supports an independent IO voltage domain for
> > > > +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> > > > +      3.1.15.1 for more details.
> > > > +    maxItems: 1
> > > > +
> > > > +  uim_power_src-gpios:
> > > 
> > > property use -
> > > 
> > 
> > Again, this is as per the spec. If DT maintainers object to it, I'll change it.
> 
> Use '-'.
> 

OK!

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Dmitry Baryshkov]

On Wed, Nov 12, 2025 at 08:15:19PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 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 along with additional interfaces like I2C for NFC solution. At any
> point of time, the connector can only support either PCIe or SDIO as the
> WiFi interface and USB or UART as the BT interface.
> 
> 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.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
>  MAINTAINERS                                        |   1 +
>  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> @@ -0,0 +1,154 @@
> +# 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.
> +
> +  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/SDIO interface

The same comment as for the M-key bindings: please describe endpoints.

> +  led1-gpios:
> +    description: GPIO controlled connection to LED_1# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.

How are we supposed to handle these LEDs? I have been assuming that
these pins should go striaght to the LED driver.

> +    maxItems: 1
> +
> +  led2-gpios:
> +    description: GPIO controlled connection to LED_2# signal. This signal is
> +      used by the M.2 card to indicate the card status via the system mounted
> +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> +      details.
> +    maxItems: 1
> +
> +  viocfg-gpios:
> +    description: GPIO controlled connection to IO voltage configuration
> +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> +      host system that the card supports an independent IO voltage domain for
> +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> +      3.1.15.1 for more details.
> +    maxItems: 1

This more looks like viocfg-supply. Looking at this one and several
other pins, it's more like a GPIO controller, providing those pins for
the system, rather than a GPIO consumer.

> +
> +  uim_power_src-gpios:
> +    description: GPIO controlled connection to UIM_POWER_SRC signal. This signal
> +      is used when the NFC solution is implemented and receives the power output
> +      from WWAN_UIM_PWR signal of the another WWAN M.2 card. Refer, PCI Express
> +      M.2 Specification r4.0, sec 3.1.11.1 for more details.
> +    maxItems: 1
> +
> +  uim_power_snk-gpios:
> +    description: GPIO controlled connection to UIM_POWER_SNK signal. This signal
> +      is used when the NFC solution is implemented and supplies power to the
> +      Universal Integrated Circuit Card (UICC). Refer, PCI Express M.2
> +      Specification r4.0, sec 3.1.11.2 for more details.
> +    maxItems: 1
> +
> +  uim_swp-gpios:
> +    description: GPIO controlled connection to UIM_SWP signal. This signal is
> +      used when the NFC solution is implemented and implements the Single Wire
> +      Protocol (SWP) interface to the UICC. Refer, PCI Express M.2 Specification
> +      r4.0, sec 3.1.11.3 for more details.
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - vpcie3v3-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  # PCI M.2 Key E connector for WLAN/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>;
> +        w_disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> +        w_disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +
> +                endpoint {
> +                    remote-endpoint = <&pcie4_port0_ep>;
> +                };
> +            };
> +
> +            port@3 {
> +                reg = <3>;
> +
> +                endpoint {
> +                    remote-endpoint = <&uart14_ep>;
> +                };
> +            };
> +        };
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9b3f689d1f50c62afa3772a0c6802f99a98ac2de..f707f29d0a37f344d8dd061b7e49dbb807933c9f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20478,6 +20478,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.48.1
> 
> 

-- 
With best wishes
Dmitry

Re: [PATCH 7/9] dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector

[Manivannan Sadhasivam]

On Wed, Nov 12, 2025 at 10:08:57PM +0200, Dmitry Baryshkov wrote:
> On Wed, Nov 12, 2025 at 08:15:19PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > 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 along with additional interfaces like I2C for NFC solution. At any
> > point of time, the connector can only support either PCIe or SDIO as the
> > WiFi interface and USB or UART as the BT interface.
> > 
> > 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.
> > 
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++++++++
> >  MAINTAINERS                                        |   1 +
> >  2 files changed, 155 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 0000000000000000000000000000000000000000..91cb56b1a75b7e3de3b9fe9a7537089f96875746
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
> > @@ -0,0 +1,154 @@
> > +# 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.
> > +
> > +  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/SDIO interface
> 
> The same comment as for the M-key bindings: please describe endpoints.
> 

Sure.

> > +  led1-gpios:
> > +    description: GPIO controlled connection to LED_1# signal. This signal is
> > +      used by the M.2 card to indicate the card status via the system mounted
> > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > +      details.
> 
> How are we supposed to handle these LEDs? I have been assuming that
> these pins should go striaght to the LED driver.
> 

Yes. I should just drop these.

> > +    maxItems: 1
> > +
> > +  led2-gpios:
> > +    description: GPIO controlled connection to LED_2# signal. This signal is
> > +      used by the M.2 card to indicate the card status via the system mounted
> > +      LED. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.2 for more
> > +      details.
> > +    maxItems: 1
> > +
> > +  viocfg-gpios:
> > +    description: GPIO controlled connection to IO voltage configuration
> > +      (VIO_CFG) signal. This signal is used by the M.2 card to indicate to the
> > +      host system that the card supports an independent IO voltage domain for
> > +      the sideband signals. Refer, PCI Express M.2 Specification r4.0, sec
> > +      3.1.15.1 for more details.
> > +    maxItems: 1
> 
> This more looks like viocfg-supply. Looking at this one and several
> other pins, it's more like a GPIO controller, providing those pins for
> the system, rather than a GPIO consumer.
> 

It is not a supply, but rather an indicator to the host. If it is low, then it
indicates that the card supports 3.3V on the sideband IO signals.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH 8/9] Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card

[Manivannan Sadhasivam via B4 Relay]

From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

The WCN7850 PCIe M.2 card connected to the UART controller exposes the
'WCN7850' serdev device and is controlled using the pwrseq framework.

Hence, add support for it in the driver. It reuses the existing
'qca_soc_data_wcn7850' driver data.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/bluetooth/hci_qca.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4cff4d9be3132561ee9bae4ddf2c8ac0bc13ecd7..09bfb3bba93698f496947775bf6b31f2f20279f1 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>
@@ -2344,6 +2345,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
 
 	qcadev->serdev_hu.serdev = serdev;
 	data = device_get_match_data(&serdev->dev);
+	if (!data && serdev->id)
+		data = (const struct qca_device_data *) serdev->id->driver_data;
+
 	serdev_device_set_drvdata(serdev, qcadev);
 	device_property_read_string_array(&serdev->dev, "firmware-name",
 					 qcadev->firmware_name, ARRAY_SIZE(qcadev->firmware_name));
@@ -2384,6 +2388,15 @@ 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))
+				qcadev->bt_power->pwrseq = NULL;
+			else
+				break;
+		}
+
 		if (!device_property_present(&serdev->dev, "enable-gpios")) {
 			/*
 			 * Backward compatibility with old DT sources. If the
@@ -2740,6 +2753,12 @@ static const struct acpi_device_id qca_bluetooth_acpi_match[] = {
 MODULE_DEVICE_TABLE(acpi, qca_bluetooth_acpi_match);
 #endif
 
+static const struct serdev_device_id qca_bluetooth_serdev_match[] = {
+	{ "WCN7850", (kernel_ulong_t)&qca_soc_data_wcn7850 },
+	{ },
+};
+MODULE_DEVICE_TABLE(serdev, qca_bluetooth_serdev_match);
+
 #ifdef CONFIG_DEV_COREDUMP
 static void hciqca_coredump(struct device *dev)
 {
@@ -2756,6 +2775,7 @@ static void hciqca_coredump(struct device *dev)
 static struct serdev_device_driver qca_serdev_driver = {
 	.probe = qca_serdev_probe,
 	.remove = qca_serdev_remove,
+	.id_table = qca_bluetooth_serdev_match,
 	.driver = {
 		.name = "hci_uart_qca",
 		.of_match_table = of_match_ptr(qca_bluetooth_of_match),

-- 
2.48.1

Re: [PATCH 8/9] Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card

[Bartosz Golaszewski]

On Wed, Nov 12, 2025 at 3:45 PM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> The WCN7850 PCIe M.2 card connected to the UART controller exposes the
> 'WCN7850' serdev device and is controlled using the pwrseq framework.
>
> Hence, add support for it in the driver. It reuses the existing
> 'qca_soc_data_wcn7850' driver data.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/bluetooth/hci_qca.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 4cff4d9be3132561ee9bae4ddf2c8ac0bc13ecd7..09bfb3bba93698f496947775bf6b31f2f20279f1 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>
> @@ -2344,6 +2345,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
>
>         qcadev->serdev_hu.serdev = serdev;
>         data = device_get_match_data(&serdev->dev);
> +       if (!data && serdev->id)
> +               data = (const struct qca_device_data *) serdev->id->driver_data;
> +
>         serdev_device_set_drvdata(serdev, qcadev);
>         device_property_read_string_array(&serdev->dev, "firmware-name",
>                                          qcadev->firmware_name, ARRAY_SIZE(qcadev->firmware_name));
> @@ -2384,6 +2388,15 @@ 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))
> +                               qcadev->bt_power->pwrseq = NULL;
> +                       else
> +                               break;
> +               }

Did you by any chance copy this logic from commit: db0ff7e15923
("driver: bluetooth: hci_qca:fix unable to load the BT driver")? This
commit is wrong and it flew under my radar during the summer and I
never got around to fixing it. It doesn't take into account probe
deferral.

Bartosz

> +
>                 if (!device_property_present(&serdev->dev, "enable-gpios")) {
>                         /*
>                          * Backward compatibility with old DT sources. If the
> @@ -2740,6 +2753,12 @@ static const struct acpi_device_id qca_bluetooth_acpi_match[] = {
>  MODULE_DEVICE_TABLE(acpi, qca_bluetooth_acpi_match);
>  #endif
>
> +static const struct serdev_device_id qca_bluetooth_serdev_match[] = {
> +       { "WCN7850", (kernel_ulong_t)&qca_soc_data_wcn7850 },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(serdev, qca_bluetooth_serdev_match);
> +
>  #ifdef CONFIG_DEV_COREDUMP
>  static void hciqca_coredump(struct device *dev)
>  {
> @@ -2756,6 +2775,7 @@ static void hciqca_coredump(struct device *dev)
>  static struct serdev_device_driver qca_serdev_driver = {
>         .probe = qca_serdev_probe,
>         .remove = qca_serdev_remove,
> +       .id_table = qca_bluetooth_serdev_match,
>         .driver = {
>                 .name = "hci_uart_qca",
>                 .of_match_table = of_match_ptr(qca_bluetooth_of_match),
>
> --
> 2.48.1
>
>

Re: [PATCH 8/9] Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card

[Manivannan Sadhasivam]

On Tue, Nov 18, 2025 at 03:29:49PM +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 12, 2025 at 3:45 PM Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> >
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> >
> > The WCN7850 PCIe M.2 card connected to the UART controller exposes the
> > 'WCN7850' serdev device and is controlled using the pwrseq framework.
> >
> > Hence, add support for it in the driver. It reuses the existing
> > 'qca_soc_data_wcn7850' driver data.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  drivers/bluetooth/hci_qca.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index 4cff4d9be3132561ee9bae4ddf2c8ac0bc13ecd7..09bfb3bba93698f496947775bf6b31f2f20279f1 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>
> > @@ -2344,6 +2345,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> >
> >         qcadev->serdev_hu.serdev = serdev;
> >         data = device_get_match_data(&serdev->dev);
> > +       if (!data && serdev->id)
> > +               data = (const struct qca_device_data *) serdev->id->driver_data;
> > +
> >         serdev_device_set_drvdata(serdev, qcadev);
> >         device_property_read_string_array(&serdev->dev, "firmware-name",
> >                                          qcadev->firmware_name, ARRAY_SIZE(qcadev->firmware_name));
> > @@ -2384,6 +2388,15 @@ 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))
> > +                               qcadev->bt_power->pwrseq = NULL;
> > +                       else
> > +                               break;
> > +               }
> 
> Did you by any chance copy this logic from commit: db0ff7e15923
> ("driver: bluetooth: hci_qca:fix unable to load the BT driver")? This
> commit is wrong and it flew under my radar during the summer and I
> never got around to fixing it. It doesn't take into account probe
> deferral.
> 

Ah, yes. I think there is no point in continuing if devm_pwrseq_get() errors
out.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH 9/9] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors

[Manivannan Sadhasivam via B4 Relay]

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.

For supporting Bluetooth over the non-discoverable UART interface, the
driver currently creates the serdev interface 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.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/power/sequencing/Kconfig          |   1 +
 drivers/power/sequencing/pwrseq-pcie-m2.c | 218 +++++++++++++++++++++++++++++-
 2 files changed, 213 insertions(+), 6 deletions(-)

diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index f5fff84566ba463b55d3cd0c07db34c82f9f1e31..29bd204319cc1636fb424f2916d7f570af905b54 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -38,6 +38,7 @@ 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
 	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 15659b009fb3e01227e40f26d633f675bc2af701..4b5adb3f731cd5e0f69344868f88329ceba70539 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -5,14 +5,17 @@
  */
 
 #include <linux/device.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/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 {
@@ -25,17 +28,20 @@ struct pwrseq_pcie_m2_ctx {
 	const struct pwrseq_pcie_m2_pdata *pdata;
 	struct regulator_bulk_data *regs;
 	size_t num_vregs;
+	struct gpio_desc *w_disable1_gpio;
+	struct gpio_desc *w_disable2_gpio;
 	struct notifier_block nb;
+	struct device *dev;
 };
 
-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);
 
@@ -44,18 +50,92 @@ 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);
+
+	gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);
+
+	return 0;
+}
+
+static int pwrseq_pci_m2_e_uart_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	gpiod_set_value_cansleep(ctx->w_disable2_gpio, 1);
+
+	return 0;
+}
+
+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);
+
+	gpiod_set_value_cansleep(ctx->w_disable1_gpio, 0);
+
+	return 0;
+}
+
+static int pwrseq_pci_m2_e_pcie_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	gpiod_set_value_cansleep(ctx->w_disable1_gpio, 1);
+
+	return 0;
+}
+
+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 = {
@@ -63,11 +143,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,
 };
@@ -95,6 +185,102 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
 	return PWRSEQ_NO_MATCH;
 }
 
+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 device_node *remote;
+	struct serdev_controller *serdev_ctrl;
+	struct serdev_device *serdev;
+	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.
+	 */
+	remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 0, -1);
+	if (!remote || (remote != pdev->dev.parent->of_node)) {
+		of_node_put(remote);
+		return NOTIFY_DONE;
+	}
+	of_node_put(remote);
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		/* Create serdev device for WCN7850 */
+		if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
+			remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 1, -1);
+			if (!remote) {
+				of_node_put(remote);
+				return NOTIFY_DONE;
+			}
+
+			serdev_ctrl = of_find_serdev_controller_by_node(remote);
+			of_node_put(remote);
+			if (!serdev_ctrl)
+				return NOTIFY_DONE;
+
+			serdev = serdev_device_alloc(serdev_ctrl);
+			if (!serdev)
+				return NOTIFY_DONE;
+
+			ret = serdev_device_add(serdev, "WCN7850");
+			if (ret) {
+				dev_err(dev, "Failed to add serdev for WCN7850: %d\n", ret);
+				serdev_device_put(serdev);
+				return NOTIFY_DONE;
+			}
+		}
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static bool pwrseq_pcie_m2_check_remote_node(struct device *dev, u8 port, const char *node)
+{
+	struct device_node *remote;
+
+	remote = of_graph_get_remote_node(dev_of_node(dev), port, -1);
+	if (remote && of_node_name_eq(remote, node)) {
+		of_node_put(remote);
+		return true;
+	}
+
+	of_node_put(remote);
+
+	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 void 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
+	 * interface and Serial as Port 1 interface.
+	 */
+	if (pwrseq_pcie_m2_check_remote_node(dev, 1, "serial")) {
+		if (pwrseq_pcie_m2_check_remote_node(dev, 0, "pcie")) {
+			ctx->dev = dev;
+			ctx->nb.notifier_call = pwrseq_m2_pcie_notify;
+			ret = (bus_register_notifier(&pci_bus_type, &ctx->nb));
+			if (ret) {
+				dev_err_probe(dev, ret, "Failed to register notifier for serdev\n");
+				return;
+			}
+		}
+	}
+}
+
 static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -122,6 +308,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;
 
 	config.parent = dev;
@@ -137,6 +333,12 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 				     "Failed to register the power sequencer\n");
 	}
 
+	/*
+	 * Register an optional notifier for creating protocol devices for
+	 * non-discoverable busses like UART.
+	 */
+	pwrseq_pcie_m2_register_notifier(ctx, dev);
+
 	return 0;
 }
 
@@ -145,6 +347,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.48.1

Re: [PATCH 9/9] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors

[Bartosz Golaszewski]

On Wed, Nov 12, 2025 at 3:45 PM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
>
> 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.
>
> For supporting Bluetooth over the non-discoverable UART interface, the
> driver currently creates the serdev interface 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.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>
> +static int pwrseq_pci_m2_e_uart_enable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);

Since this is new code and gpiod_set_value_cansleep() now returns an
integer, can you do

  return gpiod_set_value_cansleep()?

Same elsewhere.

>
> +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 device_node *remote;
> +       struct serdev_controller *serdev_ctrl;
> +       struct serdev_device *serdev;
> +       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.
> +        */
> +       remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 0, -1);
> +       if (!remote || (remote != pdev->dev.parent->of_node)) {
> +               of_node_put(remote);

You could really use some __free(device_node) here. It would simplify
the code below quite a bit and make sure you don't miss anything.

> +               return NOTIFY_DONE;
> +       }
> +       of_node_put(remote);
> +
> +       switch (action) {
> +       case BUS_NOTIFY_ADD_DEVICE:
> +               /* Create serdev device for WCN7850 */
> +               if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
> +                       remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 1, -1);
> +                       if (!remote) {
> +                               of_node_put(remote);
> +                               return NOTIFY_DONE;
> +                       }
> +
> +                       serdev_ctrl = of_find_serdev_controller_by_node(remote);
> +                       of_node_put(remote);
> +                       if (!serdev_ctrl)
> +                               return NOTIFY_DONE;
> +
> +                       serdev = serdev_device_alloc(serdev_ctrl);
> +                       if (!serdev)
> +                               return NOTIFY_DONE;
> +
> +                       ret = serdev_device_add(serdev, "WCN7850");
> +                       if (ret) {
> +                               dev_err(dev, "Failed to add serdev for WCN7850: %d\n", ret);
> +                               serdev_device_put(serdev);
> +                               return NOTIFY_DONE;
> +                       }
> +               }
> +               break;
> +       }
> +
> +       return NOTIFY_DONE;
> +}
> +
> +static bool pwrseq_pcie_m2_check_remote_node(struct device *dev, u8 port, const char *node)
> +{
> +       struct device_node *remote;

Same here.

> +
> +       remote = of_graph_get_remote_node(dev_of_node(dev), port, -1);
> +       if (remote && of_node_name_eq(remote, node)) {
> +               of_node_put(remote);
> +               return true;
> +       }
> +
> +       of_node_put(remote);
> +
> +       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.
> + */

I really like this idea BTW!

> +static void 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
> +        * interface and Serial as Port 1 interface.
> +        */
> +       if (pwrseq_pcie_m2_check_remote_node(dev, 1, "serial")) {
> +               if (pwrseq_pcie_m2_check_remote_node(dev, 0, "pcie")) {
> +                       ctx->dev = dev;
> +                       ctx->nb.notifier_call = pwrseq_m2_pcie_notify;
> +                       ret = (bus_register_notifier(&pci_bus_type, &ctx->nb));
> +                       if (ret) {
> +                               dev_err_probe(dev, ret, "Failed to register notifier for serdev\n");

If this is optional and we don't handle the error, should we really
print it as one? I'd say a dev_dbg() would suffice unless the failure
here impacts the driver's behavior (which it does, so maybe the
notifier should not be optional?).

Bart

Re: [PATCH 9/9] power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors

[Manivannan Sadhasivam]

On Wed, Nov 19, 2025 at 02:28:00PM +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 12, 2025 at 3:45 PM Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> wrote:
> >
> > 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.
> >
> > For supporting Bluetooth over the non-discoverable UART interface, the
> > driver currently creates the serdev interface 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.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >
> > +static int pwrseq_pci_m2_e_uart_enable(struct pwrseq_device *pwrseq)
> > +{
> > +       struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> > +
> > +       gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);
> 
> Since this is new code and gpiod_set_value_cansleep() now returns an
> integer, can you do
> 

Ack

>   return gpiod_set_value_cansleep()?
> 
> Same elsewhere.
> 
> >
> > +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 device_node *remote;
> > +       struct serdev_controller *serdev_ctrl;
> > +       struct serdev_device *serdev;
> > +       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.
> > +        */
> > +       remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 0, -1);
> > +       if (!remote || (remote != pdev->dev.parent->of_node)) {
> > +               of_node_put(remote);
> 
> You could really use some __free(device_node) here. It would simplify
> the code below quite a bit and make sure you don't miss anything.
> 

Ack. I'm still trying to get used to the scope based cleanup :)

> > +               return NOTIFY_DONE;
> > +       }
> > +       of_node_put(remote);
> > +
> > +       switch (action) {
> > +       case BUS_NOTIFY_ADD_DEVICE:
> > +               /* Create serdev device for WCN7850 */
> > +               if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
> > +                       remote = of_graph_get_remote_node(dev_of_node(ctx->dev), 1, -1);
> > +                       if (!remote) {
> > +                               of_node_put(remote);
> > +                               return NOTIFY_DONE;
> > +                       }
> > +
> > +                       serdev_ctrl = of_find_serdev_controller_by_node(remote);
> > +                       of_node_put(remote);
> > +                       if (!serdev_ctrl)
> > +                               return NOTIFY_DONE;
> > +
> > +                       serdev = serdev_device_alloc(serdev_ctrl);
> > +                       if (!serdev)
> > +                               return NOTIFY_DONE;
> > +
> > +                       ret = serdev_device_add(serdev, "WCN7850");
> > +                       if (ret) {
> > +                               dev_err(dev, "Failed to add serdev for WCN7850: %d\n", ret);
> > +                               serdev_device_put(serdev);
> > +                               return NOTIFY_DONE;
> > +                       }
> > +               }
> > +               break;
> > +       }
> > +
> > +       return NOTIFY_DONE;
> > +}
> > +
> > +static bool pwrseq_pcie_m2_check_remote_node(struct device *dev, u8 port, const char *node)
> > +{
> > +       struct device_node *remote;
> 
> Same here.
> 
> > +
> > +       remote = of_graph_get_remote_node(dev_of_node(dev), port, -1);
> > +       if (remote && of_node_name_eq(remote, node)) {
> > +               of_node_put(remote);
> > +               return true;
> > +       }
> > +
> > +       of_node_put(remote);
> > +
> > +       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.
> > + */
> 
> I really like this idea BTW!
> 
> > +static void 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
> > +        * interface and Serial as Port 1 interface.
> > +        */
> > +       if (pwrseq_pcie_m2_check_remote_node(dev, 1, "serial")) {
> > +               if (pwrseq_pcie_m2_check_remote_node(dev, 0, "pcie")) {
> > +                       ctx->dev = dev;
> > +                       ctx->nb.notifier_call = pwrseq_m2_pcie_notify;
> > +                       ret = (bus_register_notifier(&pci_bus_type, &ctx->nb));
> > +                       if (ret) {
> > +                               dev_err_probe(dev, ret, "Failed to register notifier for serdev\n");
> 
> If this is optional and we don't handle the error, should we really
> print it as one? I'd say a dev_dbg() would suffice unless the failure
> here impacts the driver's behavior (which it does, so maybe the
> notifier should not be optional?).
> 

Fair enough. I was on double mind tbh. But it makes sense to return failure.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree

[Rob Herring]

On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
<devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> 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.
>
> 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. I've used the M.2 card model name as the serdev device name. This is found
> out by comparing the PCIe VID:PID in the notifier. Is this approach acceptable?
> I did not use the PID as the serdev name since it will vary if the SDIO
> interface is used in the future.
>
> 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. Until then, this series is *not* mergeable as a
> whole.
>
> 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 M.2
> card connected over PCIe and UART.
>
> [1] https://lore.kernel.org/linux-pci/20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com
> [2] https://github.com/Mani-Sadhasivam/linux/commit/d39b81b3ff1ecfb0d423b4da0771925d41648b5a
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> Manivannan Sadhasivam (9):
>       serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros
>       serdev: Add serdev device based driver match support
>       serdev: Allow passing the serdev device name to serdev_device_add()
>       serdev: Add an API to find the serdev controller associated with the devicetree node
>       serdev: Add modalias support for serdev client devices
>       serdev: Skip registering serdev devices from DT is external connector is used
>       dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
>       Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card
>       power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
>
>  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++
>  MAINTAINERS                                        |   1 +
>  drivers/bluetooth/hci_qca.c                        |  20 ++
>  drivers/platform/x86/dell/dell-uart-backlight.c    |   2 +-
>  .../x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |   2 +-
>  drivers/platform/x86/x86-android-tablets/core.c    |   2 +-
>  drivers/power/sequencing/Kconfig                   |   1 +
>  drivers/power/sequencing/pwrseq-pcie-m2.c          | 218 ++++++++++++++++++++-
>  drivers/tty/serdev/core.c                          |  77 +++++++-
>  include/linux/mod_devicetable.h                    |   8 +
>  include/linux/serdev.h                             |  25 ++-
>  scripts/mod/devicetable-offsets.c                  |   3 +
>  scripts/mod/file2alias.c                           |   8 +
>  13 files changed, 494 insertions(+), 27 deletions(-)
> ---
> base-commit: db81ec30672bb228cd7cd809edeeae661d621f2d

git show db81ec30672bb228cd7cd80
fatal: ambiguous argument 'db81ec30672bb228cd7cd80': unknown revision
or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

This series doesn't apply.

Rob

Re: [PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree

[Manivannan Sadhasivam]

On Wed, Nov 12, 2025 at 03:07:29PM -0600, Rob Herring wrote:
> On Wed, Nov 12, 2025 at 8:45 AM Manivannan Sadhasivam via B4 Relay
> <devnull+manivannan.sadhasivam.oss.qualcomm.com@kernel.org> 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.
> >
> > 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. I've used the M.2 card model name as the serdev device name. This is found
> > out by comparing the PCIe VID:PID in the notifier. Is this approach acceptable?
> > I did not use the PID as the serdev name since it will vary if the SDIO
> > interface is used in the future.
> >
> > 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. Until then, this series is *not* mergeable as a
> > whole.
> >
> > 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 M.2
> > card connected over PCIe and UART.
> >
> > [1] https://lore.kernel.org/linux-pci/20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com
> > [2] https://github.com/Mani-Sadhasivam/linux/commit/d39b81b3ff1ecfb0d423b4da0771925d41648b5a
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> > Manivannan Sadhasivam (9):
> >       serdev: Convert to_serdev_device() and to_serdev_controller() helpers to macros
> >       serdev: Add serdev device based driver match support
> >       serdev: Allow passing the serdev device name to serdev_device_add()
> >       serdev: Add an API to find the serdev controller associated with the devicetree node
> >       serdev: Add modalias support for serdev client devices
> >       serdev: Skip registering serdev devices from DT is external connector is used
> >       dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
> >       Bluetooth: hci_qca: Add support for WCN7850 PCIe M.2 card
> >       power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
> >
> >  .../bindings/connector/pcie-m2-e-connector.yaml    | 154 +++++++++++++++
> >  MAINTAINERS                                        |   1 +
> >  drivers/bluetooth/hci_qca.c                        |  20 ++
> >  drivers/platform/x86/dell/dell-uart-backlight.c    |   2 +-
> >  .../x86/lenovo/yoga-tab2-pro-1380-fastcharger.c    |   2 +-
> >  drivers/platform/x86/x86-android-tablets/core.c    |   2 +-
> >  drivers/power/sequencing/Kconfig                   |   1 +
> >  drivers/power/sequencing/pwrseq-pcie-m2.c          | 218 ++++++++++++++++++++-
> >  drivers/tty/serdev/core.c                          |  77 +++++++-
> >  include/linux/mod_devicetable.h                    |   8 +
> >  include/linux/serdev.h                             |  25 ++-
> >  scripts/mod/devicetable-offsets.c                  |   3 +
> >  scripts/mod/file2alias.c                           |   8 +
> >  13 files changed, 494 insertions(+), 27 deletions(-)
> > ---
> > base-commit: db81ec30672bb228cd7cd809edeeae661d621f2d
> 
> git show db81ec30672bb228cd7cd80
> fatal: ambiguous argument 'db81ec30672bb228cd7cd80': unknown revision
> or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> 
> This series doesn't apply.
> 

Sorry, I forgot to edit the dependencies with b4. I'll fix it in v2. But if you
are interested to try this one, here are the deps:

message-id: 20251108-pci-m2-v2-0-e8bc4d7bf42d@oss.qualcomm.com
base-commit: v6.18-rc1

- Mani

-- 
மணிவண்ணன் சதாசிவம்