[PATCH RFC 0/2] of: property: Make fw_devlink follow GPIO and PWM nexus maps

[PATCH RFC 0/2] of: property: Make fw_devlink follow GPIO and PWM nexus maps

[Ernest Van Hoecke]

This series fixes an fw_devlink supplier-resolution problem reported by
Leonardo Costa while using a Devicetree nexus to describe GPIO and PWM
resources routed through an LVDS connector. Consumers referencing the
nexus could remain deferred because fw_devlink linked them to the nexus
rather than to the providers selected by gpio-map and pwm-map. [1]

GPIO and PWM consumer APIs use of_parse_phandle_with_args_map() to
resolve specifiers through gpio-map and pwm-map properties. The
corresponding fw_devlink parsers use direct phandle parsing instead.
Given a consumer which references a nexus, the consumer API and
fw_devlink therefore resolve the reference to different nodes:

  consumer API:  consumer -> nexus -> mapped provider
  fw_devlink:    consumer -> nexus

A nexus is a translation node rather than the resource provider and need
not have a driver. The link to it can consequently remain unresolved and
defer the consumer even though the mapped provider is available.

Make the fw_devlink GPIO and PWM parsers use the same map-aware resolver
as their consumer APIs. The resolver also handles valid direct
references by returning the original provider when no map is present.
Use dedicated exact-name and suffix declaration macros to opt these
bindings into map-aware parsing without changing unrelated property
parsers. Retain GPIO's existing exclusions and compatibility handling.

The regression tests call the OF add_links operation and verify that a
mapped reference creates exactly one link to the final provider, not to
the nexus. They also cover valid direct references. The GPIO tests
exercise all property spellings recognized by fw_devlink, including the
deprecated singular and unprefixed forms.

Tested with:
  - The new CONFIG_OF_UNITTEST fw_devlink cases under QEMU/x86_64 all
    passed
  - W=1 builds on x86_64 and arm64, including the OF unittest data
  - Toradex Verdin iMX8M Plus hardware using a connector nexus for the
    display GPIO and PWM resources: the display probes successfully

Sending as an RFC because the unittest part can use some polish, but I
wanted to gather feedback on the direction before doing so.

[1] https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/

Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

---
Ernest Van Hoecke (2):
      of: property: fw_devlink: Follow GPIO nexus maps
      of: property: fw_devlink: Follow PWM nexus maps

 drivers/of/property.c                       | 49 +++++++++++++++-----
 drivers/of/unittest-data/tests-phandle.dtsi | 49 ++++++++++++++++++++
 drivers/of/unittest.c                       | 71 +++++++++++++++++++++++++++++
 3 files changed, 158 insertions(+), 11 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260901-fw-devlink-nexus-ready-c859706b019d

Best regards,
-- 
Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

[PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Ernest Van Hoecke]

From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
through gpio-map properties. fw_devlink instead parses GPIO properties as
direct phandle references, so it records the nexus node as the supplier
rather than the mapped GPIO provider.

A nexus is a translation node, not the GPIO provider, and need not be
populated as a device. The resulting fwnode link can therefore remain
unresolved and indefinitely defer the consumer while
device_links_check_suppliers() waits for the nexus.

Use the map-aware parser for all supported GPIO property spellings. This
makes fw_devlink resolve the same provider as the GPIO consumer API. Direct
GPIO references continue to work because the map-aware parser returns the
original provider when no gpio-map property is present.

Add OF unittest coverage for mapped and direct GPIO suppliers, including
the deprecated singular and unprefixed property spellings.

Fixes: 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)")
Reported-by: Leonardo Costa <leonardo.costa@toradex.com>
Link: https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
Tested-by: Leonardo Costa <leonardo.costa@toradex.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
---
 drivers/of/property.c                       | 38 +++++++++++-----
 drivers/of/unittest-data/tests-phandle.dtsi | 33 ++++++++++++++
 drivers/of/unittest.c                       | 67 +++++++++++++++++++++++++++++
 3 files changed, 128 insertions(+), 10 deletions(-)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 72cf12907de0..380df0861ab9 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1311,6 +1311,19 @@ static struct device_node *parse_prop_cells(struct device_node *np,
 	return sup_args.np;
 }
 
+static struct device_node *parse_nexus_prop(struct device_node *np,
+					    const char *prop_name, int index,
+					    const char *stem_name)
+{
+	struct of_phandle_args sup_args;
+
+	if (of_parse_phandle_with_args_map(np, prop_name, stem_name, index,
+					   &sup_args))
+		return NULL;
+
+	return sup_args.np;
+}
+
 #define DEFINE_SIMPLE_PROP(fname, name, cells)				  \
 static struct device_node *parse_##fname(struct device_node *np,	  \
 					const char *prop_name, int index) \
@@ -1361,6 +1374,15 @@ static struct device_node *parse_##fname(struct device_node *np,	     \
 	return parse_suffix_prop_cells(np, prop_name, index, suffix, cells); \
 }
 
+#define DEFINE_SUFFIX_NEXUS_PROP(fname, suffix, stem)			     \
+static struct device_node *parse_##fname(struct device_node *np,	     \
+					const char *prop_name, int index)    \
+{									     \
+	if (!strends(prop_name, suffix))				     \
+		return NULL;						     \
+	return parse_nexus_prop(np, prop_name, index, stem);		     \
+}
+
 /**
  * struct supplier_bindings - Property parsing functions for suppliers
  *
@@ -1416,7 +1438,7 @@ DEFINE_SIMPLE_PROP(pses, "pses", "#pse-cells")
 DEFINE_SIMPLE_PROP(power_supplies, "power-supplies", NULL)
 DEFINE_SIMPLE_PROP(mmc_pwrseq, "mmc-pwrseq", NULL)
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
-DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
+DEFINE_SUFFIX_NEXUS_PROP(gpio, "-gpio", "gpio")
 
 static struct device_node *parse_pinctrl_n(struct device_node *np,
 					   const char *prop_name, int index)
@@ -1436,8 +1458,10 @@ static struct device_node *parse_gpios(struct device_node *np,
 	if (strends(prop_name, ",nr-gpios"))
 		return NULL;
 
-	return parse_suffix_prop_cells(np, prop_name, index, "-gpios",
-				       "#gpio-cells");
+	if (!strends(prop_name, "-gpios"))
+		return NULL;
+
+	return parse_nexus_prop(np, prop_name, index, "gpio");
 }
 
 static struct device_node *parse_iommu_maps(struct device_node *np,
@@ -1452,8 +1476,6 @@ static struct device_node *parse_iommu_maps(struct device_node *np,
 static struct device_node *parse_gpio_compat(struct device_node *np,
 					     const char *prop_name, int index)
 {
-	struct of_phandle_args sup_args;
-
 	if (strcmp(prop_name, "gpio") && strcmp(prop_name, "gpios"))
 		return NULL;
 
@@ -1464,11 +1486,7 @@ static struct device_node *parse_gpio_compat(struct device_node *np,
 	if (of_property_read_bool(np, "gpio-hog"))
 		return NULL;
 
-	if (of_parse_phandle_with_args(np, prop_name, "#gpio-cells", index,
-				       &sup_args))
-		return NULL;
-
-	return sup_args.np;
+	return parse_nexus_prop(np, prop_name, index, "gpio");
 }
 
 static struct device_node *parse_interrupts(struct device_node *np,
diff --git a/drivers/of/unittest-data/tests-phandle.dtsi b/drivers/of/unittest-data/tests-phandle.dtsi
index 554a996b2ef1..163ef07be16d 100644
--- a/drivers/of/unittest-data/tests-phandle.dtsi
+++ b/drivers/of/unittest-data/tests-phandle.dtsi
@@ -79,6 +79,39 @@ consumer-b {
 				phandle-list-bad-args = <&provider2 1 0>,
 							<&provider4 0>;
 			};
+
+			fw-devlink-tests {
+				gpio_provider: gpio-controller {
+					#gpio-cells = <2>;
+				};
+
+				test_nexus: nexus {
+					#gpio-cells = <2>;
+					gpio-map = <0 0 &gpio_provider 1 0>;
+					gpio-map-mask = <0xffffffff 0>;
+					gpio-map-pass-thru = <0 0xffffffff>;
+				};
+
+				gpio-compat-consumer {
+					gpios = <&test_nexus 0 0>;
+				};
+
+				gpio-compat-singular-consumer {
+					gpio = <&test_nexus 0 0>;
+				};
+
+				gpio-consumer {
+					test-gpios = <&test_nexus 0 0>;
+				};
+
+				gpio-direct-consumer {
+					test-gpios = <&gpio_provider 1 0>;
+				};
+
+				gpio-singular-consumer {
+					test-gpio = <&test_nexus 0 0>;
+				};
+			};
 		};
 	};
 };
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e255f54f4d76..487f3b629a73 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -10,6 +10,7 @@
 #include <linux/dma-direct.h> /* to test phys_to_dma/dma_to_phys */
 #include <linux/err.h>
 #include <linux/errno.h>
+#include <linux/fwnode.h>
 #include <linux/hashtable.h>
 #include <linux/libfdt.h>
 #include <linux/of.h>
@@ -710,6 +711,71 @@ static void __init of_unittest_parse_phandle_with_args_map(void)
 	}
 }
 
+static void __init of_unittest_fw_devlink_supplier(struct device_node *tests,
+						   const char *consumer_name,
+						   const char *supplier_name)
+{
+	struct device_node *consumer, *supplier;
+	struct fwnode_handle *consumer_fwnode;
+	struct fwnode_link *link;
+	unsigned int link_count = 0;
+	bool found = false;
+	int rc;
+
+	consumer = of_get_child_by_name(tests, consumer_name);
+	supplier = of_get_child_by_name(tests, supplier_name);
+	if (!consumer || !supplier) {
+		pr_err("missing consumer %s or supplier %s\n", consumer_name, supplier_name);
+		goto put_nodes;
+	}
+
+	consumer_fwnode = of_fwnode_handle(consumer);
+	fwnode_links_purge(consumer_fwnode);
+	rc = fwnode_call_int_op(consumer_fwnode, add_links);
+	if (unittest(!rc, "failed to add links for %pOF: %d\n", consumer, rc))
+		goto purge_links;
+
+	/*
+	 * fwnode_link_lock is private to the driver core. These test nodes are
+	 * isolated and no one should modify their links now, so it is safe to
+	 * inspect the supplier list without the lock here.
+	 */
+	list_for_each_entry(link, &consumer_fwnode->suppliers, c_hook) {
+		link_count++;
+		if (link->supplier == of_fwnode_handle(supplier))
+			found = true;
+	}
+
+	unittest(link_count == 1, "%pOF has %u suppliers, expected 1\n", consumer, link_count);
+	unittest(found, "%pOF is not linked to supplier %pOF\n", consumer, supplier);
+
+purge_links:
+	fwnode_links_purge(consumer_fwnode);
+put_nodes:
+	of_node_put(consumer);
+	of_node_put(supplier);
+}
+
+static void __init of_unittest_fw_devlink(void)
+{
+	const char *gpio_supplier = "gpio-controller";
+	struct device_node *tests;
+
+	tests = of_find_node_by_path("/testcase-data/phandle-tests/fw-devlink-tests");
+	if (!tests) {
+		pr_err("missing fw_devlink test data\n");
+		return;
+	}
+
+	of_unittest_fw_devlink_supplier(tests, "gpio-compat-consumer", gpio_supplier);
+	of_unittest_fw_devlink_supplier(tests, "gpio-compat-singular-consumer", gpio_supplier);
+	of_unittest_fw_devlink_supplier(tests, "gpio-consumer", gpio_supplier);
+	of_unittest_fw_devlink_supplier(tests, "gpio-direct-consumer", gpio_supplier);
+	of_unittest_fw_devlink_supplier(tests, "gpio-singular-consumer", gpio_supplier);
+
+	of_node_put(tests);
+}
+
 static void __init of_unittest_property_string(void)
 {
 	const char *strings[4];
@@ -4533,6 +4599,7 @@ static int __init of_unittest(void)
 	of_unittest_dynamic();
 	of_unittest_parse_phandle_with_args();
 	of_unittest_parse_phandle_with_args_map();
+	of_unittest_fw_devlink();
 	of_unittest_printf();
 	of_unittest_property_string();
 	of_unittest_property_copy();

-- 
2.43.0

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Infinite loop in `of_parse_phandle_with_args_map` due to lack of cycle detection when parsing `*-map` properties.
--

commit 97ac59dad65377a6557c6606a4f1c695b9fd0847
Author: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

of: property: fw_devlink: Follow GPIO nexus maps

This commit updates fw_devlink to parse GPIO properties using the map-aware
parser of_parse_phandle_with_args_map() instead of treating them as direct
phandle references. This ensures fw_devlink identifies the correct GPIO
provider rather than a translation nexus, and adds corresponding unittest
coverage.

Link: https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/

> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 72cf12907de03..380df0861ab97 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
[ ... ]
> @@ -1311,6 +1311,19 @@ static struct device_node *parse_prop_cells(struct device_node *np,
>  	return sup_args.np;
>  }
>  
> +static struct device_node *parse_nexus_prop(struct device_node *np,
> +					    const char *prop_name, int index,
> +					    const char *stem_name)
> +{
> +	struct of_phandle_args sup_args;
> +
> +	if (of_parse_phandle_with_args_map(np, prop_name, stem_name, index,
> +					   &sup_args))

[Severity: Medium]
This is a pre-existing issue, but does of_parse_phandle_with_args_map() lack
cycle detection when parsing *-map properties?

Looking at of_parse_phandle_with_args_map() in drivers/of/base.c, the loop
that follows mapping indirection lacks a cycle breaker:

drivers/of/base.c:of_parse_phandle_with_args_map() {
    ...
	while (cur) {
		/* Get the <list>-map property */
		map = of_get_property(cur, map_name, &map_len);
    ...
		out_args->np = new;
		of_node_put(cur);
		cur = new;
		new = NULL;
	}
    ...
}

If a cyclic device tree overlay introduces a cycle in the *-map properties,
could this while (cur) loop indefinitely follow the mapping indirection
and cause a denial of service? The function seems to jump directly to
reassigning cur = new and restarting the traversal without any cycle-breaking
or visited-node verification.

> +		return NULL;
> +
> +	return sup_args.np;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-fw-devlink-nexus-ready-v1-0-68fe1996e78a@toradex.com?part=1

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Bartosz Golaszewski]

On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
<ernestvanhoecke@gmail.com> said:
> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>
> GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
> through gpio-map properties. fw_devlink instead parses GPIO properties as

Unlike PWM, there's no such thing as "gpio-map" properties.

> direct phandle references, so it records the nexus node as the supplier
> rather than the mapped GPIO provider.
>

Can you point me to an example? I'm not sure what a nexus node is in the
context of GPIO.

> A nexus is a translation node, not the GPIO provider, and need not be
> populated as a device. The resulting fwnode link can therefore remain
> unresolved and indefinitely defer the consumer while
> device_links_check_suppliers() waits for the nexus.
>
> Use the map-aware parser for all supported GPIO property spellings. This
> makes fw_devlink resolve the same provider as the GPIO consumer API. Direct
> GPIO references continue to work because the map-aware parser returns the
> original provider when no gpio-map property is present.
>
> Add OF unittest coverage for mapped and direct GPIO suppliers, including
> the deprecated singular and unprefixed property spellings.
>

Since this is a fix that we may want to backport, the unit tests should go in
a separate, follow-up commit.

Bart

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Ernest Van Hoecke]

On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
> On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
> <ernestvanhoecke@gmail.com> said:
> > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> >
> > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
> > through gpio-map properties. fw_devlink instead parses GPIO properties as
> 
> Unlike PWM, there's no such thing as "gpio-map" properties.
> 
Hi Bartosz,

bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a
nexus node") added support for nexus nodes, and then c11e6f0f04db ("gpio:
Support gpio nexus dt bindings") added support for "gpio-map".

Herve later added support for pwm nexus dt bindings modeled on the GPIO
support in e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings").

Please let me know if I misunderstood something.

> > direct phandle references, so it records the nexus node as the supplier
> > rather than the mapped GPIO provider.
> >
> 
> Can you point me to an example? I'm not sure what a nexus node is in the
> context of GPIO.

Stephen gave an example usage in his commit message implementing
of_parse_phandle_with_args_map():
	soc {
	        soc_gpio1: gpio-controller1 {
	                #gpio-cells = <2>;
	        };
	
	        soc_gpio2: gpio-controller2 {
	                #gpio-cells = <2>;
	        };
	};

	connector: connector {
	        #gpio-cells = <2>;
	        gpio-map = <0 0 &soc_gpio1 1 0>,
	                   <1 0 &soc_gpio2 4 0>,
	                   <2 0 &soc_gpio1 3 0>,
	                   <3 0 &soc_gpio2 2 0>;
	        gpio-map-mask = <0xf 0x0>;
        	gpio-map-pass-thru = <0x0 0x1>
	};

	expansion_device {
        	reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
	};

Admittedly, this hasn't seen much (any?) actual use in the device trees
yet.

We (Toradex) would like to use it to specify a LVDS connector on our
boards. This connector appears on different carrier boards that all mate
with the same display and have the same pinout. The only potential
difference is which PWMs and GPIOs are connected to the connector.

There, specifying the LVDS connector as a nexus node on the relevant
carrier board DTS/DTSI would allow us to reuse the same display overlay.
That example usage is given by Leonardo Costa here:
https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
Note how we have the connector on imx8mp-verdin-dev.dtsi but could also
add it to other boards, i.e: imx8mp-verdin-mallow.dtsi

Note that in that example we used the "tdx,verdin-lvds-connector"
compatible for the connector. Since this is a nexus node and just a
dumb connector without driver, not having a compatible would make sense.
In a final implementation we could specify a compatible + binding if
that specifies the ABI better. It is not entirely clear to me what is
preferred at the moment, but that is disconnected from this patch
series.

> 
> > A nexus is a translation node, not the GPIO provider, and need not be
> > populated as a device. The resulting fwnode link can therefore remain
> > unresolved and indefinitely defer the consumer while
> > device_links_check_suppliers() waits for the nexus.
> >
> > Use the map-aware parser for all supported GPIO property spellings. This
> > makes fw_devlink resolve the same provider as the GPIO consumer API. Direct
> > GPIO references continue to work because the map-aware parser returns the
> > original provider when no gpio-map property is present.
> >
> > Add OF unittest coverage for mapped and direct GPIO suppliers, including
> > the deprecated singular and unprefixed property spellings.
> >
> 
> Since this is a fix that we may want to backport, the unit tests should go in
> a separate, follow-up commit.
> 
> Bart

Thanks for the feedback, if we want to go with the direction proposed
here I'll make sure to split it off in future series, I was unsure about
that.

Since usage of this nexus system seems limited, I'm also not sure if we
need to backport but it technically is a fix.

Kind regards,
Ernest

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Herve Codina]

Hi Ernest, Bartosz,

On Wed, 2 Sep 2026 15:22:36 +0200
Ernest Van Hoecke <ernestvanhoecke@gmail.com> wrote:

> On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
> > On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
> > <ernestvanhoecke@gmail.com> said:  
> > > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > >
> > > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
> > > through gpio-map properties. fw_devlink instead parses GPIO properties as  
> > 
> > Unlike PWM, there's no such thing as "gpio-map" properties.
> >   
> Hi Bartosz,
> 
> bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a
> nexus node") added support for nexus nodes, and then c11e6f0f04db ("gpio:
> Support gpio nexus dt bindings") added support for "gpio-map".
> 
> Herve later added support for pwm nexus dt bindings modeled on the GPIO
> support in e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings").
> 
> Please let me know if I misunderstood something.
> 
> > > direct phandle references, so it records the nexus node as the supplier
> > > rather than the mapped GPIO provider.
> > >  
> > 
> > Can you point me to an example? I'm not sure what a nexus node is in the
> > context of GPIO.  
> 
> Stephen gave an example usage in his commit message implementing
> of_parse_phandle_with_args_map():
> 	soc {
> 	        soc_gpio1: gpio-controller1 {
> 	                #gpio-cells = <2>;
> 	        };
> 	
> 	        soc_gpio2: gpio-controller2 {
> 	                #gpio-cells = <2>;
> 	        };
> 	};
> 
> 	connector: connector {
> 	        #gpio-cells = <2>;
> 	        gpio-map = <0 0 &soc_gpio1 1 0>,
> 	                   <1 0 &soc_gpio2 4 0>,
> 	                   <2 0 &soc_gpio1 3 0>,
> 	                   <3 0 &soc_gpio2 2 0>;
> 	        gpio-map-mask = <0xf 0x0>;
>         	gpio-map-pass-thru = <0x0 0x1>
> 	};
> 
> 	expansion_device {
>         	reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
> 	};

The binding is available in dtschema
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/gpio/gpio-nexus-node.yaml

And the gpio case is mentionned in the Devicetree Specification
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#specifier-mapping-example

> 
> Admittedly, this hasn't seen much (any?) actual use in the device trees
> yet.

Not yet in actual device trees but needed for handling hotpluging of extension
boards.

For instance you can see at the following patch [1]
https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/

tests/fdtaddon_realistic_base.dts [2] describes a nexus node for gpios allowing
to use "gpio 1 available at the connector" from the dtsa instead of "gpio 3
provided by the GPIO A controller". This allow to decouple extension boards and
base board. The common part is the connector. Extension boards dts uses
resources available at the connector while base board dts "wires" resources to
the connector. A translation in needed and Nexus nodes are part of this
translation.

tests/fdtaddon_realistic_addon.dtsa [3] uses a gpio that is translated thanks
to the nexus node:
--- 8< ---
  /* Use the connector gpio number 1 */
  reset-gpios = <&connector 1 0>;
--- 8< ---


[1] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/
[2] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/#Z31tests:fdtaddon_realistic_base.dts
[3] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/#Z31tests:fdtaddon_realistic_addon.dtsa


> 
> We (Toradex) would like to use it to specify a LVDS connector on our
> boards. This connector appears on different carrier boards that all mate
> with the same display and have the same pinout. The only potential
> difference is which PWMs and GPIOs are connected to the connector.
> 
> There, specifying the LVDS connector as a nexus node on the relevant
> carrier board DTS/DTSI would allow us to reuse the same display overlay.
> That example usage is given by Leonardo Costa here:
> https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
> Note how we have the connector on imx8mp-verdin-dev.dtsi but could also
> add it to other boards, i.e: imx8mp-verdin-mallow.dtsi
> 
> Note that in that example we used the "tdx,verdin-lvds-connector"
> compatible for the connector. Since this is a nexus node and just a
> dumb connector without driver, not having a compatible would make sense.
> In a final implementation we could specify a compatible + binding if
> that specifies the ABI better. It is not entirely clear to me what is
> preferred at the moment, but that is disconnected from this patch
> series.

Hum, do you have a look at [4] ?
You could be interrested by this work?

[4] https://lore.kernel.org/all/20260826094950.1088288-1-herve.codina@bootlin.com/

> 
> >   
> > > A nexus is a translation node, not the GPIO provider, and need not be
> > > populated as a device. The resulting fwnode link can therefore remain
> > > unresolved and indefinitely defer the consumer while
> > > device_links_check_suppliers() waits for the nexus.
> > >
> > > Use the map-aware parser for all supported GPIO property spellings. This
> > > makes fw_devlink resolve the same provider as the GPIO consumer API. Direct
> > > GPIO references continue to work because the map-aware parser returns the
> > > original provider when no gpio-map property is present.
> > >
> > > Add OF unittest coverage for mapped and direct GPIO suppliers, including
> > > the deprecated singular and unprefixed property spellings.
> > >  
> > 
> > Since this is a fix that we may want to backport, the unit tests should go in
> > a separate, follow-up commit.
> > 
> > Bart  
> 
> Thanks for the feedback, if we want to go with the direction proposed
> here I'll make sure to split it off in future series, I was unsure about
> that.
> 
> Since usage of this nexus system seems limited, I'm also not sure if we
> need to backport but it technically is a fix.

Not sure it is so limited :)

Also, I agree with both patches (PWM and GPIO).

fw_devlink should use the end device and not the first nexus node.

Best regards,
Hervé

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Miquel Raynal]

Hello Ernest,

On 02/09/2026 at 18:55:13 +02, Herve Codina <herve.codina@bootlin.com> wrote:

> Hi Ernest, Bartosz,
>
> On Wed, 2 Sep 2026 15:22:36 +0200
> Ernest Van Hoecke <ernestvanhoecke@gmail.com> wrote:
>
>> On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
>> > On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
>> > <ernestvanhoecke@gmail.com> said:  
>> > > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>> > >
>> > > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
>> > > through gpio-map properties. fw_devlink instead parses GPIO properties as  
>> > 
>> > Unlike PWM, there's no such thing as "gpio-map" properties.

Just as an FYI, there is a pending series to extend the nexus
node concept to clocks, this may also require some fw-devlink magic :-)

Link: https://lore.kernel.org/linux-clk/20260807-schneider-v7-2-rc1-eip201-upstream-v5-0-8785f9531cf0@bootlin.com/T/#m16ddef087544db31b5f434fa44be70aad0b5e37e

Thanks,
Miquèl

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Ernest Van Hoecke]

On Thu, Sep 03, 2026 at 11:57:58AM +0200, Miquel Raynal wrote:
> Hello Ernest,
> 
> On 02/09/2026 at 18:55:13 +02, Herve Codina <herve.codina@bootlin.com> wrote:
> 
> > Hi Ernest, Bartosz,
> >
> > On Wed, 2 Sep 2026 15:22:36 +0200
> > Ernest Van Hoecke <ernestvanhoecke@gmail.com> wrote:
> >
> >> On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
> >> > On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
> >> > <ernestvanhoecke@gmail.com> said:  
> >> > > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> >> > >
> >> > > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
> >> > > through gpio-map properties. fw_devlink instead parses GPIO properties as  
> >> > 
> >> > Unlike PWM, there's no such thing as "gpio-map" properties.
> 
> Just as an FYI, there is a pending series to extend the nexus
> node concept to clocks, this may also require some fw-devlink magic :-)
> 
> Link: https://lore.kernel.org/linux-clk/20260807-schneider-v7-2-rc1-eip201-upstream-v5-0-8785f9531cf0@bootlin.com/T/#m16ddef087544db31b5f434fa44be70aad0b5e37e
> 
> Thanks,
> Miquèl

Hi Miquèl,

That's the reason I put you in cc and also the reason I went for new
NEXUS macros in this series. Clock would hopefully be the next consumer
of that :)

I should've mentioned that more explicitly in my cover letter. Your work
on the clock nexus can certainly come in handy for us, thanks for your
input.

Kind regards,
Ernest

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Ernest Van Hoecke]

Hi Hervé,

On Wed, Sep 02, 2026 at 06:55:13PM +0200, Herve Codina wrote:
> Hi Ernest, Bartosz,
> 
> On Wed, 2 Sep 2026 15:22:36 +0200
> Ernest Van Hoecke <ernestvanhoecke@gmail.com> wrote:
> 
> > On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
> > > On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
> > > <ernestvanhoecke@gmail.com> said:  
> > > > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > >
> > > > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
> > > > through gpio-map properties. fw_devlink instead parses GPIO properties as  
> > > 
> > > Unlike PWM, there's no such thing as "gpio-map" properties.
> > >   
> > Hi Bartosz,
> > 
> > bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a
> > nexus node") added support for nexus nodes, and then c11e6f0f04db ("gpio:
> > Support gpio nexus dt bindings") added support for "gpio-map".
> > 
> > Herve later added support for pwm nexus dt bindings modeled on the GPIO
> > support in e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings").
> > 
> > Please let me know if I misunderstood something.
> > 
> > > > direct phandle references, so it records the nexus node as the supplier
> > > > rather than the mapped GPIO provider.
> > > >  
> > > 
> > > Can you point me to an example? I'm not sure what a nexus node is in the
> > > context of GPIO.  
> > 
> > Stephen gave an example usage in his commit message implementing
> > of_parse_phandle_with_args_map():
> > 	soc {
> > 	        soc_gpio1: gpio-controller1 {
> > 	                #gpio-cells = <2>;
> > 	        };
> > 	
> > 	        soc_gpio2: gpio-controller2 {
> > 	                #gpio-cells = <2>;
> > 	        };
> > 	};
> > 
> > 	connector: connector {
> > 	        #gpio-cells = <2>;
> > 	        gpio-map = <0 0 &soc_gpio1 1 0>,
> > 	                   <1 0 &soc_gpio2 4 0>,
> > 	                   <2 0 &soc_gpio1 3 0>,
> > 	                   <3 0 &soc_gpio2 2 0>;
> > 	        gpio-map-mask = <0xf 0x0>;
> >         	gpio-map-pass-thru = <0x0 0x1>
> > 	};
> > 
> > 	expansion_device {
> >         	reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
> > 	};
> 
> The binding is available in dtschema
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/gpio/gpio-nexus-node.yaml
> 
> And the gpio case is mentionned in the Devicetree Specification
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#specifier-mapping-example
> 
> > 
> > Admittedly, this hasn't seen much (any?) actual use in the device trees
> > yet.
> 
> Not yet in actual device trees but needed for handling hotpluging of extension
> boards.
> 
> For instance you can see at the following patch [1]
> https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/
> 
> tests/fdtaddon_realistic_base.dts [2] describes a nexus node for gpios allowing
> to use "gpio 1 available at the connector" from the dtsa instead of "gpio 3
> provided by the GPIO A controller". This allow to decouple extension boards and
> base board. The common part is the connector. Extension boards dts uses
> resources available at the connector while base board dts "wires" resources to
> the connector. A translation in needed and Nexus nodes are part of this
> translation.
> 
> tests/fdtaddon_realistic_addon.dtsa [3] uses a gpio that is translated thanks
> to the nexus node:
> --- 8< ---
>   /* Use the connector gpio number 1 */
>   reset-gpios = <&connector 1 0>;
> --- 8< ---
> 
> 
> [1] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/
> [2] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/#Z31tests:fdtaddon_realistic_base.dts
> [3] https://lore.kernel.org/all/20260826094950.1088288-73-herve.codina@bootlin.com/#Z31tests:fdtaddon_realistic_addon.dtsa
> 

Thanks for explaining and linking your use cases here as well.

> 
> > 
> > We (Toradex) would like to use it to specify a LVDS connector on our
> > boards. This connector appears on different carrier boards that all mate
> > with the same display and have the same pinout. The only potential
> > difference is which PWMs and GPIOs are connected to the connector.
> > 
> > There, specifying the LVDS connector as a nexus node on the relevant
> > carrier board DTS/DTSI would allow us to reuse the same display overlay.
> > That example usage is given by Leonardo Costa here:
> > https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
> > Note how we have the connector on imx8mp-verdin-dev.dtsi but could also
> > add it to other boards, i.e: imx8mp-verdin-mallow.dtsi
> > 
> > Note that in that example we used the "tdx,verdin-lvds-connector"
> > compatible for the connector. Since this is a nexus node and just a
> > dumb connector without driver, not having a compatible would make sense.
> > In a final implementation we could specify a compatible + binding if
> > that specifies the ABI better. It is not entirely clear to me what is
> > preferred at the moment, but that is disconnected from this patch
> > series.
> 
> Hum, do you have a look at [4] ?
> You could be interrested by this work?
> 
> [4] https://lore.kernel.org/all/20260826094950.1088288-1-herve.codina@bootlin.com/
> 

Yes, we've started looking into it and are very interested in the work
on the connector concept.

Here, we can use nexus nodes to simplify an LVDS connector and share one
overlay for multiple carrier boards, but without a real generic
connector, we still have a lot of combinations we need to support, and
we cannot point to one specific connector on a board. The connector idea
would allow making our overlays more generic and reusing more. We will
be looking into it more. Thanks for your work on this!

> > 
> > >   
> > > > A nexus is a translation node, not the GPIO provider, and need not be
> > > > populated as a device. The resulting fwnode link can therefore remain
> > > > unresolved and indefinitely defer the consumer while
> > > > device_links_check_suppliers() waits for the nexus.
> > > >
> > > > Use the map-aware parser for all supported GPIO property spellings. This
> > > > makes fw_devlink resolve the same provider as the GPIO consumer API. Direct
> > > > GPIO references continue to work because the map-aware parser returns the
> > > > original provider when no gpio-map property is present.
> > > >
> > > > Add OF unittest coverage for mapped and direct GPIO suppliers, including
> > > > the deprecated singular and unprefixed property spellings.
> > > >  
> > > 
> > > Since this is a fix that we may want to backport, the unit tests should go in
> > > a separate, follow-up commit.
> > > 
> > > Bart  
> > 
> > Thanks for the feedback, if we want to go with the direction proposed
> > here I'll make sure to split it off in future series, I was unsure about
> > that.
> > 
> > Since usage of this nexus system seems limited, I'm also not sure if we
> > need to backport but it technically is a fix.
> 
> Not sure it is so limited :)
> 
> Also, I agree with both patches (PWM and GPIO).
> 
> fw_devlink should use the end device and not the first nexus node.
> 
> Best regards,
> Hervé

Glad to hear this is being used. From a quick experiment I noticed it
didn't really apply to kernels before v7.0, but we can see the state of
it once this moves out of RFC and I split the testing code off.

Kind regards,
Ernest

Re: [PATCH RFC 1/2] of: property: fw_devlink: Follow GPIO nexus maps

[Bartosz Golaszewski]

On Wed, 2 Sep 2026 15:22:36 +0200, Ernest Van Hoecke
<ernestvanhoecke@gmail.com> said:
> On Wed, Sep 02, 2026 at 05:30:19AM -0700, Bartosz Golaszewski wrote:
>> On Wed, 2 Sep 2026 13:41:39 +0200, Ernest Van Hoecke
>> <ernestvanhoecke@gmail.com> said:
>> > From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>> >
>> > GPIO consumers use of_parse_phandle_with_args_map() to resolve specifiers
>> > through gpio-map properties. fw_devlink instead parses GPIO properties as
>>
>> Unlike PWM, there's no such thing as "gpio-map" properties.
>>
> Hi Bartosz,
>
> bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a
> nexus node") added support for nexus nodes, and then c11e6f0f04db ("gpio:
> Support gpio nexus dt bindings") added support for "gpio-map".
>
> Herve later added support for pwm nexus dt bindings modeled on the GPIO
> support in e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings").
>
> Please let me know if I misunderstood something.
>

No, sorry, it's me who didn't get that part correctly.

>> > direct phandle references, so it records the nexus node as the supplier
>> > rather than the mapped GPIO provider.
>> >
>>
>> Can you point me to an example? I'm not sure what a nexus node is in the
>> context of GPIO.
>
> Stephen gave an example usage in his commit message implementing
> of_parse_phandle_with_args_map():
> 	soc {
> 	        soc_gpio1: gpio-controller1 {
> 	                #gpio-cells = <2>;
> 	        };
>
> 	        soc_gpio2: gpio-controller2 {
> 	                #gpio-cells = <2>;
> 	        };
> 	};
>
> 	connector: connector {
> 	        #gpio-cells = <2>;
> 	        gpio-map = <0 0 &soc_gpio1 1 0>,
> 	                   <1 0 &soc_gpio2 4 0>,
> 	                   <2 0 &soc_gpio1 3 0>,
> 	                   <3 0 &soc_gpio2 2 0>;
> 	        gpio-map-mask = <0xf 0x0>;
>         	gpio-map-pass-thru = <0x0 0x1>
> 	};
>
> 	expansion_device {
>         	reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
> 	};
>
> Admittedly, this hasn't seen much (any?) actual use in the device trees
> yet.
>
> We (Toradex) would like to use it to specify a LVDS connector on our
> boards. This connector appears on different carrier boards that all mate
> with the same display and have the same pinout. The only potential
> difference is which PWMs and GPIOs are connected to the connector.
>
> There, specifying the LVDS connector as a nexus node on the relevant
> carrier board DTS/DTSI would allow us to reuse the same display overlay.
> That example usage is given by Leonardo Costa here:
> https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
> Note how we have the connector on imx8mp-verdin-dev.dtsi but could also
> add it to other boards, i.e: imx8mp-verdin-mallow.dtsi
>
> Note that in that example we used the "tdx,verdin-lvds-connector"
> compatible for the connector. Since this is a nexus node and just a
> dumb connector without driver, not having a compatible would make sense.
> In a final implementation we could specify a compatible + binding if
> that specifies the ABI better. It is not entirely clear to me what is
> preferred at the moment, but that is disconnected from this patch
> series.
>

In that case it makes sense I guess and good to see someone actually using it
eventually.

Bartosz

[PATCH RFC 2/2] of: property: fw_devlink: Follow PWM nexus maps

[Ernest Van Hoecke]

From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

PWM consumers use of_parse_phandle_with_args_map() to resolve specifiers
through pwm-map properties. fw_devlink instead parses the pwms property as
a direct phandle reference, so it records the nexus node as the supplier
rather than the mapped PWM provider.

A nexus is a translation node, not the PWM provider, and need not be
populated as a device. The resulting fwnode link can therefore remain
unresolved and indefinitely defer the consumer while
device_links_check_suppliers() waits for the nexus.

Use the map-aware parser for pwms so fw_devlink resolves the same provider
as the PWM consumer API. Direct PWM references continue to work because the
map-aware parser returns the original provider when no pwm-map property is
present.

Add OF unittest coverage for mapped and direct PWM suppliers.

Fixes: e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
Reported-by: Leonardo Costa <leonardo.costa@toradex.com>
Link: https://lore.kernel.org/all/juuc4af7ndbajcl7gzf4tg5qz2q2j5tt3rvql4jbauradujrre@gc5nbdhhixaf/
Tested-by: Leonardo Costa <leonardo.costa@toradex.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
---
 drivers/of/property.c                       | 11 ++++++++++-
 drivers/of/unittest-data/tests-phandle.dtsi | 16 ++++++++++++++++
 drivers/of/unittest.c                       |  4 ++++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 380df0861ab9..d5e89beb17f9 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1331,6 +1331,15 @@ static struct device_node *parse_##fname(struct device_node *np,	  \
 	return parse_prop_cells(np, prop_name, index, name, cells);	  \
 }
 
+#define DEFINE_SIMPLE_NEXUS_PROP(fname, name, stem)			  \
+static struct device_node *parse_##fname(struct device_node *np,	  \
+					const char *prop_name, int index) \
+{									  \
+	if (strcmp(prop_name, name))					  \
+		return NULL;						  \
+	return parse_nexus_prop(np, prop_name, index, stem);		  \
+}
+
 /**
  * parse_suffix_prop_cells - Suffix property parsing function for suppliers
  *
@@ -1426,7 +1435,6 @@ DEFINE_SIMPLE_PROP(extcon, "extcon", NULL)
 DEFINE_SIMPLE_PROP(nvmem_cells, "nvmem-cells", "#nvmem-cell-cells")
 DEFINE_SIMPLE_PROP(phys, "phys", "#phy-cells")
 DEFINE_SIMPLE_PROP(wakeup_parent, "wakeup-parent", NULL)
-DEFINE_SIMPLE_PROP(pwms, "pwms", "#pwm-cells")
 DEFINE_SIMPLE_PROP(resets, "resets", "#reset-cells")
 DEFINE_SIMPLE_PROP(leds, "leds", NULL)
 DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
@@ -1438,6 +1446,7 @@ DEFINE_SIMPLE_PROP(pses, "pses", "#pse-cells")
 DEFINE_SIMPLE_PROP(power_supplies, "power-supplies", NULL)
 DEFINE_SIMPLE_PROP(mmc_pwrseq, "mmc-pwrseq", NULL)
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
+DEFINE_SIMPLE_NEXUS_PROP(pwms, "pwms", "pwm")
 DEFINE_SUFFIX_NEXUS_PROP(gpio, "-gpio", "gpio")
 
 static struct device_node *parse_pinctrl_n(struct device_node *np,
diff --git a/drivers/of/unittest-data/tests-phandle.dtsi b/drivers/of/unittest-data/tests-phandle.dtsi
index 163ef07be16d..7cb3e19554b6 100644
--- a/drivers/of/unittest-data/tests-phandle.dtsi
+++ b/drivers/of/unittest-data/tests-phandle.dtsi
@@ -85,11 +85,19 @@ gpio_provider: gpio-controller {
 					#gpio-cells = <2>;
 				};
 
+				pwm_provider: pwm-controller {
+					#pwm-cells = <3>;
+				};
+
 				test_nexus: nexus {
 					#gpio-cells = <2>;
+					#pwm-cells = <3>;
 					gpio-map = <0 0 &gpio_provider 1 0>;
 					gpio-map-mask = <0xffffffff 0>;
 					gpio-map-pass-thru = <0 0xffffffff>;
+					pwm-map = <0 0 0 &pwm_provider 1 0 0>;
+					pwm-map-mask = <0xffffffff 0 0>;
+					pwm-map-pass-thru = <0 0xffffffff 0xffffffff>;
 				};
 
 				gpio-compat-consumer {
@@ -111,6 +119,14 @@ gpio-direct-consumer {
 				gpio-singular-consumer {
 					test-gpio = <&test_nexus 0 0>;
 				};
+
+				pwm-consumer {
+					pwms = <&test_nexus 0 1000 0>;
+				};
+
+				pwm-direct-consumer {
+					pwms = <&pwm_provider 1 1000 0>;
+				};
 			};
 		};
 	};
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 487f3b629a73..508ebc7581c8 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -759,6 +759,7 @@ static void __init of_unittest_fw_devlink_supplier(struct device_node *tests,
 static void __init of_unittest_fw_devlink(void)
 {
 	const char *gpio_supplier = "gpio-controller";
+	const char *pwm_supplier = "pwm-controller";
 	struct device_node *tests;
 
 	tests = of_find_node_by_path("/testcase-data/phandle-tests/fw-devlink-tests");
@@ -773,6 +774,9 @@ static void __init of_unittest_fw_devlink(void)
 	of_unittest_fw_devlink_supplier(tests, "gpio-direct-consumer", gpio_supplier);
 	of_unittest_fw_devlink_supplier(tests, "gpio-singular-consumer", gpio_supplier);
 
+	of_unittest_fw_devlink_supplier(tests, "pwm-consumer", pwm_supplier);
+	of_unittest_fw_devlink_supplier(tests, "pwm-direct-consumer", pwm_supplier);
+
 	of_node_put(tests);
 }
 

-- 
2.43.0