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@xxxxxxxxx> said:
> > From: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> >
> > 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