[PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[PATCH v3 00/14] 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 DT compatible for the serdev swnode to match the existing OF
device_id of the bluetooth driver. This avoids implementing custom serdev id
matching as implemented till v2.

2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
the PCIe device DT node to extract properties such as
'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
add the PCIe DT node in the Root Port in conjunction with the Port node as
below?

pcie@0 {
	wifi@0 {
		compatible = "pci17cb,1103";
		...
		qcom,calibration-variant = "LE_X13S";
	};

	port {
		pcie4_port0_ep: endpoint {
			remote-endpoint = <&m2_e_pcie_ep>;
		};
	};
};

This will also require marking the PMU supplies optional in the relevant ath
bindings for M.2 cards.

3. Some M.2 cards require specific power up sequence like delays between
regulator/GPIO and such. For instance, the WCN7850 card supported in this series
requires 50ms delay between powering up an interface and driving it. I've just
hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
driver doesn't know anything about the device it is dealing with before powering
it ON, how should it handle the device specific power requirements? Should we
hardcode the device specific property in the connector node? But then, it will
no longer become a generic M.2 connector and sort of defeats the purpose of the
connector binding.

I hope to address these questions with the help of the relevant subsystem
maintainers and the community. 

Testing
=======

This series, together with the devicetree changes [2] was tested on the
Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
1620 LGA card connected over PCIe and UART.

Dependency
==========

This series is dependent on the M.2 Key M series [1] on top of v6.19-rc1.

[1] https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com
[2] https://github.com/Mani-Sadhasivam/linux/commit/753033861360171f2af1fdd56e8985ff916e1ac2

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Changes in v3:
- Switched to swnode for the serdev device and dropped the custom
  serdev_device_id related patches
- Added new swnode APIs to match the swnode with existing of_device_id
- Incorporated comments in the bindings patch
- Dropped the UIM interface from binding since it is not clear how it should get
  wired
- Incorporated comments in the pwrseq driver patch
- Splitted the pwrseq patch into two
- Added the 1620 LGA compatible with Key E fallback based on Stephan's finding
- Link to v2: https://lore.kernel.org/r/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com

Changes in v2:
- Used '-' for GPIO names in the binding and removed led*-gpios properties
- Described the endpoint nodes for port@0 and port@1 nodes
- Added the OF graph port to the serial binding
- Fixed the hci_qca driver to return err if devm_pwrseq_get() fails
- Incorporated various review comments in pwrseq driver
- Collected Ack
- Link to v1: https://lore.kernel.org/r/20251112-pci-m2-e-v1-0-97413d6bf824@oss.qualcomm.com

---
Manivannan Sadhasivam (13):
      serdev: Convert to_serdev_*() helpers to macros and use container_of_const()
      serdev: Add an API to find the serdev controller associated with the devicetree node
      software node: Add software_node_match_device() API
      software node: Add software_node_device_uevent() API
      software node: Add software_node_device_modalias() API
      serdev: Do not return -ENODEV from of_serdev_register_devices() if external connector is used
      serdev: Add support for swnode based driver matching and uevent/modalias
      dt-bindings: serial: Document the graph port
      dt-bindings: connector: Add PCIe M.2 Mechanical Key E connector
      dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector
      Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq
      power: sequencing: pcie-m2: Add support for PCIe M.2 Key E connectors
      power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth

Sui Jingfeng (1):
      software node: Implement device_get_match_data fwnode callback

 .../bindings/connector/pcie-m2-e-connector.yaml    | 161 ++++++++++++++
 .../devicetree/bindings/serial/serial.yaml         |   3 +
 MAINTAINERS                                        |   1 +
 drivers/base/swnode.c                              |  71 +++++++
 drivers/bluetooth/hci_qca.c                        |   9 +
 drivers/power/sequencing/Kconfig                   |   1 +
 drivers/power/sequencing/pwrseq-pcie-m2.c          | 234 ++++++++++++++++++++-
 drivers/tty/serdev/core.c                          |  45 +++-
 include/linux/property.h                           |   5 +
 include/linux/serdev.h                             |  24 +--
 10 files changed, 528 insertions(+), 26 deletions(-)
---
base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
change-id: 20251112-pci-m2-e-94695ac9d657
prerequisite-message-id: 20251125-pci-m2-v3-0-c528042aea47@oss.qualcomm.com
prerequisite-patch-id: 58778d8eb97ab86008cd48fb5d28ed6cc0bbbc1b
prerequisite-patch-id: 2dd7d793a67f59ef6e6b5137e69436896198b965
prerequisite-patch-id: 8ccaa5fdd95e64e69cd942f93c26e89b827d0453
prerequisite-patch-id: 3d3e1bb7959ab1e140c5024acdd8655e7a7e99ef

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

[PATCH v3 01/14] serdev: Convert to_serdev_*() helpers to macros and use container_of_const()

[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 and
also use container_of_const() as container_of() is deprecated.

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 include/linux/serdev.h | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 34562eb99931..ecde0ad3e248 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -49,10 +49,7 @@ struct serdev_device {
 	struct mutex write_lock;
 };
 
-static inline struct serdev_device *to_serdev_device(struct device *d)
-{
-	return container_of(d, struct serdev_device, dev);
-}
+#define to_serdev_device(d) container_of_const(d, struct serdev_device, dev)
 
 /**
  * struct serdev_device_driver - serdev slave device driver
@@ -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_const(d, struct serdev_device_driver, driver)
 
 enum serdev_parity {
 	SERDEV_PARITY_NONE,
@@ -111,10 +105,7 @@ struct serdev_controller {
 	const struct serdev_controller_ops *ops;
 };
 
-static inline struct serdev_controller *to_serdev_controller(struct device *d)
-{
-	return container_of(d, struct serdev_controller, dev);
-}
+#define to_serdev_controller(d) container_of_const(d, struct serdev_controller, dev)
 
 static inline void *serdev_device_get_drvdata(const struct serdev_device *serdev)
 {

-- 
2.48.1

[PATCH v3 02/14] 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 b33e708cb245..25382c2d63e6 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -504,6 +504,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 ecde0ad3e248..db9bfaba0662 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -333,4 +333,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

Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:20PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Add of_find_serdev_controller_by_node() API to find the serdev controller
> device associated with the devicetree node.

Why OF-centric code? No, please do it fwnode-based.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node

[Manivannan Sadhasivam]

On Mon, Jan 12, 2026 at 09:50:33AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:20PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 
> > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > device associated with the devicetree node.
> 
> Why OF-centric code? No, please do it fwnode-based.
> 

No issues for me. But the existing APIs in serdev are OF based. If uniformity is
not needed, I can change it to a fwnode based API.

- Mani

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

Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node

[Andy Shevchenko]

On Mon, Jan 12, 2026 at 01:25:21PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Jan 12, 2026 at 09:50:33AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:20PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > 
> > > Add of_find_serdev_controller_by_node() API to find the serdev controller
> > > device associated with the devicetree node.
> > 
> > Why OF-centric code? No, please do it fwnode-based.
> 
> No issues for me. But the existing APIs in serdev are OF based. If uniformity is
> not needed, I can change it to a fwnode based API.

Really? serdev.h has no OF APIs.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 02/14] serdev: Add an API to find the serdev controller associated with the devicetree node

[Bartosz Golaszewski]

On Mon, 12 Jan 2026 08:55:21 +0100, Manivannan Sadhasivam
<mani@kernel.org> said:
> On Mon, Jan 12, 2026 at 09:50:33AM +0200, Andy Shevchenko wrote:
>> On Sat, Jan 10, 2026 at 12:26:20PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>>
>> > Add of_find_serdev_controller_by_node() API to find the serdev controller
>> > device associated with the devicetree node.
>>
>> Why OF-centric code? No, please do it fwnode-based.
>>
>
> No issues for me. But the existing APIs in serdev are OF based. If uniformity is
> not needed, I can change it to a fwnode based API.
>

Using fwnodes here shouldn't be an issue, even though serdev core assigns
dev->of_node, it will be converted to dev->fwnode when the device is registered.

Bart

[PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Manivannan Sadhasivam via B4 Relay]

From: Sui Jingfeng <sui.jingfeng@linux.dev>

Because the software node backend of the fwnode API framework lacks an
implementation for the .device_get_match_data function callback. This
makes it difficult to use(and/or test) a few drivers that originates
from DT world on the non-DT platform.

Implement the .device_get_match_data fwnode callback, which helps to keep
the three backends of the fwnode API aligned as much as possible. This is
also a fundamental step to make a few drivers OF-independent truely
possible.

Device drivers or platform setup codes are expected to provide a software
node string property, named as "compatible". At this moment, the value of
this string property is being used to match against the compatible entries
in the of_device_id table. It can be extended in the future though.

Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
[mani: removed fixes tag]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/base/swnode.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 16a8301c25d6..cd722712b8e9 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -15,6 +15,7 @@
 #include <linux/kobject.h>
 #include <linux/kstrtox.h>
 #include <linux/list.h>
+#include <linux/mod_devicetable.h>
 #include <linux/property.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
@@ -390,6 +391,33 @@ static void software_node_put(struct fwnode_handle *fwnode)
 	kobject_put(&swnode->kobj);
 }
 
+static const void *
+software_node_get_match_data(const struct fwnode_handle *fwnode,
+			     const struct device *dev)
+{
+	struct swnode *swnode = to_swnode(fwnode);
+	const struct of_device_id *matches = dev->driver->of_match_table;
+	const char *val = NULL;
+	int ret;
+
+	ret = property_entry_read_string_array(swnode->node->properties,
+					       "compatible", &val, 1);
+	if (ret < 0 || !val)
+		return NULL;
+
+	if (!matches)
+		return NULL;
+
+	while (matches->compatible[0]) {
+		if (!strcmp(matches->compatible, val))
+			return matches->data;
+
+		++matches;
+	}
+
+	return NULL;
+}
+
 static bool software_node_property_present(const struct fwnode_handle *fwnode,
 					   const char *propname)
 {
@@ -694,6 +722,7 @@ software_node_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 static const struct fwnode_operations software_node_ops = {
 	.get = software_node_get,
 	.put = software_node_put,
+	.device_get_match_data = software_node_get_match_data,
 	.property_present = software_node_property_present,
 	.property_read_bool = software_node_property_present,
 	.property_read_int_array = software_node_read_int_array,

-- 
2.48.1

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Because the software node backend of the fwnode API framework lacks an
> implementation for the .device_get_match_data function callback.

Maybe this is done on purpose. Have you thought about this aspect?

> This makes it difficult to use(and/or test) a few drivers that originates
> from DT world on the non-DT platform.

How difficult? DSA implementation went to the way of taking DT overlay
approach. Why that one can't be applied here?

> Implement the .device_get_match_data fwnode callback, which helps to keep
> the three backends of the fwnode API aligned as much as possible. This is
> also a fundamental step to make a few drivers OF-independent truely
> possible.
> 
> Device drivers or platform setup codes are expected to provide a software
> node string property, named as "compatible". At this moment, the value of
> this string property is being used to match against the compatible entries
> in the of_device_id table. It can be extended in the future though.

I really do not want to see this patch without very good justification
(note, there were at least two attempts in the past to add this stuff
 and no-one was merged, have you studied those cases?).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Manivannan Sadhasivam]

+ Dmitry Torokhov (who was against this patch previously)

On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 
> > Because the software node backend of the fwnode API framework lacks an
> > implementation for the .device_get_match_data function callback.
> 
> Maybe this is done on purpose. Have you thought about this aspect?
> 

IMO, software nodes were introduced to add sub-properties to the existing
firmware nodes, but it has usecase/potential to go beyond that. More below.

> > This makes it difficult to use(and/or test) a few drivers that originates
> > from DT world on the non-DT platform.
> 
> How difficult? DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?
> 

Sometimes you do not have any DT node at all. For example, in this series, the
M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
match it with the existing OF based BT driver (for non-M2 device). From the
driver's point of view, a BT device attached to the M.2 slot and over custom
connectors are both the same. Only difference is that, in the case of custom
connectors, the bluetooth DT node will have the BT device described and in the
case of M.2, the device won't get described, but just the connector [1]. But for
the driver to identify the device (since it cannot enumerate it), either it has
to rely on DT/ACPI or some other means.

In the previous version of this series [2], I used the serdev ID based on the
product name for creating the serdev device and added a new id_table for serdev
driver to match with the device [3]. This almost duplicated the existing OF
match logic. Then Bartosz suggested to use swnode approach [4], to get rid of
the custom serdev ID based matching. When I prototyped, it mostly worked well,
except that swnode needed to have its own .device_get_match_data(), match() and
uevent/modalias functions. And if the swnode reused the existing DT compatible
string, it can work with the existing BT driver without modifications. And this
approach can also be extended to devices instantiated from the board specific
drivers.

[1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
[3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
[4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/

> > Implement the .device_get_match_data fwnode callback, which helps to keep
> > the three backends of the fwnode API aligned as much as possible. This is
> > also a fundamental step to make a few drivers OF-independent truely
> > possible.
> > 
> > Device drivers or platform setup codes are expected to provide a software
> > node string property, named as "compatible". At this moment, the value of
> > this string property is being used to match against the compatible entries
> > in the of_device_id table. It can be extended in the future though.
> 
> I really do not want to see this patch without very good justification
> (note, there were at least two attempts in the past to add this stuff
>  and no-one was merged, have you studied those cases?).
> 

Yes I did. I didn't put the above justification in the cover letter, as it was
already overwhelmed with too much information regarding the connector node.
Maybe I should've added it in the comments section of this patch. But I didn't
know how to do that with b4.

- Mani

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

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Andy Shevchenko]

On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> + Dmitry Torokhov (who was against this patch previously)
> 
> On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > 
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> > 
> > Maybe this is done on purpose. Have you thought about this aspect?
> 
> IMO, software nodes were introduced to add sub-properties to the existing
> firmware nodes, but it has usecase/potential to go beyond that. More below.

Potential doesn't mean the necessity.

> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > 
> > How difficult? DSA implementation went to the way of taking DT overlay
> > approach. Why that one can't be applied here?
> 
> Sometimes you do not have any DT node at all.

Yes, that is exactly the case I have referred to. The PCI core (in Linux)
is able to create DT subtree on non-OF based platforms.

> For example, in this series, the
> M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> match it with the existing OF based BT driver (for non-M2 device). From the
> driver's point of view, a BT device attached to the M.2 slot and over custom
> connectors are both the same. Only difference is that, in the case of custom
> connectors, the bluetooth DT node will have the BT device described and in the
> case of M.2, the device won't get described, but just the connector [1].

So, what's the problem to add such a description? (Assuming you want a customisation
it can be done at run-time, correct?)

> But for the driver to identify the device (since it cannot enumerate it),
> either it has to rely on DT/ACPI or some other means.

Yes.

> In the previous version of this series [2], I used the serdev ID based on the
> product name for creating the serdev device and added a new id_table for serdev
> driver to match with the device [3]. This almost duplicated the existing OF
> match logic.

That's how we do when we want to add a board file, but thing is that we do not
want board files (only in the cases when other ways are impossible or make less
sense).

> Then Bartosz suggested to use swnode approach [4], to get rid of
> the custom serdev ID based matching. When I prototyped, it mostly worked well,

I know that Bart is fan of swnodes, but it should not be used as a silver
bullet, really.

> except that swnode needed to have its own .device_get_match_data(), match() and
> uevent/modalias functions. And if the swnode reused the existing DT compatible
> string, it can work with the existing BT driver without modifications. And this
> approach can also be extended to devices instantiated from the board specific
> drivers.

DT overlay should work without even modifications done to swnode code, right?

> [1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
> [2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
> [3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
> [4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/
> 
> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > > 
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> > 
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> >  and no-one was merged, have you studied those cases?).
> 
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.

Then you missed it. The cover letter for such a change is way too short.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Manivannan Sadhasivam]

On Mon, Jan 12, 2026 at 10:27:45AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > + Dmitry Torokhov (who was against this patch previously)
> > 
> > On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > 
> > > > Because the software node backend of the fwnode API framework lacks an
> > > > implementation for the .device_get_match_data function callback.
> > > 
> > > Maybe this is done on purpose. Have you thought about this aspect?
> > 
> > IMO, software nodes were introduced to add sub-properties to the existing
> > firmware nodes, but it has usecase/potential to go beyond that. More below.
> 
> Potential doesn't mean the necessity.
> 
> > > > This makes it difficult to use(and/or test) a few drivers that originates
> > > > from DT world on the non-DT platform.
> > > 
> > > How difficult? DSA implementation went to the way of taking DT overlay
> > > approach. Why that one can't be applied here?
> > 
> > Sometimes you do not have any DT node at all.
> 
> Yes, that is exactly the case I have referred to. The PCI core (in Linux)
> is able to create DT subtree on non-OF based platforms.
> 

Maybe I should look into creating dynamic DT node for the device and insert it
to the uart node. Theoretically it should work.

> > For example, in this series, the
> > M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> > match it with the existing OF based BT driver (for non-M2 device). From the
> > driver's point of view, a BT device attached to the M.2 slot and over custom
> > connectors are both the same. Only difference is that, in the case of custom
> > connectors, the bluetooth DT node will have the BT device described and in the
> > case of M.2, the device won't get described, but just the connector [1].
> 
> So, what's the problem to add such a description? (Assuming you want a customisation
> it can be done at run-time, correct?)
> 
> > But for the driver to identify the device (since it cannot enumerate it),
> > either it has to rely on DT/ACPI or some other means.
> 
> Yes.
> 
> > In the previous version of this series [2], I used the serdev ID based on the
> > product name for creating the serdev device and added a new id_table for serdev
> > driver to match with the device [3]. This almost duplicated the existing OF
> > match logic.
> 
> That's how we do when we want to add a board file, but thing is that we do not
> want board files (only in the cases when other ways are impossible or make less
> sense).
> 
> > Then Bartosz suggested to use swnode approach [4], to get rid of
> > the custom serdev ID based matching. When I prototyped, it mostly worked well,
> 
> I know that Bart is fan of swnodes, but it should not be used as a silver
> bullet, really.
> 
> > except that swnode needed to have its own .device_get_match_data(), match() and
> > uevent/modalias functions. And if the swnode reused the existing DT compatible
> > string, it can work with the existing BT driver without modifications. And this
> > approach can also be extended to devices instantiated from the board specific
> > drivers.
> 
> DT overlay should work without even modifications done to swnode code, right?
> 

Not from the overlay binaries (.dtbo), but adding dynamic BT node for the device
based on the enumerated PCI device should work.

- Mani

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

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Manivannan Sadhasivam]

On Mon, Jan 12, 2026 at 02:32:21PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Jan 12, 2026 at 10:27:45AM +0200, Andy Shevchenko wrote:
> > On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > > + Dmitry Torokhov (who was against this patch previously)
> > > 
> > > On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > > > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > > 
> > > > > Because the software node backend of the fwnode API framework lacks an
> > > > > implementation for the .device_get_match_data function callback.
> > > > 
> > > > Maybe this is done on purpose. Have you thought about this aspect?
> > > 
> > > IMO, software nodes were introduced to add sub-properties to the existing
> > > firmware nodes, but it has usecase/potential to go beyond that. More below.
> > 
> > Potential doesn't mean the necessity.
> > 
> > > > > This makes it difficult to use(and/or test) a few drivers that originates
> > > > > from DT world on the non-DT platform.
> > > > 
> > > > How difficult? DSA implementation went to the way of taking DT overlay
> > > > approach. Why that one can't be applied here?
> > > 
> > > Sometimes you do not have any DT node at all.
> > 
> > Yes, that is exactly the case I have referred to. The PCI core (in Linux)
> > is able to create DT subtree on non-OF based platforms.
> > 
> 
> Maybe I should look into creating dynamic DT node for the device and insert it
> to the uart node. Theoretically it should work.
> 

It worked flawlessly. So I sent v4 incorporating this design:
https://lore.kernel.org/linux-pci/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com/

Thanks!

- Mani

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

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Konstantin Ryabitsev]

On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> >  and no-one was merged, have you studied those cases?).
> > 
> 
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.

You can just amend the commit directly and put comments under "---". They
will be preserved when email is sent, but won't be applied when the maintainer
pulls the series.

-K

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Manivannan Sadhasivam]

On Mon, Jan 12, 2026 at 08:37:02AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > > I really do not want to see this patch without very good justification
> > > (note, there were at least two attempts in the past to add this stuff
> > >  and no-one was merged, have you studied those cases?).
> > > 
> > 
> > Yes I did. I didn't put the above justification in the cover letter, as it was
> > already overwhelmed with too much information regarding the connector node.
> > Maybe I should've added it in the comments section of this patch. But I didn't
> > know how to do that with b4.
> 
> You can just amend the commit directly and put comments under "---". They
> will be preserved when email is sent, but won't be applied when the maintainer
> pulls the series.
> 

Ah, thanks for the info!

- Mani

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

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Sui Jingfeng]

On 2026/1/12 15:56, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 
>> Because the software node backend of the fwnode API framework lacks an
>> implementation for the .device_get_match_data function callback.
> 
> Maybe this is done on purpose. 


It is a *fact* that the broken swnode lacks an implementation for the 
.device_get_match_data stub.


Otherwise, If it is really done *on purpose*, the maintainers of swnode
backend probably shall document it in the source file *explicitly*.

Have you thought about this aspect?
> 

If it is sure thing, then it shouldn't start with "Maybe ..."


>> This makes it difficult to use(and/or test) a few drivers that originates
>> from DT world on the non-DT platform.
> 
> How difficult? 

The emphasis isn't on the 'difficult' word, it means 'inconvenience'

> DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?


Software node as an complement of ACPI, Therefore should do the same.



DT overlay introduce extra overhead/side effects on the non-DT systems.

Besides, DT overlay requires the OS distribution(such as ubuntu) has the 
DT overlay config option selected.



> 
>> Implement the .device_get_match_data fwnode callback, which helps to keep
>> the three backends of the fwnode API aligned as much as possible. This is
>> also a fundamental step to make a few drivers OF-independent truely
>> possible.
>>
>> Device drivers or platform setup codes are expected to provide a software
>> node string property, named as "compatible". At this moment, the value of
>> this string property is being used to match against the compatible entries
>> in the of_device_id table. It can be extended in the future though.
> 
> I really do not want to see this patch

You can do that by dropping the maintainer-ship.

Your endless, bruth-force ranting on such a straight-forward thing 
doesn't make much sense, because that waste everybody's time.

> without very good justification


Justifications has been provided over and over again.

> (note, there were at least two attempts in the past to add this stuff

This exactly saying that the implementation is missing.

>   and no-one was merged, 

That's the reason why you see it at least the second time.

have you studied those cases?).
> 

The first one is not 100% correct.

Re: [PATCH v3 03/14] software node: Implement device_get_match_data fwnode callback

[Andy Shevchenko]

On Wed, Jan 14, 2026 at 11:21:59AM +0800, Sui Jingfeng wrote:
> On 2026/1/12 15:56, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> > Maybe this is done on purpose.
> 
> It is a *fact* that the broken swnode lacks an implementation for the .device_get_match_data stub.

No need to re-create board files when it's not needed or doesn't fit.

> Otherwise, If it is really done *on purpose*, the maintainers of swnode
> backend could/shall document it in the source file *explicitly*.

Probably it should be spoken in a better way.

> > Have you thought about this aspect?
> 
> If you are sure, then stop telling us something start with "Maybe ..."

I wasn't the author of the swnode idea I can't read their minds. Please,
ask the respective people about this directly.

> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > How difficult?
> 
> The emphasis isn't on the 'difficult', it means that not convenient
> 
> > DSA implementation went to the way of taking DT overlay
> > approach.
> 
> Software node can do the same implementation just as what ACPI fwnode backend does.
> 
> > Why that one can't be applied here?
> 
> DT overlay requires the OS distribution(such as ubuntu) has theDT overlay
> config option selected.  this is introduce extra overhead/side effects on the
> non-DT systems.

If we have hotpluggable or runtime reconfigurable devices this is the expected
option to support them. I don't see a problem here.

> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > > 
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> > I really do not want to see this patch
> 
> Whatever!
> 
> Then just stop the endless, bruth-force ranting on such a straight-forward thing.
> 
> > without very good justification
> 
> Justifications has been provided over and over again.
> 
> > (note, there were at least two attempts in the past
> 
> This exactly saying that the implementation is missing.

Now you count a third one for your pleasure :-)

P.S.
We already had this discussion in the past and this attitude won't help
moving forward.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 04/14] software node: Add software_node_match_device() API

[Manivannan Sadhasivam via B4 Relay]

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

Add software_node_match_device() API to match the swnode device with the
swnode driver. The matching is based on the compatible property in the
device and the driver's of_match_table.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/base/swnode.c    | 16 ++++++++++++++++
 include/linux/property.h |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index cd722712b8e9..4a3b367dea02 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -372,6 +372,22 @@ void property_entries_free(const struct property_entry *properties)
 }
 EXPORT_SYMBOL_GPL(property_entries_free);
 
+bool software_node_match_device(struct device *dev, const struct device_driver *drv)
+{
+	const struct of_device_id *id;
+
+	if (!drv->of_match_table)
+		return false;
+
+	for (id = drv->of_match_table; id->compatible[0]; id++) {
+		if (device_is_compatible(dev, id->compatible))
+			return true;
+	}
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(software_node_match_device);
+
 /* -------------------------------------------------------------------------- */
 /* fwnode operations */
 
diff --git a/include/linux/property.h b/include/linux/property.h
index 272bfbdea7bf..7fe75ab732f6 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -14,6 +14,7 @@
 #include <linux/array_size.h>
 #include <linux/bits.h>
 #include <linux/cleanup.h>
+#include <linux/device.h>
 #include <linux/fwnode.h>
 #include <linux/stddef.h>
 #include <linux/types.h>
@@ -597,6 +598,8 @@ void software_node_unregister_node_group(const struct software_node * const *nod
 int software_node_register(const struct software_node *node);
 void software_node_unregister(const struct software_node *node);
 
+bool software_node_match_device(struct device *dev, const struct device_driver *drv);
+
 struct fwnode_handle *
 fwnode_create_software_node(const struct property_entry *properties,
 			    const struct fwnode_handle *parent);

-- 
2.48.1

Re: [PATCH v3 04/14] software node: Add software_node_match_device() API

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Add software_node_match_device() API to match the swnode device with the
> swnode driver. The matching is based on the compatible property in the
> device and the driver's of_match_table.

NAK. swnodes != real firmware nodes.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 04/14] software node: Add software_node_match_device() API

[Bartosz Golaszewski]

On Mon, 12 Jan 2026 09:31:44 +0100, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>
>> Add software_node_match_device() API to match the swnode device with the
>> swnode driver. The matching is based on the compatible property in the
>> device and the driver's of_match_table.
>
> NAK. swnodes != real firmware nodes.
>

While I'm not arguing that this is *the* solution, I think it warrants
a discussion on proper matching of devices that are only backed by a software
node - for instance a serdev device on the auxiliary bus. I understand what
software nodes were historically but perhaps it's time to extend their role as
a full-blown firmware node allowing matching with drivers.

Reusing existing OF IDs is just one way, we could potentially think about a
high-level fwnode-based device to driver matching?

Bartosz

Re: [PATCH v3 04/14] software node: Add software_node_match_device() API

[Andy Shevchenko]

On Mon, Jan 12, 2026 at 06:03:34AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 09:31:44 +0100, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> >
> >> Add software_node_match_device() API to match the swnode device with the
> >> swnode driver. The matching is based on the compatible property in the
> >> device and the driver's of_match_table.
> >
> > NAK. swnodes != real firmware nodes.
> 
> While I'm not arguing that this is *the* solution, I think it warrants
> a discussion on proper matching of devices that are only backed by a software
> node - for instance a serdev device on the auxiliary bus. I understand what
> software nodes were historically but perhaps it's time to extend their role as
> a full-blown firmware node allowing matching with drivers.
> 
> Reusing existing OF IDs is just one way, we could potentially think about a
> high-level fwnode-based device to driver matching?

There is already proposed and agree way to do that via DT overlays.
If one needs to describe the (PnP or hotpluggable) hardware, it's
the way to go as the HW maybe much complex than the just one small UART
appendix.

As per auxdevice, this should not be enumerable by compatible. The auxdevice
usually are created by other devices (from real ones) that _know_ the topology.
I don't see why we need to open the can of worms with the software nodes
to enumerate them as real ones.

P.S. Collect others' opinions (esp. device property reviewers and maintainers)
and we will see. But I do not see any even looking good justification for that.
It might be that I didn't get fully the use case and the other means can not
be used. But taking into account history of the rejection of the matching against
OF compatible string in swnodes suggests that this will stay the way it's now.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 05/14] software node: Add software_node_device_uevent() API

[Manivannan Sadhasivam via B4 Relay]

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

Add software_node_device_uevent() API to return the uevent variable for
swnode using the DT compatible property. The uevent will have the DT prefix
of "of:N*T*C" to match the DT's module device table.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/base/swnode.c    | 13 +++++++++++++
 include/linux/property.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 4a3b367dea02..c33e09300e5f 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -388,6 +388,19 @@ bool software_node_match_device(struct device *dev, const struct device_driver *
 }
 EXPORT_SYMBOL_GPL(software_node_match_device);
 
+int software_node_device_uevent(const struct device *dev, struct kobj_uevent_env *env)
+{
+	const char *compatible;
+	int ret;
+
+	ret = device_property_read_string(dev, "compatible", &compatible);
+	if (ret)
+		return ret;
+
+	return add_uevent_var(env, "MODALIAS=of:N*T*C%s", compatible);
+}
+EXPORT_SYMBOL_GPL(software_node_device_uevent);
+
 /* -------------------------------------------------------------------------- */
 /* fwnode operations */
 
diff --git a/include/linux/property.h b/include/linux/property.h
index 7fe75ab732f6..14f85fd66bfc 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -599,6 +599,7 @@ int software_node_register(const struct software_node *node);
 void software_node_unregister(const struct software_node *node);
 
 bool software_node_match_device(struct device *dev, const struct device_driver *drv);
+int software_node_device_uevent(const struct device *dev, struct kobj_uevent_env *env);
 
 struct fwnode_handle *
 fwnode_create_software_node(const struct property_entry *properties,

-- 
2.48.1

Re: [PATCH v3 05/14] software node: Add software_node_device_uevent() API

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:23PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Add software_node_device_uevent() API to return the uevent variable for
> swnode using the DT compatible property. The uevent will have the DT prefix
> of "of:N*T*C" to match the DT's module device table.

This even sounds wrong.
NAK.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 06/14] software node: Add software_node_device_modalias() API

[Manivannan Sadhasivam via B4 Relay]

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

Add software_node_device_modalias() API to return the MODALIAS string for
swnode based on the swnode's compatible property.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/base/swnode.c    | 13 +++++++++++++
 include/linux/property.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index c33e09300e5f..a9fa19a27dc6 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -401,6 +401,19 @@ int software_node_device_uevent(const struct device *dev, struct kobj_uevent_env
 }
 EXPORT_SYMBOL_GPL(software_node_device_uevent);
 
+ssize_t software_node_device_modalias(struct device *dev, char *str, ssize_t len)
+{
+	const char *compatible;
+	int ret;
+
+	ret = device_property_read_string(dev, "compatible", &compatible);
+	if (ret)
+		return ret;
+
+	return sysfs_emit(str, "%s\n", compatible);
+}
+EXPORT_SYMBOL_GPL(software_node_device_modalias);
+
 /* -------------------------------------------------------------------------- */
 /* fwnode operations */
 
diff --git a/include/linux/property.h b/include/linux/property.h
index 14f85fd66bfc..94ea02ae1675 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -600,6 +600,7 @@ void software_node_unregister(const struct software_node *node);
 
 bool software_node_match_device(struct device *dev, const struct device_driver *drv);
 int software_node_device_uevent(const struct device *dev, struct kobj_uevent_env *env);
+ssize_t software_node_device_modalias(struct device *dev, char *str, ssize_t len);
 
 struct fwnode_handle *
 fwnode_create_software_node(const struct property_entry *properties,

-- 
2.48.1

Re: [PATCH v3 06/14] software node: Add software_node_device_modalias() API

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:24PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Add software_node_device_modalias() API to return the MODALIAS string for
> swnode based on the swnode's compatible property.

NAK. swnodes != real firmware nodes.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 07/14] serdev: Do not return -ENODEV from of_serdev_register_devices() if 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 may be created dynamically by the connector
driver. So do not return -ENODEV from of_serdev_register_devices() if the
static nodes are not found and the graph node is used.

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/tty/serdev/core.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 25382c2d63e6..f8093b606dda 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>
@@ -548,7 +549,13 @@ static int of_serdev_register_devices(struct serdev_controller *ctrl)
 		} else
 			found = true;
 	}
-	if (!found)
+
+	/*
+	 * When the serdev controller is connected to an external connector like
+	 * M.2 in DT, then the serdev devices may be created dynamically by the
+	 * connector driver.
+	 */
+	if (!found && !of_graph_is_present(ctrl->dev.of_node))
 		return -ENODEV;
 
 	return 0;

-- 
2.48.1

[PATCH v3 08/14] serdev: Add support for swnode based driver matching and uevent/modalias

[Manivannan Sadhasivam via B4 Relay]

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

Serdev devices that do not use OF or ACPI can use swnode to expose the
device specific properties that could be used to match the serdev driver.
For such devices, provide the swnode based driver matching and
uevent/modalias support.

If a serdev device doesn't support neither OF, nor ACPI, swnode will be
tried as a last resort.

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

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index f8093b606dda..9d42bd5f550a 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -35,7 +35,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 software_node_device_modalias(dev, buf, PAGE_SIZE);
 }
 static DEVICE_ATTR_RO(modalias);
 
@@ -49,13 +53,15 @@ 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 software_node_device_uevent(dev, env);
 }
 
 static void serdev_device_release(struct device *dev)
@@ -91,11 +97,13 @@ static int serdev_device_match(struct device *dev, const struct device_driver *d
 	if (!is_serdev_device(dev))
 		return 0;
 
-	/* TODO: platform matching */
 	if (acpi_driver_match_device(dev, drv))
 		return 1;
 
-	return of_driver_match_device(dev, drv);
+	if (of_driver_match_device(dev, drv))
+		return 1;
+
+	return software_node_match_device(dev, drv);
 }
 
 /**

-- 
2.48.1

[PATCH v3 09/14] dt-bindings: serial: Document the graph port

[Manivannan Sadhasivam via B4 Relay]

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

A serial controller could be connected to an external connector like PCIe
M.2 for controlling the serial interface of the card. Hence, document the
OF graph port.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/serial/serial.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 6aa9cfae417b..96eb1de8771e 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -87,6 +87,9 @@ properties:
     description:
       TX FIFO threshold configuration (in bytes).
 
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+
 patternProperties:
   "^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$":
     if:

-- 
2.48.1

[PATCH v3 10/14] 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. Spec also provides an optional interface to connect the UIM card,
but that is not covered in this binding.

The connector provides a primary power supply of 3.3v, along with an
optional 1.8v VIO supply for the Adapter I/O buffer circuitry operating at
1.8v sideband signaling.

The connector also supplies optional signals in the form of GPIOs for fine
grained power management.

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 000000000000..b65b39ddfd19
--- /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: Connector interfaces for Wi-Fi
+
+        properties:
+          endpoint@0:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description: PCIe interface
+
+          endpoint@1:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description: SDIO interface
+
+        anyOf:
+          - required:
+              - endpoint@0
+          - required:
+              - endpoint@1
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Connector interfaces for BT
+
+        properties:
+          endpoint@0:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description: USB 2.0 interface
+
+          endpoint@1:
+            $ref: /schemas/graph.yaml#/properties/endpoint
+            description: UART interface
+
+        anyOf:
+          - required:
+              - endpoint@0
+          - required:
+              - endpoint@1
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: PCM/I2S interface
+
+      i2c-parent:
+        $ref: /schemas/types.yaml#/definitions/phandle
+        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 input 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 input to W_DISABLE2# 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
+
+  viocfg-gpios:
+    description: GPIO output 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
+
+required:
+  - compatible
+  - vpcie3v3-supply
+
+additionalProperties: false
+
+examples:
+  # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    connector {
+        compatible = "pcie-m2-e-connector";
+        vpcie3v3-supply = <&vreg_wcn_3p3>;
+        vpcie1v8-supply = <&vreg_l15b_1p8>;
+        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>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                endpoint@0 {
+                    reg = <0>;
+                    remote-endpoint = <&pcie4_port0_ep>;
+                };
+            };
+
+            port@1 {
+                reg = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                endpoint@1 {
+                    reg = <1>;
+                    remote-endpoint = <&uart14_ep>;
+                };
+            };
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2eb7b6d26573..451c54675b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20795,6 +20795,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

[PATCH v3 11/14] dt-bindings: connector: m2: Add M.2 1620 LGA soldered down connector

[Manivannan Sadhasivam via B4 Relay]

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

Lenovo Thinkpad T14s is found to have a soldered down version of M.2 1620
LGA connector. Though, there is no 1620 LGA form factor defined in the M.2
spec, it looks very similar to the M.2 Key M connector. So add the
"pcie-m2-1620-lga-connector" compatible with "pcie-m2-e-connector" fallback
to reuse the Key M binding.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 .../devicetree/bindings/connector/pcie-m2-e-connector.yaml       | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
index b65b39ddfd19..9757fe92907b 100644
--- a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
@@ -17,7 +17,14 @@ description:
 
 properties:
   compatible:
-    const: pcie-m2-e-connector
+    oneOf:
+      - items:
+          - enum:
+              - pcie-m2-1620-lga-connector
+          - const: pcie-m2-e-connector
+      - items:
+          - enum:
+              - pcie-m2-e-connector
 
   vpcie3v3-supply:
     description: A phandle to the regulator for 3.3v supply.

-- 
2.48.1

[PATCH v3 12/14] Bluetooth: hci_qca: Add M.2 Bluetooth device support using pwrseq

[Manivannan Sadhasivam via B4 Relay]

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

Power supply to the M.2 Bluetooth device attached to the host using M.2
connector is controlled using the 'uart' pwrseq device. So add support for
getting the pwrseq device if the OF graph link is present. Once obtained,
the existing pwrseq APIs can be used to control the power supplies of the
M.2 card.

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

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 888176b0faa9..4d562596ebf9 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>
@@ -2384,6 +2385,14 @@ static int qca_serdev_probe(struct serdev_device *serdev)
 	case QCA_WCN6855:
 	case QCA_WCN7850:
 	case QCA_WCN6750:
+		if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
+			qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
+								   "uart");
+			if (IS_ERR(qcadev->bt_power->pwrseq))
+				return PTR_ERR(qcadev->bt_power->pwrseq);
+			break;
+		}
+
 		if (!device_property_present(&serdev->dev, "enable-gpios")) {
 			/*
 			 * Backward compatibility with old DT sources. If the

-- 
2.48.1

[PATCH v3 13/14] 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.

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

diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index f5fff84566ba..29bd204319cc 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 e01e19123415..ad94090bbdb2 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -4,12 +4,16 @@
  * Author: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
  */
 
+#include <linux/err.h>
 #include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_graph.h>
 #include <linux/of_platform.h>
+#include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/pwrseq/provider.h>
 #include <linux/regulator/consumer.h>
@@ -25,17 +29,20 @@ struct pwrseq_pcie_m2_ctx {
 	const struct pwrseq_pcie_m2_pdata *pdata;
 	struct regulator_bulk_data *regs;
 	size_t num_vregs;
-	struct notifier_block nb;
+	struct gpio_desc *w_disable1_gpio;
+	struct gpio_desc *w_disable2_gpio;
+	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 +51,84 @@ static int pwrseq_pcie_m2_m_vregs_disable(struct pwrseq_device *pwrseq)
 
 static const struct pwrseq_unit_data pwrseq_pcie_m2_vregs_unit_data = {
 	.name = "regulators-enable",
-	.enable = pwrseq_pcie_m2_m_vregs_enable,
-	.disable = pwrseq_pcie_m2_m_vregs_disable,
+	.enable = pwrseq_pcie_m2_vregs_enable,
+	.disable = pwrseq_pcie_m2_vregs_disable,
 };
 
-static const struct pwrseq_unit_data *pwrseq_pcie_m2_m_unit_deps[] = {
+static const struct pwrseq_unit_data *pwrseq_pcie_m2_unit_deps[] = {
 	&pwrseq_pcie_m2_vregs_unit_data,
 	NULL
 };
 
+static int pwrseq_pci_m2_e_uart_enable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);
+}
+
+static int pwrseq_pci_m2_e_uart_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 1);
+}
+
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_uart_unit_data = {
+	.name = "uart-enable",
+	.deps = pwrseq_pcie_m2_unit_deps,
+	.enable = pwrseq_pci_m2_e_uart_enable,
+	.disable = pwrseq_pci_m2_e_uart_disable,
+};
+
+static int pwrseq_pci_m2_e_pcie_enable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 0);
+}
+
+static int pwrseq_pci_m2_e_pcie_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 1);
+}
+
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_pcie_unit_data = {
+	.name = "pcie-enable",
+	.deps = pwrseq_pcie_m2_unit_deps,
+	.enable = pwrseq_pci_m2_e_pcie_enable,
+	.disable = pwrseq_pci_m2_e_pcie_disable,
+};
+
 static const struct pwrseq_unit_data pwrseq_pcie_m2_m_pcie_unit_data = {
 	.name = "pcie-enable",
-	.deps = pwrseq_pcie_m2_m_unit_deps,
+	.deps = pwrseq_pcie_m2_unit_deps,
+};
+
+static int pwrseq_pcie_m2_e_pwup_delay(struct pwrseq_device *pwrseq)
+{
+	/*
+	 * FIXME: This delay is only required for some Qcom WLAN/BT cards like
+	 * WCN7850 and not for all devices. But currently, there is no way to
+	 * identify the device model before enumeration.
+	 */
+	msleep(50);
+
+	return 0;
+}
+
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_uart_target_data = {
+	.name = "uart",
+	.unit = &pwrseq_pcie_m2_e_uart_unit_data,
+	.post_enable = pwrseq_pcie_m2_e_pwup_delay,
+};
+
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_pcie_target_data = {
+	.name = "pcie",
+	.unit = &pwrseq_pcie_m2_e_pcie_unit_data,
+	.post_enable = pwrseq_pcie_m2_e_pwup_delay,
 };
 
 static const struct pwrseq_target_data pwrseq_pcie_m2_m_pcie_target_data = {
@@ -63,11 +136,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,
 };
@@ -126,6 +209,16 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, ret,
 				     "Failed to get all regulators\n");
 
+	ctx->w_disable1_gpio = devm_gpiod_get_optional(dev, "w-disable1", GPIOD_OUT_HIGH);
+	if (IS_ERR(ctx->w_disable1_gpio))
+		return dev_err_probe(dev, PTR_ERR(ctx->w_disable1_gpio),
+				     "Failed to get the W_DISABLE_1# GPIO\n");
+
+	ctx->w_disable2_gpio = devm_gpiod_get_optional(dev, "w-disable2", GPIOD_OUT_HIGH);
+	if (IS_ERR(ctx->w_disable2_gpio))
+		return dev_err_probe(dev, PTR_ERR(ctx->w_disable2_gpio),
+				     "Failed to get the W_DISABLE_2# GPIO\n");
+
 	ctx->num_vregs = ret;
 
 	ret = devm_add_action_or_reset(dev, pwrseq_pcie_free_resources, ctx);
@@ -151,6 +244,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

[PATCH v3 14/14] power: sequencing: pcie-m2: Create serdev device for WCN7850 bluetooth

[Manivannan Sadhasivam via B4 Relay]

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

For supporting bluetooth over the non-discoverable UART interface of
WCN7850, create the serdev device after enumerating the PCIe interface.
This is mandatory since the device ID is only known after the PCIe
enumeration and the ID is used for creating the serdev device.

Since there is no OF or ACPI table for the created serdev, a software node
is created with the 'compatible' property. This property will be used to
match the existing OF device id in the bluetooth driver.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/power/sequencing/pwrseq-pcie-m2.c | 125 +++++++++++++++++++++++++++++-
 1 file changed, 124 insertions(+), 1 deletion(-)

diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index ad94090bbdb2..7c7bde563341 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -17,6 +17,7 @@
 #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 {
@@ -26,11 +27,14 @@ struct pwrseq_pcie_m2_pdata {
 struct pwrseq_pcie_m2_ctx {
 	struct pwrseq_device *pwrseq;
 	struct device_node *of_node;
+	struct fwnode_handle *fwnode;
+	struct serdev_device *serdev;
 	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;
 
 };
@@ -179,9 +183,124 @@ static void pwrseq_pcie_free_resources(void *data)
 {
 	struct pwrseq_pcie_m2_ctx *ctx = data;
 
+	fwnode_handle_put(ctx->fwnode);
+	serdev_device_put(ctx->serdev);
+	bus_unregister_notifier(&pci_bus_type, &ctx->nb);
 	regulator_bulk_free(ctx->num_vregs, ctx->regs);
 }
 
+static const struct property_entry wcn7850_bt_props[] = {
+	PROPERTY_ENTRY_STRING("compatible", "qcom,wcn7850-bt"),
+};
+
+static int pwrseq_m2_pcie_notify(struct notifier_block *nb, unsigned long action,
+			      void *data)
+{
+	struct pwrseq_pcie_m2_ctx *ctx = container_of(nb, struct pwrseq_pcie_m2_ctx, nb);
+	struct pci_dev *pdev = to_pci_dev(data);
+	struct serdev_controller *serdev_ctrl;
+	struct device *dev = ctx->dev;
+	struct device_node *remote;
+	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, 0);
+	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;
+
+			ctx->serdev = serdev_device_alloc(serdev_ctrl);
+			if (!ctx->serdev)
+				return NOTIFY_BAD;
+
+			ctx->fwnode = fwnode_create_software_node(wcn7850_bt_props, NULL);
+			if (IS_ERR(ctx->fwnode))
+				return notifier_from_errno(PTR_ERR(ctx->fwnode));
+
+			device_set_node(&ctx->serdev->dev, ctx->fwnode);
+
+			ret = serdev_device_add(ctx->serdev);
+			if (ret) {
+				dev_err(dev, "Failed to add serdev for WCN7850: %d\n", ret);
+				fwnode_handle_put(ctx->fwnode);
+				serdev_device_put(ctx->serdev);
+				return notifier_from_errno(ret);
+			}
+		}
+		break;
+	case BUS_NOTIFY_REMOVED_DEVICE:
+		/* Destroy serdev device for WCN7850 */
+		if (pdev->vendor == PCI_VENDOR_ID_QCOM && pdev->device == 0x1107) {
+			fwnode_handle_put(ctx->fwnode);
+			serdev_device_put(ctx->serdev);
+		}
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static bool pwrseq_pcie_m2_check_remote_node(struct device *dev, u8 port, u8 endpoint,
+					     const char *node)
+{
+	struct device_node *remote __free(device_node) =
+			of_graph_get_remote_node(dev_of_node(dev), port, endpoint);
+
+	if (remote && of_node_name_eq(remote, node))
+		return true;
+
+	return false;
+}
+
+/*
+ * If the connector exposes a non-discoverable bus like UART, the respective
+ * protocol device needs to be created manually with the help of the notifier
+ * of the discoverable bus like PCIe.
+ */
+static int pwrseq_pcie_m2_register_notifier(struct pwrseq_pcie_m2_ctx *ctx, struct device *dev)
+{
+	int ret;
+
+	/*
+	 * Register a PCI notifier for Key E connector that has PCIe as Port
+	 * 0/Endpoint 0 interface and Serial as Port 1/Endpoint 1 interface.
+	 */
+	if (pwrseq_pcie_m2_check_remote_node(dev, 1, 1, "serial")) {
+		if (pwrseq_pcie_m2_check_remote_node(dev, 0, 0, "pcie")) {
+			ctx->dev = dev;
+			ctx->nb.notifier_call = pwrseq_m2_pcie_notify;
+			ret = bus_register_notifier(&pci_bus_type, &ctx->nb);
+			if (ret) {
+				dev_err_probe(dev, ret, "Failed to register notifier for serdev\n");
+				return ret;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -236,7 +355,11 @@ static int pwrseq_pcie_m2_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(ctx->pwrseq),
 				     "Failed to register the power sequencer\n");
 
-	return 0;
+	/*
+	 * Register a notifier for creating protocol devices for
+	 * non-discoverable busses like UART.
+	 */
+	return pwrseq_pcie_m2_register_notifier(ctx, dev);
 }
 
 static const struct of_device_id pwrseq_pcie_m2_of_match[] = {

-- 
2.48.1

Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Andy Shevchenko]

On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay 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 DT compatible for the serdev swnode to match the existing OF
> device_id of the bluetooth driver. This avoids implementing custom serdev id
> matching as implemented till v2.

Yeah, swnodes are not designed to replace the real DT or other firmware
interface. The idea of swnodes is to have them providing quirks if needed (i.e.
fixing up the broken or missed FW device properties). This should not have been
done this way. Please, consider another approach, e.g. DT-overlay.

> 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> the PCIe device DT node to extract properties such as
> 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> add the PCIe DT node in the Root Port in conjunction with the Port node as
> below?
> 
> pcie@0 {
> 	wifi@0 {
> 		compatible = "pci17cb,1103";
> 		...
> 		qcom,calibration-variant = "LE_X13S";
> 	};
> 
> 	port {
> 		pcie4_port0_ep: endpoint {
> 			remote-endpoint = <&m2_e_pcie_ep>;
> 		};
> 	};
> };
> 
> This will also require marking the PMU supplies optional in the relevant ath
> bindings for M.2 cards.
> 
> 3. Some M.2 cards require specific power up sequence like delays between
> regulator/GPIO and such. For instance, the WCN7850 card supported in this series
> requires 50ms delay between powering up an interface and driving it. I've just
> hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
> driver doesn't know anything about the device it is dealing with before powering
> it ON, how should it handle the device specific power requirements? Should we
> hardcode the device specific property in the connector node? But then, it will
> no longer become a generic M.2 connector and sort of defeats the purpose of the
> connector binding.
> 
> I hope to address these questions with the help of the relevant subsystem
> maintainers and the community. 
> 
> Testing
> =======
> 
> This series, together with the devicetree changes [2] was tested on the
> Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> 1620 LGA card connected over PCIe and UART.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Andy Shevchenko]

+Cc: Herve (btw, any news on LAN966x support?)

On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay 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 DT compatible for the serdev swnode to match the existing OF
> > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > matching as implemented till v2.
> 
> Yeah, swnodes are not designed to replace the real DT or other firmware
> interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> fixing up the broken or missed FW device properties). This should not have been
> done this way. Please, consider another approach, e.g. DT-overlay.

This is what I have in mind when replied to you:

https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/

> > 2. PCIe client drivers of some M.2 WLAN cards like the Qcom QCA6390, rely on
> > the PCIe device DT node to extract properties such as
> > 'qcom,calibration-variant', 'firmware-name', etc... For those drivers, should we
> > add the PCIe DT node in the Root Port in conjunction with the Port node as
> > below?
> > 
> > pcie@0 {
> > 	wifi@0 {
> > 		compatible = "pci17cb,1103";
> > 		...
> > 		qcom,calibration-variant = "LE_X13S";
> > 	};
> > 
> > 	port {
> > 		pcie4_port0_ep: endpoint {
> > 			remote-endpoint = <&m2_e_pcie_ep>;
> > 		};
> > 	};
> > };
> > 
> > This will also require marking the PMU supplies optional in the relevant ath
> > bindings for M.2 cards.
> > 
> > 3. Some M.2 cards require specific power up sequence like delays between
> > regulator/GPIO and such. For instance, the WCN7850 card supported in this series
> > requires 50ms delay between powering up an interface and driving it. I've just
> > hardcoded the delay in the driver, but it is a pure hack. Since the pwrseq
> > driver doesn't know anything about the device it is dealing with before powering
> > it ON, how should it handle the device specific power requirements? Should we
> > hardcode the device specific property in the connector node? But then, it will
> > no longer become a generic M.2 connector and sort of defeats the purpose of the
> > connector binding.
> > 
> > I hope to address these questions with the help of the relevant subsystem
> > maintainers and the community. 
> > 
> > Testing
> > =======
> > 
> > This series, together with the devicetree changes [2] was tested on the
> > Qualcomm X1e based Lenovo Thinkpad T14s Laptop which has the WCN7850 WLAN/BT
> > 1620 LGA card connected over PCIe and UART.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Herve Codina]

Hi Andy, Manivannan,

On Mon, 12 Jan 2026 10:18:41 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> +Cc: Herve (btw, any news on LAN966x support?)

Related to LAN966x support, I am still stucked on issues related to
fw_devlink and DT overlays [1].

[1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/

> 
> On Mon, Jan 12, 2026 at 10:04:24AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay 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.

Related to describing a connector in DT. If DT overlays are involved to described
what is connected to this connector, some issues need to be fixed.

Those issues are related to referencing an external symbol from the overlay.

We, at Boolin, have been working on the topic

A talk (last year at ELC Europe) gives all details about the topic an related issue:
  https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
  https://www.youtube.com/watch?v=C8dEQ4OzMnc

Also a discussion took place after this talk:
  https://lore.kernel.org/all/20250902105710.00512c6d@booty/

Recently, I also send a RFC series to DTC in order to move forward on this symbol
reverence topic. This series implements features emerged from the pointed out
discussion.

> > > 
> > > 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 DT compatible for the serdev swnode to match the existing OF
> > > device_id of the bluetooth driver. This avoids implementing custom serdev id
> > > matching as implemented till v2.  
> > 
> > Yeah, swnodes are not designed to replace the real DT or other firmware
> > interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> > fixing up the broken or missed FW device properties). This should not have been
> > done this way. Please, consider another approach, e.g. DT-overlay.  
> 
> This is what I have in mind when replied to you:
> 
> https://lore.kernel.org/all/20251015071420.1173068-1-herve.codina@bootlin.com/
> 
> > > 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>;
> > > 		};
> > > 	};
> > > };

Using mechanisms used by the LAN966x, those wifi@0 and port nodes could be added by
a DT overlay by the PCI device driver handling the Qcom QCA6390 PCI device.

Best regards,
Hervé

Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Andy Shevchenko]

On Wed, Jan 14, 2026 at 01:40:04PM +0100, Herve Codina wrote:
> On Mon, 12 Jan 2026 10:18:41 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > +Cc: Herve (btw, any news on LAN966x support?)
> 
> Related to LAN966x support, I am still stucked on issues related to
> fw_devlink and DT overlays [1].

Thank you for the update and your reply here!

> [1] https://lore.kernel.org/all/20260112154731.6540453b@bootlin.com/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

[Bartosz Golaszewski]

On Mon, 12 Jan 2026 09:04:15 +0100, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> said:
> On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>>

[snip]

>> 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 DT compatible for the serdev swnode to match the existing OF
>> device_id of the bluetooth driver. This avoids implementing custom serdev id
>> matching as implemented till v2.
>
> Yeah, swnodes are not designed to replace the real DT or other firmware
> interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> fixing up the broken or missed FW device properties). This should not have been
> done this way. Please, consider another approach, e.g. DT-overlay.
>

This may have been true historically but software nodes were introduced before
the auxiliary bus. With platform devices, the question has a clear response:
DT or ACPI first, then possibly additional software node. But with auxiliary
devices, where does the entirety of device properties come from if we - for
whatever reason - don't want to propagate any "real" firmware node?

This is not even about this particular series, rather it's a wider architecture
question.

Bartosz