| Message ID | 20260902-fw-devlink-nexus-ready-v1-1-68fe1996e78a@toradex.com |
|---|---|
| State | New |
| Headers | show |
| Series | of: property: Make fw_devlink follow GPIO and PWM nexus maps | expand |
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
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
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é
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
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 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
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
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();