.../devicetree/bindings/export-symbols.yaml | 43 ++++++++++ drivers/misc/lan966x_pci.c | 3 +- drivers/of/of_kunit_helpers.c | 2 +- drivers/of/of_private.h | 2 +- drivers/of/overlay.c | 30 ++++++- drivers/of/resolver.c | 80 ++++++++++++++----- drivers/of/unittest-data/Makefile | 5 ++ .../unittest-data/overlay_export_symbols.dtso | 15 ++++ .../of/unittest-data/testcases_common.dtsi | 1 + .../unittest-data/tests-export-symbols.dtsi | 30 +++++++ drivers/of/unittest.c | 76 ++++++++++++++++-- include/linux/of.h | 6 +- 12 files changed, 259 insertions(+), 34 deletions(-) create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml create mode 100644 drivers/of/unittest-data/overlay_export_symbols.dtso create mode 100644 drivers/of/unittest-data/tests-export-symbols.dtsi
Hi,
At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
about issues we have with runtime hotplug on non-discoverable busses
with device tree overlays [1].
On our system, a base board has a connector and addon boards can be
connected to this connector. Both boards are described using device
tree. The base board is described by a base device tree and addon boards
are describe by overlays device tree. More details can be found at [2].
This kind of use case can be found also on:
- Grove Sunlight Sensor [3]
- mikroBUS [4]
One of the issue we were facing on was referencing resources available
on the base board device tree from the addon overlay device tree.
Using a nexus node [5] helps decoupling resources and avoid the
knowledge of the full base board from the overlay. Indeed, with nexus
node, the overlay need to know only about the nexus node itself.
For instance, suppose a connector where a GPIO is connected at PinA. On
the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
controller.
The base board can describe this GPIO using a nexus node:
soc_gpio: gpio-controller {
#gpio-cells = <2>;
};
connector1: connector1 {
/*
* Nexus node for the GPIO available on the connector.
* GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
* controller
*/
#gpio-cells = <2>;
gpio-map = <0 0 &soc_gpio 12 0>;
gpio-map-mask = <0xf 0x0>;
gpio-map-pass-thru = <0x0 0xf>;
};
The connector pin A GPIO can be referenced using:
<&connector1 0 GPIO_ACTIVE_HIGH>
This implies that the overlay needs to know about exact label that
references the connector. This label can be different on a different
board and so applying the overlay could failed even if it is used to
describe the exact same addon board. Further more, a given base board
can have several connectors where the exact same addon board can be
connected. In that case, the same overlay cannot be used on both
connector. Indeed, the connector labels have to be different.
The export-symbols node introduced by this current series solves this
issue.
The idea of export-symbols is to have something similar to the global
__symbols__ node but local to a specific node. Symbols listed in this
export-symbols are local and visible only when an overlay is applied on
a node having an export-symbols subnode.
Using export-symbols, our example becomes:
soc_gpio: gpio-controller {
#gpio-cells = <2>;
};
connector1: connector1 {
/*
* Nexus node for the GPIO available on the connector.
* GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
* controller
*/
#gpio-cells = <2>;
gpio-map = <0 0 &soc_gpio 12 0>;
gpio-map-mask = <0xf 0x0>;
gpio-map-pass-thru = <0x0 0xf>;
export-symbols {
connector = <&connector1>;
};
};
With that export-symbols node, an overlay applied on connector1 node can
have the symbol named 'connector' resolved to connector1. Indeed, the
export-symbols node available at connector1 node is used when the
overlay is applied. If the overlay has an unresolved 'connector' symbol,
it will be resolved to connector1 thanks to export-symbols.
Our overlay using the nexus node can contains:
node {
foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
};
It used the GPIO 0 from the connector it is applied on.
A board with two connectors can be described with:
connector1: connector1 {
...
export-symbols {
connector = <&connector1>;
};
};
connector2: connector2 {
...
export-symbols {
connector = <&connector2>;
};
};
In that case, the same overlay with unresolved 'connector' symbol can be
applied on both connectors and the correct symbol resolution (connector1
or connector2) will be done.
This current series add support for the export-symbols node feature:
- Patch 1 describes the export-symbols binding
- Patches 2 to 6 prepare and add the support for the export-symbols
feature
- Patch 7 adds an unittest for the export-symbols feature
Best regards,
Hervé
[1] https://lpc.events/event/18/contributions/1696/
[2] https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
[3] https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/
[4] https://lore.kernel.org/lkml/20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org/
[5] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
Herve Codina (7):
dt-bindings: Add support for export-symbols node
of: resolver: Introduce get_phandle_from_symbols_node()
of: resolver: Add export_symbols in of_resolve_phandles() parameters
of: resolver: Add support for the export symbols node
of: overlay: Add export_symbols_name in of_overlay_fdt_apply()
parameters
of: overlay: Add support for the export symbols node
of: unittest: Add tests for export symbols
.../devicetree/bindings/export-symbols.yaml | 43 ++++++++++
drivers/misc/lan966x_pci.c | 3 +-
drivers/of/of_kunit_helpers.c | 2 +-
drivers/of/of_private.h | 2 +-
drivers/of/overlay.c | 30 ++++++-
drivers/of/resolver.c | 80 ++++++++++++++-----
drivers/of/unittest-data/Makefile | 5 ++
.../unittest-data/overlay_export_symbols.dtso | 15 ++++
.../of/unittest-data/testcases_common.dtsi | 1 +
.../unittest-data/tests-export-symbols.dtsi | 30 +++++++
drivers/of/unittest.c | 76 ++++++++++++++++--
include/linux/of.h | 6 +-
12 files changed, 259 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
create mode 100644 drivers/of/unittest-data/overlay_export_symbols.dtso
create mode 100644 drivers/of/unittest-data/tests-export-symbols.dtsi
--
2.47.0
On 12/9/24 20:48, Herve Codina wrote:
> Hi,
>
> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> about issues we have with runtime hotplug on non-discoverable busses
> with device tree overlays [1].
>
> On our system, a base board has a connector and addon boards can be
> connected to this connector. Both boards are described using device
> tree. The base board is described by a base device tree and addon boards
> are describe by overlays device tree. More details can be found at [2].
>
> This kind of use case can be found also on:
> - Grove Sunlight Sensor [3]
> - mikroBUS [4]
>
> One of the issue we were facing on was referencing resources available
> on the base board device tree from the addon overlay device tree.
>
> Using a nexus node [5] helps decoupling resources and avoid the
> knowledge of the full base board from the overlay. Indeed, with nexus
> node, the overlay need to know only about the nexus node itself.
>
> For instance, suppose a connector where a GPIO is connected at PinA. On
> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> controller.
>
> The base board can describe this GPIO using a nexus node:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
> };
>
> The connector pin A GPIO can be referenced using:
> <&connector1 0 GPIO_ACTIVE_HIGH>
>
> This implies that the overlay needs to know about exact label that
> references the connector. This label can be different on a different
> board and so applying the overlay could failed even if it is used to
> describe the exact same addon board. Further more, a given base board
> can have several connectors where the exact same addon board can be
> connected. In that case, the same overlay cannot be used on both
> connector. Indeed, the connector labels have to be different.
>
> The export-symbols node introduced by this current series solves this
> issue.
>
> The idea of export-symbols is to have something similar to the global
> __symbols__ node but local to a specific node. Symbols listed in this
> export-symbols are local and visible only when an overlay is applied on
> a node having an export-symbols subnode.
>
> Using export-symbols, our example becomes:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
>
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> With that export-symbols node, an overlay applied on connector1 node can
> have the symbol named 'connector' resolved to connector1. Indeed, the
> export-symbols node available at connector1 node is used when the
> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> it will be resolved to connector1 thanks to export-symbols.
>
> Our overlay using the nexus node can contains:
> node {
> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> };
> It used the GPIO 0 from the connector it is applied on.
>
> A board with two connectors can be described with:
> connector1: connector1 {
> ...
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> connector2: connector2 {
> ...
> export-symbols {
> connector = <&connector2>;
> };
> };
>
> In that case, the same overlay with unresolved 'connector' symbol can be
> applied on both connectors and the correct symbol resolution (connector1
> or connector2) will be done.
>
> This current series add support for the export-symbols node feature:
> - Patch 1 describes the export-symbols binding
> - Patches 2 to 6 prepare and add the support for the export-symbols
> feature
> - Patch 7 adds an unittest for the export-symbols feature
>
> Best regards,
> Hervé
>
> [1] https://lpc.events/event/18/contributions/1696/
> [2] https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
> [3] https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/
> [4] https://lore.kernel.org/lkml/20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org/
> [5] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
>
> Herve Codina (7):
> dt-bindings: Add support for export-symbols node
> of: resolver: Introduce get_phandle_from_symbols_node()
> of: resolver: Add export_symbols in of_resolve_phandles() parameters
> of: resolver: Add support for the export symbols node
> of: overlay: Add export_symbols_name in of_overlay_fdt_apply()
> parameters
> of: overlay: Add support for the export symbols node
> of: unittest: Add tests for export symbols
>
> .../devicetree/bindings/export-symbols.yaml | 43 ++++++++++
> drivers/misc/lan966x_pci.c | 3 +-
> drivers/of/of_kunit_helpers.c | 2 +-
> drivers/of/of_private.h | 2 +-
> drivers/of/overlay.c | 30 ++++++-
> drivers/of/resolver.c | 80 ++++++++++++++-----
> drivers/of/unittest-data/Makefile | 5 ++
> .../unittest-data/overlay_export_symbols.dtso | 15 ++++
> .../of/unittest-data/testcases_common.dtsi | 1 +
> .../unittest-data/tests-export-symbols.dtsi | 30 +++++++
> drivers/of/unittest.c | 76 ++++++++++++++++--
> include/linux/of.h | 6 +-
> 12 files changed, 259 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
> create mode 100644 drivers/of/unittest-data/overlay_export_symbols.dtso
> create mode 100644 drivers/of/unittest-data/tests-export-symbols.dtsi
>
Tested for pocketbeagle2 connector [0]
[0]: https://github.com/Ayush1325/linux/tree/b4/beagle-cape
Tested-by: Ayush Singh <ayush@beagleboard.org>
On 09/12/24 20:48, Herve Codina wrote:
> Hi,
>
> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> about issues we have with runtime hotplug on non-discoverable busses
> with device tree overlays [1].
>
> On our system, a base board has a connector and addon boards can be
> connected to this connector. Both boards are described using device
> tree. The base board is described by a base device tree and addon boards
> are describe by overlays device tree. More details can be found at [2].
>
> This kind of use case can be found also on:
> - Grove Sunlight Sensor [3]
> - mikroBUS [4]
>
> One of the issue we were facing on was referencing resources available
> on the base board device tree from the addon overlay device tree.
>
> Using a nexus node [5] helps decoupling resources and avoid the
> knowledge of the full base board from the overlay. Indeed, with nexus
> node, the overlay need to know only about the nexus node itself.
>
> For instance, suppose a connector where a GPIO is connected at PinA. On
> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> controller.
>
> The base board can describe this GPIO using a nexus node:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
> };
>
> The connector pin A GPIO can be referenced using:
> <&connector1 0 GPIO_ACTIVE_HIGH>
>
> This implies that the overlay needs to know about exact label that
> references the connector. This label can be different on a different
> board and so applying the overlay could failed even if it is used to
> describe the exact same addon board. Further more, a given base board
> can have several connectors where the exact same addon board can be
> connected. In that case, the same overlay cannot be used on both
> connector. Indeed, the connector labels have to be different.
>
> The export-symbols node introduced by this current series solves this
> issue.
>
> The idea of export-symbols is to have something similar to the global
> __symbols__ node but local to a specific node. Symbols listed in this
> export-symbols are local and visible only when an overlay is applied on
> a node having an export-symbols subnode.
>
> Using export-symbols, our example becomes:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
>
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> With that export-symbols node, an overlay applied on connector1 node can
> have the symbol named 'connector' resolved to connector1. Indeed, the
> export-symbols node available at connector1 node is used when the
> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> it will be resolved to connector1 thanks to export-symbols.
>
> Our overlay using the nexus node can contains:
> node {
> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> };
> It used the GPIO 0 from the connector it is applied on.
>
> A board with two connectors can be described with:
> connector1: connector1 {
> ...
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> connector2: connector2 {
> ...
> export-symbols {
> connector = <&connector2>;
> };
> };
>
> In that case, the same overlay with unresolved 'connector' symbol can be
> applied on both connectors and the correct symbol resolution (connector1
> or connector2) will be done.
What is the reason for not using symbols directly as described here [3]?
I do like this approach since it does not pollute the global symbols.
Just want to know if there are any other reasons for it.
>
> This current series add support for the export-symbols node feature:
> - Patch 1 describes the export-symbols binding
> - Patches 2 to 6 prepare and add the support for the export-symbols
> feature
> - Patch 7 adds an unittest for the export-symbols feature
>
> Best regards,
> Hervé
>
> [1] https://lpc.events/event/18/contributions/1696/
> [2] https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
> [3] https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/
> [4] https://lore.kernel.org/lkml/20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org/
> [5] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
>
> Herve Codina (7):
> dt-bindings: Add support for export-symbols node
> of: resolver: Introduce get_phandle_from_symbols_node()
> of: resolver: Add export_symbols in of_resolve_phandles() parameters
> of: resolver: Add support for the export symbols node
> of: overlay: Add export_symbols_name in of_overlay_fdt_apply()
> parameters
> of: overlay: Add support for the export symbols node
> of: unittest: Add tests for export symbols
>
> .../devicetree/bindings/export-symbols.yaml | 43 ++++++++++
> drivers/misc/lan966x_pci.c | 3 +-
> drivers/of/of_kunit_helpers.c | 2 +-
> drivers/of/of_private.h | 2 +-
> drivers/of/overlay.c | 30 ++++++-
> drivers/of/resolver.c | 80 ++++++++++++++-----
> drivers/of/unittest-data/Makefile | 5 ++
> .../unittest-data/overlay_export_symbols.dtso | 15 ++++
> .../of/unittest-data/testcases_common.dtsi | 1 +
> .../unittest-data/tests-export-symbols.dtsi | 30 +++++++
> drivers/of/unittest.c | 76 ++++++++++++++++--
> include/linux/of.h | 6 +-
> 12 files changed, 259 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
> create mode 100644 drivers/of/unittest-data/overlay_export_symbols.dtso
> create mode 100644 drivers/of/unittest-data/tests-export-symbols.dtsi
>
Ayush Singh
Hi Ayush, On Tue, 10 Dec 2024 14:52:22 +0530 Ayush Singh <ayush@beagleboard.org> wrote: ... > > What is the reason for not using symbols directly as described here [3]? > > I do like this approach since it does not pollute the global symbols. > Just want to know if there are any other reasons for it. > Modifying the __symbols__ node at runtime (adding / removing properties in it) exposes memory leaks if __symbols__ already exist in the live DT. This __symbols__ node exist if the dtb was compiled with '-@' or if you chain the overlay (i.e. __symbols__ node created by the first overlay). I think also that some conflicts can appears. What happens if you want to add a new label but this label is already present for some other purpose? Best regards, Hervé
On 10/12/24 15:11, Herve Codina wrote: > Hi Ayush, > > On Tue, 10 Dec 2024 14:52:22 +0530 > Ayush Singh <ayush@beagleboard.org> wrote: > > ... >> >> What is the reason for not using symbols directly as described here [3]? >> >> I do like this approach since it does not pollute the global symbols. >> Just want to know if there are any other reasons for it. >> > > Modifying the __symbols__ node at runtime (adding / removing properties in > it) exposes memory leaks if __symbols__ already exist in the live DT. > This __symbols__ node exist if the dtb was compiled with '-@' or if you > chain the overlay (i.e. __symbols__ node created by the first overlay). Yeah, that is a problem, specially in a setup which might involve hot-plugging. > > I think also that some conflicts can appears. What happens if you want to > add a new label but this label is already present for some other purpose? I do not think that actually is a problem. As described in the original patch [0], the symbol and connector overlay is supposed to be applied as a group (overwriting any conflicting symbols in the process). The reason why this is not a problem is that `__symbols__` are only used to resolve the phandles (overlays do not support path references yet), but do not really have a purpose in the livetree (at least far as I know, but I can be wrong). > > Best regards, > Hervé [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ Ayush Singh
Hi Ayush, On Tue, 10 Dec 2024 15:26:44 +0530 Ayush Singh <ayush@beagleboard.org> wrote: > On 10/12/24 15:11, Herve Codina wrote: > > Hi Ayush, > > > > On Tue, 10 Dec 2024 14:52:22 +0530 > > Ayush Singh <ayush@beagleboard.org> wrote: > > > > ... > >> > >> What is the reason for not using symbols directly as described here [3]? > >> > >> I do like this approach since it does not pollute the global symbols. > >> Just want to know if there are any other reasons for it. > >> > > > > Modifying the __symbols__ node at runtime (adding / removing properties in > > it) exposes memory leaks if __symbols__ already exist in the live DT. > > This __symbols__ node exist if the dtb was compiled with '-@' or if you > > chain the overlay (i.e. __symbols__ node created by the first overlay). > > Yeah, that is a problem, specially in a setup which might involve > hot-plugging. > > > > > I think also that some conflicts can appears. What happens if you want to > > add a new label but this label is already present for some other purpose? > > I do not think that actually is a problem. As described in the original > patch [0], the symbol and connector overlay is supposed to be applied as > a group (overwriting any conflicting symbols in the process). > > The reason why this is not a problem is that `__symbols__` are only used > to resolve the phandles (overlays do not support path references yet), > but do not really have a purpose in the livetree (at least far as I > know, but I can be wrong). > > > > > Best regards, > > Hervé > > [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ Also, in your first overlay (adding symbols in __sympbols__ node), you have something like: GROVE_PIN1_MUX_I2C_SCL = "/bus@f0000/pinctrl@f4000/grove-i2c-pins"; If I understood correctly, other overlays will have GROVE_PIN1_MUX_I2C_SCL as unresolved symbols and will use GROVE_PIN1_MUX_I2C_SCL to reference the grove-i2c-pins node. This unresolved symbol from the overlay is resolved thanks to the __symbols__ table where you added GROVE_PIN1_MUX_I2C_SCL (first overlay operation). In order to work, you need to have a phandle property set in the grove-i2c-pins node. This is done by dtc when you compile the dtb containing the grove-i2c-pins node (i.e. k3-am625-beagleplay.dts) The phandle property will be set only if: - a label for grove-i2c-pins already exist and -@ option is used or - a label for grove-i2c-pins already exist and it is referenced as a phandle in the dts (k3-am625-beagleplay.dts). Otherwise, dtc will not create the phandle property and without this property, the symbol resolution will not be correct. Best regards, Hervé
On 10/12/24 16:25, Herve Codina wrote: > Hi Ayush, > > On Tue, 10 Dec 2024 15:26:44 +0530 > Ayush Singh <ayush@beagleboard.org> wrote: > >> On 10/12/24 15:11, Herve Codina wrote: >>> Hi Ayush, >>> >>> On Tue, 10 Dec 2024 14:52:22 +0530 >>> Ayush Singh <ayush@beagleboard.org> wrote: >>> >>> ... >>>> >>>> What is the reason for not using symbols directly as described here [3]? >>>> >>>> I do like this approach since it does not pollute the global symbols. >>>> Just want to know if there are any other reasons for it. >>>> >>> >>> Modifying the __symbols__ node at runtime (adding / removing properties in >>> it) exposes memory leaks if __symbols__ already exist in the live DT. >>> This __symbols__ node exist if the dtb was compiled with '-@' or if you >>> chain the overlay (i.e. __symbols__ node created by the first overlay). >> >> Yeah, that is a problem, specially in a setup which might involve >> hot-plugging. >> >>> >>> I think also that some conflicts can appears. What happens if you want to >>> add a new label but this label is already present for some other purpose? >> >> I do not think that actually is a problem. As described in the original >> patch [0], the symbol and connector overlay is supposed to be applied as >> a group (overwriting any conflicting symbols in the process). >> >> The reason why this is not a problem is that `__symbols__` are only used >> to resolve the phandles (overlays do not support path references yet), >> but do not really have a purpose in the livetree (at least far as I >> know, but I can be wrong). >> >>> >>> Best regards, >>> Hervé >> >> [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ > > > Also, in your first overlay (adding symbols in __sympbols__ node), you have > something like: > GROVE_PIN1_MUX_I2C_SCL = "/bus@f0000/pinctrl@f4000/grove-i2c-pins"; > > If I understood correctly, other overlays will have GROVE_PIN1_MUX_I2C_SCL > as unresolved symbols and will use GROVE_PIN1_MUX_I2C_SCL to reference the > grove-i2c-pins node. > This unresolved symbol from the overlay is resolved thanks to the __symbols__ > table where you added GROVE_PIN1_MUX_I2C_SCL (first overlay operation). > > In order to work, you need to have a phandle property set in the > grove-i2c-pins node. > > This is done by dtc when you compile the dtb containing the grove-i2c-pins > node (i.e. k3-am625-beagleplay.dts) > > The phandle property will be set only if: > - a label for grove-i2c-pins already exist and -@ option is used > or > - a label for grove-i2c-pins already exist and it is referenced as a phandle > in the dts (k3-am625-beagleplay.dts). > > Otherwise, dtc will not create the phandle property and without this > property, the symbol resolution will not be correct. > > Best regards, > Hervé > Hello Hervé Thanks for the clarification. things have changed a bit since the last message and it seems like trying to add path reference support to overlays is not the best way forward [0]. So I would love to help move this approach forward. I do have a question regarding this approach, so here I go: Can the `export-symbols` node be added to devicetree spec and be resolved by the devicetree compiler (and fdtoverlay) instead of being runtime resolution. To get some context, I would like to share the addon-board overlays between ZephyrRTOS and Linux kernel. I would be happy to try adding support to dtc compiler for it. I am also tagging David Gibson (dtc maintainer) in this discussion since he also had some ideas regarding the feasibility and pitfalls of adding it to devicetree compiler (and spec). [0]: https://lore.kernel.org/devicetree-compiler/6b2dba90-3c52-4933-88f3-b47f96dc7710@beagleboard.org/T/#m900b5ca13cfc28396d4d46d9c3130a7070fa8c90 Best regards, Ayush Singh
Hi Ayush, On Wed, 8 Jan 2025 13:06:03 +0530 Ayush Singh <ayush@beagleboard.org> wrote: > On 10/12/24 16:25, Herve Codina wrote: > > Hi Ayush, > > > > On Tue, 10 Dec 2024 15:26:44 +0530 > > Ayush Singh <ayush@beagleboard.org> wrote: > > > >> On 10/12/24 15:11, Herve Codina wrote: > >>> Hi Ayush, > >>> > >>> On Tue, 10 Dec 2024 14:52:22 +0530 > >>> Ayush Singh <ayush@beagleboard.org> wrote: > >>> > >>> ... > >>>> > >>>> What is the reason for not using symbols directly as described here [3]? > >>>> > >>>> I do like this approach since it does not pollute the global symbols. > >>>> Just want to know if there are any other reasons for it. > >>>> > >>> > >>> Modifying the __symbols__ node at runtime (adding / removing properties in > >>> it) exposes memory leaks if __symbols__ already exist in the live DT. > >>> This __symbols__ node exist if the dtb was compiled with '-@' or if you > >>> chain the overlay (i.e. __symbols__ node created by the first overlay). > >> > >> Yeah, that is a problem, specially in a setup which might involve > >> hot-plugging. > >> > >>> > >>> I think also that some conflicts can appears. What happens if you want to > >>> add a new label but this label is already present for some other purpose? > >> > >> I do not think that actually is a problem. As described in the original > >> patch [0], the symbol and connector overlay is supposed to be applied as > >> a group (overwriting any conflicting symbols in the process). > >> > >> The reason why this is not a problem is that `__symbols__` are only used > >> to resolve the phandles (overlays do not support path references yet), > >> but do not really have a purpose in the livetree (at least far as I > >> know, but I can be wrong). > >> > >>> > >>> Best regards, > >>> Hervé > >> > >> [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ > > > > > > Also, in your first overlay (adding symbols in __sympbols__ node), you have > > something like: > > GROVE_PIN1_MUX_I2C_SCL = "/bus@f0000/pinctrl@f4000/grove-i2c-pins"; > > > > If I understood correctly, other overlays will have GROVE_PIN1_MUX_I2C_SCL > > as unresolved symbols and will use GROVE_PIN1_MUX_I2C_SCL to reference the > > grove-i2c-pins node. > > This unresolved symbol from the overlay is resolved thanks to the __symbols__ > > table where you added GROVE_PIN1_MUX_I2C_SCL (first overlay operation). > > > > In order to work, you need to have a phandle property set in the > > grove-i2c-pins node. > > > > This is done by dtc when you compile the dtb containing the grove-i2c-pins > > node (i.e. k3-am625-beagleplay.dts) > > > > The phandle property will be set only if: > > - a label for grove-i2c-pins already exist and -@ option is used > > or > > - a label for grove-i2c-pins already exist and it is referenced as a phandle > > in the dts (k3-am625-beagleplay.dts). > > > > Otherwise, dtc will not create the phandle property and without this > > property, the symbol resolution will not be correct. > > > > Best regards, > > Hervé > > > > Hello Hervé > > Thanks for the clarification. things have changed a bit since the last > message and it seems like trying to add path reference support to > overlays is not the best way forward [0]. So I would love to help move > this approach forward. > > I do have a question regarding this approach, so here I go: > > Can the `export-symbols` node be added to devicetree spec and be > resolved by the devicetree compiler (and fdtoverlay) instead of being > runtime resolution. Of course, a solution with fdtoverlay is welcome but it should not fully replace the runtime resolution. In our case, we need runtime resolution because the overlay is loaded by a driver. Both resolutions (fdtoverlay and runtime) should work. > > To get some context, I would like to share the addon-board overlays > between ZephyrRTOS and Linux kernel. I would be happy to try adding > support to dtc compiler for it. I am also tagging David Gibson (dtc > maintainer) in this discussion since he also had some ideas regarding > the feasibility and pitfalls of adding it to devicetree compiler (and spec). > > > [0]: > https://lore.kernel.org/devicetree-compiler/6b2dba90-3c52-4933-88f3-b47f96dc7710@beagleboard.org/T/#m900b5ca13cfc28396d4d46d9c3130a7070fa8c90 > > Best regards, > Ayush Singh > Thanks for your help proposal! Best regards, Hervé
On 08/01/25 13:37, Herve Codina wrote: > Hi Ayush, > > On Wed, 8 Jan 2025 13:06:03 +0530 > Ayush Singh <ayush@beagleboard.org> wrote: > >> On 10/12/24 16:25, Herve Codina wrote: >>> Hi Ayush, >>> >>> On Tue, 10 Dec 2024 15:26:44 +0530 >>> Ayush Singh <ayush@beagleboard.org> wrote: >>> >>>> On 10/12/24 15:11, Herve Codina wrote: >>>>> Hi Ayush, >>>>> >>>>> On Tue, 10 Dec 2024 14:52:22 +0530 >>>>> Ayush Singh <ayush@beagleboard.org> wrote: >>>>> >>>>> ... >>>>>> >>>>>> What is the reason for not using symbols directly as described here [3]? >>>>>> >>>>>> I do like this approach since it does not pollute the global symbols. >>>>>> Just want to know if there are any other reasons for it. >>>>>> >>>>> >>>>> Modifying the __symbols__ node at runtime (adding / removing properties in >>>>> it) exposes memory leaks if __symbols__ already exist in the live DT. >>>>> This __symbols__ node exist if the dtb was compiled with '-@' or if you >>>>> chain the overlay (i.e. __symbols__ node created by the first overlay). >>>> >>>> Yeah, that is a problem, specially in a setup which might involve >>>> hot-plugging. >>>> >>>>> >>>>> I think also that some conflicts can appears. What happens if you want to >>>>> add a new label but this label is already present for some other purpose? >>>> >>>> I do not think that actually is a problem. As described in the original >>>> patch [0], the symbol and connector overlay is supposed to be applied as >>>> a group (overwriting any conflicting symbols in the process). >>>> >>>> The reason why this is not a problem is that `__symbols__` are only used >>>> to resolve the phandles (overlays do not support path references yet), >>>> but do not really have a purpose in the livetree (at least far as I >>>> know, but I can be wrong). >>>> >>>>> >>>>> Best regards, >>>>> Hervé >>>> >>>> [0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/ >>> >>> >>> Also, in your first overlay (adding symbols in __sympbols__ node), you have >>> something like: >>> GROVE_PIN1_MUX_I2C_SCL = "/bus@f0000/pinctrl@f4000/grove-i2c-pins"; >>> >>> If I understood correctly, other overlays will have GROVE_PIN1_MUX_I2C_SCL >>> as unresolved symbols and will use GROVE_PIN1_MUX_I2C_SCL to reference the >>> grove-i2c-pins node. >>> This unresolved symbol from the overlay is resolved thanks to the __symbols__ >>> table where you added GROVE_PIN1_MUX_I2C_SCL (first overlay operation). >>> >>> In order to work, you need to have a phandle property set in the >>> grove-i2c-pins node. >>> >>> This is done by dtc when you compile the dtb containing the grove-i2c-pins >>> node (i.e. k3-am625-beagleplay.dts) >>> >>> The phandle property will be set only if: >>> - a label for grove-i2c-pins already exist and -@ option is used >>> or >>> - a label for grove-i2c-pins already exist and it is referenced as a phandle >>> in the dts (k3-am625-beagleplay.dts). >>> >>> Otherwise, dtc will not create the phandle property and without this >>> property, the symbol resolution will not be correct. >>> >>> Best regards, >>> Hervé >>> >> >> Hello Hervé >> >> Thanks for the clarification. things have changed a bit since the last >> message and it seems like trying to add path reference support to >> overlays is not the best way forward [0]. So I would love to help move >> this approach forward. >> >> I do have a question regarding this approach, so here I go: >> >> Can the `export-symbols` node be added to devicetree spec and be >> resolved by the devicetree compiler (and fdtoverlay) instead of being >> runtime resolution. > > Of course, a solution with fdtoverlay is welcome but it should not fully > replace the runtime resolution. In our case, we need runtime resolution > because the overlay is loaded by a driver. > > Both resolutions (fdtoverlay and runtime) should work. I see, it seems linux does not use libfdt for applying overlays internally. > >> >> To get some context, I would like to share the addon-board overlays >> between ZephyrRTOS and Linux kernel. I would be happy to try adding >> support to dtc compiler for it. I am also tagging David Gibson (dtc >> maintainer) in this discussion since he also had some ideas regarding >> the feasibility and pitfalls of adding it to devicetree compiler (and spec). >> >> >> [0]: >> https://lore.kernel.org/devicetree-compiler/6b2dba90-3c52-4933-88f3-b47f96dc7710@beagleboard.org/T/#m900b5ca13cfc28396d4d46d9c3130a7070fa8c90 >> >> Best regards, >> Ayush Singh >> > > Thanks for your help proposal! > > Best regards, > Hervé I will experiment with adding support to dtc and see how things look. Hopefully, 2025 is the year of addon board support. Best regards, Ayush Singh
Hi Ayush, On Wed, 8 Jan 2025 13:58:04 +0530 Ayush Singh <ayush@beagleboard.org> wrote: ... > > I will experiment with adding support to dtc and see how things look. > Hopefully, 2025 is the year of addon board support. > Also one point different between fdtoverlay an runtime loading is that runtime loading allows to set the target node of the overlay at runtime. For instance, on LAN966X PCI driver, an overlay is loaded and applied on a PCI device node. The overlay loading is done by the PCI driver device: https://elixir.bootlin.com/linux/v6.13-rc1/source/drivers/misc/lan966x_pci.c#L131 The overlay loaded is the following one: https://elixir.bootlin.com/linux/v6.13-rc1/source/drivers/misc/lan966x_pci.dtso For addon boards, this feature is also useful because without any modification in the overlay itself, it can be applied on the correct connector. This allows to support, without any overlay modification the following cases: - A base board with multiple connectors where an addon board can be connected. - An addon board with its own DT overlay used on different base board This feature is not supported by fdtoverlay. Maybe something like fdtoverlay --base=/somewhere/my_connector could be implemented in fdtoverlay in order to choose the node where the overlay has to be applied. Best regards, Hervé
On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote: > Hi Ayush, > > On Wed, 8 Jan 2025 13:58:04 +0530 > Ayush Singh <ayush@beagleboard.org> wrote: > > ... > > > > I will experiment with adding support to dtc and see how things look. > > Hopefully, 2025 is the year of addon board support. > > > > Also one point different between fdtoverlay an runtime loading is > that runtime loading allows to set the target node of the overlay > at runtime. I'm not really sure what you mean by "runtime loading". Do you mean the kernel's implementation of loading dtbo overlays? While that is a different implementation from the one in fdtoverlay (AIUI), they're both working from the same dtb format. As we discovered attempting Ayush's proposal, it turns out that the dtbo simply doesn't have the information we need to correctly path substitutions; and it's not at all easy to add it. So, the problem of the encoding format needs to be solved regardless of which implementation is actually processing the overlays. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On 10/01/25 09:56, David Gibson wrote: > On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote: >> Hi Ayush, >> >> On Wed, 8 Jan 2025 13:58:04 +0530 >> Ayush Singh <ayush@beagleboard.org> wrote: >> >> ... >>> >>> I will experiment with adding support to dtc and see how things look. >>> Hopefully, 2025 is the year of addon board support. >>> >> >> Also one point different between fdtoverlay an runtime loading is >> that runtime loading allows to set the target node of the overlay >> at runtime. > > I'm not really sure what you mean by "runtime loading". Do you mean > the kernel's implementation of loading dtbo overlays? > > While that is a different implementation from the one in fdtoverlay > (AIUI), they're both working from the same dtb format. As we > discovered attempting Ayush's proposal, it turns out that the dtbo > simply doesn't have the information we need to correctly path > substitutions; and it's not at all easy to add it. Ahh, I think there is a misunderstanding. `export-symbols` only seems to support phandles, not paths. So no resizing involved. It's closer to the phandle support in `__symbols__`, just local in scope. > > So, the problem of the encoding format needs to be solved regardless > of which implementation is actually processing the overlays. > So there is no problem with the encoding format. The questions I have are more regarding weather `export-symbols` or something close to it can be made part of spec instead of the custom linux thing. Ayush Singh
On Fri, Jan 10, 2025 at 01:25:43PM +0530, Ayush Singh wrote: > > > On 10/01/25 09:56, David Gibson wrote: > > On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote: > > > Hi Ayush, > > > > > > On Wed, 8 Jan 2025 13:58:04 +0530 > > > Ayush Singh <ayush@beagleboard.org> wrote: > > > > > > ... > > > > > > > > I will experiment with adding support to dtc and see how things look. > > > > Hopefully, 2025 is the year of addon board support. > > > > > > > > > > Also one point different between fdtoverlay an runtime loading is > > > that runtime loading allows to set the target node of the overlay > > > at runtime. > > > > I'm not really sure what you mean by "runtime loading". Do you mean > > the kernel's implementation of loading dtbo overlays? > > > > While that is a different implementation from the one in fdtoverlay > > (AIUI), they're both working from the same dtb format. As we > > discovered attempting Ayush's proposal, it turns out that the dtbo > > simply doesn't have the information we need to correctly path > > substitutions; and it's not at all easy to add it. > > Ahh, I think there is a misunderstanding. `export-symbols` only seems to > support phandles, not paths. So no resizing involved. Oh, sorry, I was mixing this up with a different feature Ayush was working on. > It's closer to the phandle support in `__symbols__`, just local in scope. > > > > > So, the problem of the encoding format needs to be solved regardless > > of which implementation is actually processing the overlays. > > > > So there is no problem with the encoding format. > > The questions I have are more regarding weather `export-symbols` or > something close to it can be made part of spec instead of the custom linux > thing. > > > Ayush Singh > -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
Hi David, On Fri, 10 Jan 2025 15:26:23 +1100 David Gibson <david@gibson.dropbear.id.au> wrote: > On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote: > > Hi Ayush, > > > > On Wed, 8 Jan 2025 13:58:04 +0530 > > Ayush Singh <ayush@beagleboard.org> wrote: > > > > ... > > > > > > I will experiment with adding support to dtc and see how things look. > > > Hopefully, 2025 is the year of addon board support. > > > > > > > Also one point different between fdtoverlay an runtime loading is > > that runtime loading allows to set the target node of the overlay > > at runtime. > > I'm not really sure what you mean by "runtime loading". Do you mean > the kernel's implementation of loading dtbo overlays? Yes, exactly. > > While that is a different implementation from the one in fdtoverlay > (AIUI), they're both working from the same dtb format. As we > discovered attempting Ayush's proposal, it turns out that the dtbo > simply doesn't have the information we need to correctly path > substitutions; and it's not at all easy to add it. > > So, the problem of the encoding format needs to be solved regardless > of which implementation is actually processing the overlays. > What is the issue with the encoding format? It works on my side (kernel loading) and I didn't see anything problematic. Best regards Hervé
On Mon, Dec 9, 2024 at 9:18 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi,
>
> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> about issues we have with runtime hotplug on non-discoverable busses
> with device tree overlays [1].
>
> On our system, a base board has a connector and addon boards can be
> connected to this connector. Both boards are described using device
> tree. The base board is described by a base device tree and addon boards
> are describe by overlays device tree. More details can be found at [2].
>
> This kind of use case can be found also on:
> - Grove Sunlight Sensor [3]
> - mikroBUS [4]
>
> One of the issue we were facing on was referencing resources available
> on the base board device tree from the addon overlay device tree.
>
> Using a nexus node [5] helps decoupling resources and avoid the
> knowledge of the full base board from the overlay. Indeed, with nexus
> node, the overlay need to know only about the nexus node itself.
>
> For instance, suppose a connector where a GPIO is connected at PinA. On
> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> controller.
>
> The base board can describe this GPIO using a nexus node:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
> };
>
> The connector pin A GPIO can be referenced using:
> <&connector1 0 GPIO_ACTIVE_HIGH>
>
> This implies that the overlay needs to know about exact label that
> references the connector. This label can be different on a different
> board and so applying the overlay could failed even if it is used to
> describe the exact same addon board. Further more, a given base board
> can have several connectors where the exact same addon board can be
> connected. In that case, the same overlay cannot be used on both
> connector. Indeed, the connector labels have to be different.
>
> The export-symbols node introduced by this current series solves this
> issue.
>
> The idea of export-symbols is to have something similar to the global
> __symbols__ node but local to a specific node. Symbols listed in this
> export-symbols are local and visible only when an overlay is applied on
> a node having an export-symbols subnode.
>
> Using export-symbols, our example becomes:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
>
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> With that export-symbols node, an overlay applied on connector1 node can
> have the symbol named 'connector' resolved to connector1. Indeed, the
> export-symbols node available at connector1 node is used when the
> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> it will be resolved to connector1 thanks to export-symbols.
>
> Our overlay using the nexus node can contains:
> node {
> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> };
Couldn't we make something like this work:
connector: __overlay__ {
node {
foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
};
};
We already have to process all the phandles in the overlay. So this
just changes handling of 'connector' from being a local phandle which
we just renumber to an unresolved phandle which we have to lookup and
replace the phandle uses with.
Rob
Hi Rob,
On Mon, 9 Dec 2024 14:11:09 -0600
Rob Herring <robh@kernel.org> wrote:
...
> >
> > Our overlay using the nexus node can contains:
> > node {
> > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > };
>
> Couldn't we make something like this work:
>
> connector: __overlay__ {
>
> node {
> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> };
> };
>
> We already have to process all the phandles in the overlay. So this
> just changes handling of 'connector' from being a local phandle which
> we just renumber to an unresolved phandle which we have to lookup and
> replace the phandle uses with.
>
I have tried what you suggested but I've got some issues with dtc.
If a label is not used as a phandle in a dts, dtc doesn't create the phandle
property in the pointed node (except if we use '-@' option but I don't want
to add all symbols in my dtb just for one or two connector symbols).
The way to make sure that the phandle property will be created in the base
DT node by dtc is to reference the label as a phandle in the base DT.
The export-symbols node references this label as a phandle in the base DT
and so, with that, dtc creates the phandle property.
Also, using 'connector: __overlay__' allows to have only one label from
the base DT to be referenced by the overlay.
I don't know if use cases exist where more than one label need to be
referenced but this 'one label' constraint is not present with the
export-symbols node.
The use case where more than one label would be needed is the need for a
phandle from the overlay that couldn't be translated by the connector nexus
node. Maybe pinctrl because it uses of_find_node_by_phandle().
Last point, having export-symbols node makes some nodes explicitly
candidates for an overlay and defines the label to be used on the base DT
node side. This specific label can be described in the node binding as well
as the nexus node properties.
With 'connector: __overlay__', the overlay can be applied on any nodes, at
least from the needed label point of view without any restrictions.
With all of that, I discarded the 'connector: __overlay__' description.
Best regards,
Hervé
+dtc list and David G.
On Tue, Dec 10, 2024 at 2:16 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi Rob,
>
> On Mon, 9 Dec 2024 14:11:09 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> ...
> > >
> > > Our overlay using the nexus node can contains:
> > > node {
> > > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > > };
> >
> > Couldn't we make something like this work:
> >
> > connector: __overlay__ {
> >
> > node {
> > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > };
> > };
> >
> > We already have to process all the phandles in the overlay. So this
> > just changes handling of 'connector' from being a local phandle which
> > we just renumber to an unresolved phandle which we have to lookup and
> > replace the phandle uses with.
> >
>
> I have tried what you suggested but I've got some issues with dtc.
>
> If a label is not used as a phandle in a dts, dtc doesn't create the phandle
> property in the pointed node (except if we use '-@' option but I don't want
> to add all symbols in my dtb just for one or two connector symbols).
Sorry, but that's the cost of using overlays, and that's pretty
orthogonal to the issue of how the overlay references the connector
node.
However, I agree '-@' is a pretty big switch and an issue that's been
discussed before. I also don't like that all labels become part of the
ABI nor the fact that overlays can make any random modification
anywhere in the DT. I would rather see some sort of explicit opt-in
mechanism of nodes we can apply overlays to. Perhaps we could do
something like this:
/export/ label: node {
};
And then __symbols__ can be only those exported labels (unless -@ is used).
> The way to make sure that the phandle property will be created in the base
> DT node by dtc is to reference the label as a phandle in the base DT.
> The export-symbols node references this label as a phandle in the base DT
> and so, with that, dtc creates the phandle property.
>
> Also, using 'connector: __overlay__' allows to have only one label from
> the base DT to be referenced by the overlay.
>
> I don't know if use cases exist where more than one label need to be
> referenced but this 'one label' constraint is not present with the
> export-symbols node.
>
> The use case where more than one label would be needed is the need for a
> phandle from the overlay that couldn't be translated by the connector nexus
> node. Maybe pinctrl because it uses of_find_node_by_phandle().
Labels are an ABI. I can't see that we need to remap them when we can
just say the name must be X. We can have multiple labels on a node as
well. So I think the problem space is purely mapping 1 name to
multiple possible names.
The connector handling has to be addressed binding by binding at least
for each pattern of binding. Pinctrl binding is pretty unique, so we
should make sure we can handle it in this case.
> Last point, having export-symbols node makes some nodes explicitly
> candidates for an overlay and defines the label to be used on the base DT
> node side. This specific label can be described in the node binding as well
> as the nexus node properties.
Both David (IIRC) and I feel that putting the overlay info
(__symbols__, __fixups__, etc.) within the DT data rather than in the
DTB format was a mistake. The export-symbols node expands on that, so
I'm not sure that's the right direction.
(We should have rev'ed the DTB format to store type information for
(at a minimum) phandles.)
> With 'connector: __overlay__', the overlay can be applied on any nodes, at
> least from the needed label point of view without any restrictions.
Certainly that is something I'd like to have some control over. An
/export/ tag would accomplish that.
One idea I have there is that the overlay could have the compatible of
the connector and we use that for matching. That would give us a way
to know what base DTs overlays apply to. Then you could load an
overlay and dispatch it to the correct driver to handle. It would have
to be handled as a special case as the compatible may match, but
wouldn't necessarily be equal values.
I'll throw out another idea. What if we make resolving phandle errors
something that can be handled by the connector driver? The driver
knows 'connector' resolves to the connector node it is applying the
overlay to.
Rob
Hi Rob,
On Tue, 10 Dec 2024 07:46:02 -0600
Rob Herring <robh@kernel.org> wrote:
> +dtc list and David G.
>
> On Tue, Dec 10, 2024 at 2:16 AM Herve Codina <herve.codina@bootlin.com> wrote:
> >
> > Hi Rob,
> >
> > On Mon, 9 Dec 2024 14:11:09 -0600
> > Rob Herring <robh@kernel.org> wrote:
> >
> > ...
> > > >
> > > > Our overlay using the nexus node can contains:
> > > > node {
> > > > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > > > };
> > >
> > > Couldn't we make something like this work:
> > >
> > > connector: __overlay__ {
> > >
> > > node {
> > > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > > };
> > > };
> > >
> > > We already have to process all the phandles in the overlay. So this
> > > just changes handling of 'connector' from being a local phandle which
> > > we just renumber to an unresolved phandle which we have to lookup and
> > > replace the phandle uses with.
> > >
> >
> > I have tried what you suggested but I've got some issues with dtc.
> >
> > If a label is not used as a phandle in a dts, dtc doesn't create the phandle
> > property in the pointed node (except if we use '-@' option but I don't want
> > to add all symbols in my dtb just for one or two connector symbols).
>
> Sorry, but that's the cost of using overlays, and that's pretty
> orthogonal to the issue of how the overlay references the connector
> node.
>
> However, I agree '-@' is a pretty big switch and an issue that's been
> discussed before. I also don't like that all labels become part of the
> ABI nor the fact that overlays can make any random modification
> anywhere in the DT. I would rather see some sort of explicit opt-in
> mechanism of nodes we can apply overlays to. Perhaps we could do
> something like this:
>
> /export/ label: node {
> };
>
> And then __symbols__ can be only those exported labels (unless -@ is used).
>
> > The way to make sure that the phandle property will be created in the base
> > DT node by dtc is to reference the label as a phandle in the base DT.
> > The export-symbols node references this label as a phandle in the base DT
> > and so, with that, dtc creates the phandle property.
> >
> > Also, using 'connector: __overlay__' allows to have only one label from
> > the base DT to be referenced by the overlay.
> >
> > I don't know if use cases exist where more than one label need to be
> > referenced but this 'one label' constraint is not present with the
> > export-symbols node.
> >
> > The use case where more than one label would be needed is the need for a
> > phandle from the overlay that couldn't be translated by the connector nexus
> > node. Maybe pinctrl because it uses of_find_node_by_phandle().
>
> Labels are an ABI. I can't see that we need to remap them when we can
> just say the name must be X. We can have multiple labels on a node as
> well. So I think the problem space is purely mapping 1 name to
> multiple possible names.
So, with a base DT having:
/export/ label0: node@0 {
}
/export/ label1: node@1 {
}
the __symbols__ node will contains:
__symbols__ {
label0 = ...;
label1 = ...;
}
without export-symbols, the overlay will look like this:
connector: __overlay__ {
...
ref = <&connector>;
}
The "connector" label is the only one we can use from the overlay to
reference the base DT (special label defined on the __overlay__ node).
As it is defined to point to __overlay__, it has to be resolved to the
exported symbol that point to the node where the overlay is applied.
If the overlay is applied on node@0, 'connector' is resolved to node@0.
This case cannot be handled:
connector: __overlay__ {
...
ref1 = <&connector>;
ref2 = <&other-label-from-base-dt>;
}
Indeed, only one 'connector' label can be resolved to node@0 or node@1.
other-label-from-base-dt cannot be resolved based on the node the overlay
is applied to.
Again, I am not sure on my side that we have to handle this case of multiple
labels in the overlay that point to the base DT dependent on node@0 or node@1.
On my use case, I considered the node@0 or node@1 as nexus nodes and so, all
GPIOs (soon PWM, I hope, and probably other ressources in the future) can be
referenced using nexus nodes.
>
> The connector handling has to be addressed binding by binding at least
> for each pattern of binding. Pinctrl binding is pretty unique, so we
> should make sure we can handle it in this case.
If pinctrl can be handled using nexus node, it should be ok. Otherwise
things are going to be complicated. Again, with your proposal, we can
reference only one label from the overlay, the node where the overlay
is applied to.
>
> > Last point, having export-symbols node makes some nodes explicitly
> > candidates for an overlay and defines the label to be used on the base DT
> > node side. This specific label can be described in the node binding as well
> > as the nexus node properties.
>
> Both David (IIRC) and I feel that putting the overlay info
> (__symbols__, __fixups__, etc.) within the DT data rather than in the
> DTB format was a mistake. The export-symbols node expands on that, so
> I'm not sure that's the right direction.
>
> (We should have rev'ed the DTB format to store type information for
> (at a minimum) phandles.)
>
> > With 'connector: __overlay__', the overlay can be applied on any nodes, at
> > least from the needed label point of view without any restrictions.
>
> Certainly that is something I'd like to have some control over. An
> /export/ tag would accomplish that.
>
> One idea I have there is that the overlay could have the compatible of
> the connector and we use that for matching. That would give us a way
> to know what base DTs overlays apply to. Then you could load an
> overlay and dispatch it to the correct driver to handle. It would have
> to be handled as a special case as the compatible may match, but
> wouldn't necessarily be equal values.
compatible property will not be enough. We can have two exact same
connectors on the same base board:
/export/ label0: node@0 {
compatible = 'foo,addon-connector';
}
/export/ label1: node@1 {
compatible = 'foo,addon-connector';
}
To load the overlay, we can match compatible for sure but we need to node
the overlay is supposed to be applied to.
Also, it you want to check bindings for node@0 available in the base DT
and bindings in the overlay, having one compatible string with different
meaning will introduce some complexity.
A compatible string can now define the "provider" part (the base DT) and
the "consumer" part (the overlay).
>
>
> I'll throw out another idea. What if we make resolving phandle errors
> something that can be handled by the connector driver? The driver
> knows 'connector' resolves to the connector node it is applying the
> overlay to.
Well, my proposal was to give enough information to the resolver instead of
handling errors.
I probably miss something but I don't see what could be the benefit to do
that in the other way. Can you give me more details about your idea?
Best regards,
Hervé
Hi Rob, David,
On Tue, 10 Dec 2024 15:58:33 +0100
Herve Codina <herve.codina@bootlin.com> wrote:
> Hi Rob,
>
> On Tue, 10 Dec 2024 07:46:02 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > +dtc list and David G.
> >
> > On Tue, Dec 10, 2024 at 2:16 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, 9 Dec 2024 14:11:09 -0600
> > > Rob Herring <robh@kernel.org> wrote:
> > >
> > > ...
> > > > >
> > > > > Our overlay using the nexus node can contains:
> > > > > node {
> > > > > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > > > > };
> > > >
> > > > Couldn't we make something like this work:
> > > >
> > > > connector: __overlay__ {
> > > >
> > > > node {
> > > > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > > > };
> > > > };
> > > >
> > > > We already have to process all the phandles in the overlay. So this
> > > > just changes handling of 'connector' from being a local phandle which
> > > > we just renumber to an unresolved phandle which we have to lookup and
> > > > replace the phandle uses with.
> > > >
> > >
> > > I have tried what you suggested but I've got some issues with dtc.
> > >
> > > If a label is not used as a phandle in a dts, dtc doesn't create the phandle
> > > property in the pointed node (except if we use '-@' option but I don't want
> > > to add all symbols in my dtb just for one or two connector symbols).
> >
> > Sorry, but that's the cost of using overlays, and that's pretty
> > orthogonal to the issue of how the overlay references the connector
> > node.
> >
> > However, I agree '-@' is a pretty big switch and an issue that's been
> > discussed before. I also don't like that all labels become part of the
> > ABI nor the fact that overlays can make any random modification
> > anywhere in the DT. I would rather see some sort of explicit opt-in
> > mechanism of nodes we can apply overlays to. Perhaps we could do
> > something like this:
> >
> > /export/ label: node {
> > };
> >
> > And then __symbols__ can be only those exported labels (unless -@ is used).
> >
> > > The way to make sure that the phandle property will be created in the base
> > > DT node by dtc is to reference the label as a phandle in the base DT.
> > > The export-symbols node references this label as a phandle in the base DT
> > > and so, with that, dtc creates the phandle property.
> > >
> > > Also, using 'connector: __overlay__' allows to have only one label from
> > > the base DT to be referenced by the overlay.
> > >
> > > I don't know if use cases exist where more than one label need to be
> > > referenced but this 'one label' constraint is not present with the
> > > export-symbols node.
> > >
> > > The use case where more than one label would be needed is the need for a
> > > phandle from the overlay that couldn't be translated by the connector nexus
> > > node. Maybe pinctrl because it uses of_find_node_by_phandle().
> >
> > Labels are an ABI. I can't see that we need to remap them when we can
> > just say the name must be X. We can have multiple labels on a node as
> > well. So I think the problem space is purely mapping 1 name to
> > multiple possible names.
>
> So, with a base DT having:
> /export/ label0: node@0 {
> }
>
> /export/ label1: node@1 {
> }
>
> the __symbols__ node will contains:
> __symbols__ {
> label0 = ...;
> label1 = ...;
> }
>
> without export-symbols, the overlay will look like this:
> connector: __overlay__ {
> ...
> ref = <&connector>;
> }
>
> The "connector" label is the only one we can use from the overlay to
> reference the base DT (special label defined on the __overlay__ node).
> As it is defined to point to __overlay__, it has to be resolved to the
> exported symbol that point to the node where the overlay is applied.
>
> If the overlay is applied on node@0, 'connector' is resolved to node@0.
>
> This case cannot be handled:
> connector: __overlay__ {
> ...
> ref1 = <&connector>;
> ref2 = <&other-label-from-base-dt>;
> }
>
> Indeed, only one 'connector' label can be resolved to node@0 or node@1.
> other-label-from-base-dt cannot be resolved based on the node the overlay
> is applied to.
>
> Again, I am not sure on my side that we have to handle this case of multiple
> labels in the overlay that point to the base DT dependent on node@0 or node@1.
>
> On my use case, I considered the node@0 or node@1 as nexus nodes and so, all
> GPIOs (soon PWM, I hope, and probably other ressources in the future) can be
> referenced using nexus nodes.
>
> >
> > The connector handling has to be addressed binding by binding at least
> > for each pattern of binding. Pinctrl binding is pretty unique, so we
> > should make sure we can handle it in this case.
>
> If pinctrl can be handled using nexus node, it should be ok. Otherwise
> things are going to be complicated. Again, with your proposal, we can
> reference only one label from the overlay, the node where the overlay
> is applied to.
>
> >
> > > Last point, having export-symbols node makes some nodes explicitly
> > > candidates for an overlay and defines the label to be used on the base DT
> > > node side. This specific label can be described in the node binding as well
> > > as the nexus node properties.
> >
> > Both David (IIRC) and I feel that putting the overlay info
> > (__symbols__, __fixups__, etc.) within the DT data rather than in the
> > DTB format was a mistake. The export-symbols node expands on that, so
> > I'm not sure that's the right direction.
> >
> > (We should have rev'ed the DTB format to store type information for
> > (at a minimum) phandles.)
> >
> > > With 'connector: __overlay__', the overlay can be applied on any nodes, at
> > > least from the needed label point of view without any restrictions.
> >
> > Certainly that is something I'd like to have some control over. An
> > /export/ tag would accomplish that.
> >
> > One idea I have there is that the overlay could have the compatible of
> > the connector and we use that for matching. That would give us a way
> > to know what base DTs overlays apply to. Then you could load an
> > overlay and dispatch it to the correct driver to handle. It would have
> > to be handled as a special case as the compatible may match, but
> > wouldn't necessarily be equal values.
>
> compatible property will not be enough. We can have two exact same
> connectors on the same base board:
> /export/ label0: node@0 {
> compatible = 'foo,addon-connector';
> }
>
> /export/ label1: node@1 {
> compatible = 'foo,addon-connector';
> }
>
> To load the overlay, we can match compatible for sure but we need to node
> the overlay is supposed to be applied to.
>
> Also, it you want to check bindings for node@0 available in the base DT
> and bindings in the overlay, having one compatible string with different
> meaning will introduce some complexity.
> A compatible string can now define the "provider" part (the base DT) and
> the "consumer" part (the overlay).
>
> >
> >
> > I'll throw out another idea. What if we make resolving phandle errors
> > something that can be handled by the connector driver? The driver
> > knows 'connector' resolves to the connector node it is applying the
> > overlay to.
>
> Well, my proposal was to give enough information to the resolver instead of
> handling errors.
>
> I probably miss something but I don't see what could be the benefit to do
> that in the other way. Can you give me more details about your idea?
>
If I understand correctly, to move forward on the topic, we are waiting from
feedback from David.
Is that correct or do you have in mind an other plan I could explore?
Best regards,
Hervé
On 12/9/24 9:18 AM, Herve Codina wrote:
> Hi,
>
> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> about issues we have with runtime hotplug on non-discoverable busses
> with device tree overlays [1].
>
> On our system, a base board has a connector and addon boards can be
> connected to this connector. Both boards are described using device
> tree. The base board is described by a base device tree and addon boards
> are describe by overlays device tree. More details can be found at [2].
>
> This kind of use case can be found also on:
> - Grove Sunlight Sensor [3]
> - mikroBUS [4]
>
> One of the issue we were facing on was referencing resources available
> on the base board device tree from the addon overlay device tree.
>
> Using a nexus node [5] helps decoupling resources and avoid the
> knowledge of the full base board from the overlay. Indeed, with nexus
> node, the overlay need to know only about the nexus node itself.
>
> For instance, suppose a connector where a GPIO is connected at PinA. On
> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> controller.
>
> The base board can describe this GPIO using a nexus node:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
> };
>
> The connector pin A GPIO can be referenced using:
> <&connector1 0 GPIO_ACTIVE_HIGH>
>
> This implies that the overlay needs to know about exact label that
> references the connector. This label can be different on a different
> board and so applying the overlay could failed even if it is used to
> describe the exact same addon board. Further more, a given base board
> can have several connectors where the exact same addon board can be
> connected. In that case, the same overlay cannot be used on both
> connector. Indeed, the connector labels have to be different.
>
> The export-symbols node introduced by this current series solves this
> issue.
>
> The idea of export-symbols is to have something similar to the global
> __symbols__ node but local to a specific node. Symbols listed in this
> export-symbols are local and visible only when an overlay is applied on
> a node having an export-symbols subnode.
>
> Using export-symbols, our example becomes:
> soc_gpio: gpio-controller {
> #gpio-cells = <2>;
> };
>
> connector1: connector1 {
> /*
> * Nexus node for the GPIO available on the connector.
> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> * controller
> */
> #gpio-cells = <2>;
> gpio-map = <0 0 &soc_gpio 12 0>;
> gpio-map-mask = <0xf 0x0>;
> gpio-map-pass-thru = <0x0 0xf>;
>
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> With that export-symbols node, an overlay applied on connector1 node can
> have the symbol named 'connector' resolved to connector1. Indeed, the
> export-symbols node available at connector1 node is used when the
> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> it will be resolved to connector1 thanks to export-symbols.
>
> Our overlay using the nexus node can contains:
> node {
> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> };
> It used the GPIO 0 from the connector it is applied on.
>
> A board with two connectors can be described with:
> connector1: connector1 {
> ...
> export-symbols {
> connector = <&connector1>;
> };
> };
>
> connector2: connector2 {
> ...
> export-symbols {
> connector = <&connector2>;
> };
> };
>
> In that case, the same overlay with unresolved 'connector' symbol can be
> applied on both connectors and the correct symbol resolution (connector1
> or connector2) will be done.
>
I might be missing something, but how is the correct connector (connector1
or connector2) selected? Let's say I connect my addon board to connector2,
then I apply the addon board's overlay to the base DTB. What connector
just got referenced?
Andrew
> This current series add support for the export-symbols node feature:
> - Patch 1 describes the export-symbols binding
> - Patches 2 to 6 prepare and add the support for the export-symbols
> feature
> - Patch 7 adds an unittest for the export-symbols feature
>
> Best regards,
> Hervé
>
> [1] https://lpc.events/event/18/contributions/1696/
> [2] https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
> [3] https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/
> [4] https://lore.kernel.org/lkml/20240627-mikrobus-scratch-spi-v5-0-9e6c148bf5f0@beagleboard.org/
> [5] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
>
> Herve Codina (7):
> dt-bindings: Add support for export-symbols node
> of: resolver: Introduce get_phandle_from_symbols_node()
> of: resolver: Add export_symbols in of_resolve_phandles() parameters
> of: resolver: Add support for the export symbols node
> of: overlay: Add export_symbols_name in of_overlay_fdt_apply()
> parameters
> of: overlay: Add support for the export symbols node
> of: unittest: Add tests for export symbols
>
> .../devicetree/bindings/export-symbols.yaml | 43 ++++++++++
> drivers/misc/lan966x_pci.c | 3 +-
> drivers/of/of_kunit_helpers.c | 2 +-
> drivers/of/of_private.h | 2 +-
> drivers/of/overlay.c | 30 ++++++-
> drivers/of/resolver.c | 80 ++++++++++++++-----
> drivers/of/unittest-data/Makefile | 5 ++
> .../unittest-data/overlay_export_symbols.dtso | 15 ++++
> .../of/unittest-data/testcases_common.dtsi | 1 +
> .../unittest-data/tests-export-symbols.dtsi | 30 +++++++
> drivers/of/unittest.c | 76 ++++++++++++++++--
> include/linux/of.h | 6 +-
> 12 files changed, 259 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
> create mode 100644 drivers/of/unittest-data/overlay_export_symbols.dtso
> create mode 100644 drivers/of/unittest-data/tests-export-symbols.dtsi
>
On Mon, 9 Dec 2024 10:47:50 -0600
Andrew Davis <afd@ti.com> wrote:
> On 12/9/24 9:18 AM, Herve Codina wrote:
> > Hi,
> >
> > At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> > about issues we have with runtime hotplug on non-discoverable busses
> > with device tree overlays [1].
> >
> > On our system, a base board has a connector and addon boards can be
> > connected to this connector. Both boards are described using device
> > tree. The base board is described by a base device tree and addon boards
> > are describe by overlays device tree. More details can be found at [2].
> >
> > This kind of use case can be found also on:
> > - Grove Sunlight Sensor [3]
> > - mikroBUS [4]
> >
> > One of the issue we were facing on was referencing resources available
> > on the base board device tree from the addon overlay device tree.
> >
> > Using a nexus node [5] helps decoupling resources and avoid the
> > knowledge of the full base board from the overlay. Indeed, with nexus
> > node, the overlay need to know only about the nexus node itself.
> >
> > For instance, suppose a connector where a GPIO is connected at PinA. On
> > the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> > controller.
> >
> > The base board can describe this GPIO using a nexus node:
> > soc_gpio: gpio-controller {
> > #gpio-cells = <2>;
> > };
> >
> > connector1: connector1 {
> > /*
> > * Nexus node for the GPIO available on the connector.
> > * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> > * controller
> > */
> > #gpio-cells = <2>;
> > gpio-map = <0 0 &soc_gpio 12 0>;
> > gpio-map-mask = <0xf 0x0>;
> > gpio-map-pass-thru = <0x0 0xf>;
> > };
> >
> > The connector pin A GPIO can be referenced using:
> > <&connector1 0 GPIO_ACTIVE_HIGH>
> >
> > This implies that the overlay needs to know about exact label that
> > references the connector. This label can be different on a different
> > board and so applying the overlay could failed even if it is used to
> > describe the exact same addon board. Further more, a given base board
> > can have several connectors where the exact same addon board can be
> > connected. In that case, the same overlay cannot be used on both
> > connector. Indeed, the connector labels have to be different.
> >
> > The export-symbols node introduced by this current series solves this
> > issue.
> >
> > The idea of export-symbols is to have something similar to the global
> > __symbols__ node but local to a specific node. Symbols listed in this
> > export-symbols are local and visible only when an overlay is applied on
> > a node having an export-symbols subnode.
> >
> > Using export-symbols, our example becomes:
> > soc_gpio: gpio-controller {
> > #gpio-cells = <2>;
> > };
> >
> > connector1: connector1 {
> > /*
> > * Nexus node for the GPIO available on the connector.
> > * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> > * controller
> > */
> > #gpio-cells = <2>;
> > gpio-map = <0 0 &soc_gpio 12 0>;
> > gpio-map-mask = <0xf 0x0>;
> > gpio-map-pass-thru = <0x0 0xf>;
> >
> > export-symbols {
> > connector = <&connector1>;
> > };
> > };
> >
> > With that export-symbols node, an overlay applied on connector1 node can
> > have the symbol named 'connector' resolved to connector1. Indeed, the
> > export-symbols node available at connector1 node is used when the
> > overlay is applied. If the overlay has an unresolved 'connector' symbol,
> > it will be resolved to connector1 thanks to export-symbols.
> >
> > Our overlay using the nexus node can contains:
> > node {
> > foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> > };
> > It used the GPIO 0 from the connector it is applied on.
> >
> > A board with two connectors can be described with:
> > connector1: connector1 {
> > ...
> > export-symbols {
> > connector = <&connector1>;
> > };
> > };
> >
> > connector2: connector2 {
> > ...
> > export-symbols {
> > connector = <&connector2>;
> > };
> > };
> >
> > In that case, the same overlay with unresolved 'connector' symbol can be
> > applied on both connectors and the correct symbol resolution (connector1
> > or connector2) will be done.
> >
>
> I might be missing something, but how is the correct connector (connector1
> or connector2) selected? Let's say I connect my addon board to connector2,
> then I apply the addon board's overlay to the base DTB. What connector
> just got referenced?
>
A driver for the connector is needed.
The driver applies the overlay using of_overlay_fdt_apply().
The node the overlay has to be applied to is passed by the driver to
of_overlay_fdt_apply().
Even if obsolete because I added one more parameter (export_symbols_name)
in of_overlay_fdt_apply() in this current series, you can have a look at the
following patch to see the connector driver:
https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-8-bc4dfee61be6@bootlin.com/
Best regards,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 12/9/24 11:03 AM, Herve Codina wrote:
> On Mon, 9 Dec 2024 10:47:50 -0600
> Andrew Davis <afd@ti.com> wrote:
>
>> On 12/9/24 9:18 AM, Herve Codina wrote:
>>> Hi,
>>>
>>> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
>>> about issues we have with runtime hotplug on non-discoverable busses
>>> with device tree overlays [1].
>>>
>>> On our system, a base board has a connector and addon boards can be
>>> connected to this connector. Both boards are described using device
>>> tree. The base board is described by a base device tree and addon boards
>>> are describe by overlays device tree. More details can be found at [2].
>>>
>>> This kind of use case can be found also on:
>>> - Grove Sunlight Sensor [3]
>>> - mikroBUS [4]
>>>
>>> One of the issue we were facing on was referencing resources available
>>> on the base board device tree from the addon overlay device tree.
>>>
>>> Using a nexus node [5] helps decoupling resources and avoid the
>>> knowledge of the full base board from the overlay. Indeed, with nexus
>>> node, the overlay need to know only about the nexus node itself.
>>>
>>> For instance, suppose a connector where a GPIO is connected at PinA. On
>>> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
>>> controller.
>>>
>>> The base board can describe this GPIO using a nexus node:
>>> soc_gpio: gpio-controller {
>>> #gpio-cells = <2>;
>>> };
>>>
>>> connector1: connector1 {
>>> /*
>>> * Nexus node for the GPIO available on the connector.
>>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
>>> * controller
>>> */
>>> #gpio-cells = <2>;
>>> gpio-map = <0 0 &soc_gpio 12 0>;
>>> gpio-map-mask = <0xf 0x0>;
>>> gpio-map-pass-thru = <0x0 0xf>;
>>> };
>>>
>>> The connector pin A GPIO can be referenced using:
>>> <&connector1 0 GPIO_ACTIVE_HIGH>
>>>
>>> This implies that the overlay needs to know about exact label that
>>> references the connector. This label can be different on a different
>>> board and so applying the overlay could failed even if it is used to
>>> describe the exact same addon board. Further more, a given base board
>>> can have several connectors where the exact same addon board can be
>>> connected. In that case, the same overlay cannot be used on both
>>> connector. Indeed, the connector labels have to be different.
>>>
>>> The export-symbols node introduced by this current series solves this
>>> issue.
>>>
>>> The idea of export-symbols is to have something similar to the global
>>> __symbols__ node but local to a specific node. Symbols listed in this
>>> export-symbols are local and visible only when an overlay is applied on
>>> a node having an export-symbols subnode.
>>>
>>> Using export-symbols, our example becomes:
>>> soc_gpio: gpio-controller {
>>> #gpio-cells = <2>;
>>> };
>>>
>>> connector1: connector1 {
>>> /*
>>> * Nexus node for the GPIO available on the connector.
>>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
>>> * controller
>>> */
>>> #gpio-cells = <2>;
>>> gpio-map = <0 0 &soc_gpio 12 0>;
>>> gpio-map-mask = <0xf 0x0>;
>>> gpio-map-pass-thru = <0x0 0xf>;
>>>
>>> export-symbols {
>>> connector = <&connector1>;
>>> };
>>> };
>>>
>>> With that export-symbols node, an overlay applied on connector1 node can
>>> have the symbol named 'connector' resolved to connector1. Indeed, the
>>> export-symbols node available at connector1 node is used when the
>>> overlay is applied. If the overlay has an unresolved 'connector' symbol,
>>> it will be resolved to connector1 thanks to export-symbols.
>>>
>>> Our overlay using the nexus node can contains:
>>> node {
>>> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
>>> };
>>> It used the GPIO 0 from the connector it is applied on.
>>>
>>> A board with two connectors can be described with:
>>> connector1: connector1 {
>>> ...
>>> export-symbols {
>>> connector = <&connector1>;
>>> };
>>> };
>>>
>>> connector2: connector2 {
>>> ...
>>> export-symbols {
>>> connector = <&connector2>;
>>> };
>>> };
>>>
>>> In that case, the same overlay with unresolved 'connector' symbol can be
>>> applied on both connectors and the correct symbol resolution (connector1
>>> or connector2) will be done.
>>>
>>
>> I might be missing something, but how is the correct connector (connector1
>> or connector2) selected? Let's say I connect my addon board to connector2,
>> then I apply the addon board's overlay to the base DTB. What connector
>> just got referenced?
>>
>
> A driver for the connector is needed.
> The driver applies the overlay using of_overlay_fdt_apply().
> The node the overlay has to be applied to is passed by the driver to
> of_overlay_fdt_apply().
>
So every connector needs a driver? Most connectors are dumb connectors,
just a bunch of wires broken out to a header.
What if an addon board overlay uses multiple connectors?
If you need a connector-specific driver, and that driver needs to know
which node this overlay will be applied to, then why not just do a
fixup directly to the overlay in the driver?
Andrew
> Even if obsolete because I added one more parameter (export_symbols_name)
> in of_overlay_fdt_apply() in this current series, you can have a look at the
> following patch to see the connector driver:
> https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-8-bc4dfee61be6@bootlin.com/
>
> Best regards,
> Hervé
>
On 09/12/24 23:17, Andrew Davis wrote:
> On 12/9/24 11:03 AM, Herve Codina wrote:
>> On Mon, 9 Dec 2024 10:47:50 -0600
>> Andrew Davis <afd@ti.com> wrote:
>>
>>> On 12/9/24 9:18 AM, Herve Codina wrote:
>>>> Hi,
>>>>
>>>> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
>>>> about issues we have with runtime hotplug on non-discoverable busses
>>>> with device tree overlays [1].
>>>>
>>>> On our system, a base board has a connector and addon boards can be
>>>> connected to this connector. Both boards are described using device
>>>> tree. The base board is described by a base device tree and addon
>>>> boards
>>>> are describe by overlays device tree. More details can be found at [2].
>>>>
>>>> This kind of use case can be found also on:
>>>> - Grove Sunlight Sensor [3]
>>>> - mikroBUS [4]
>>>>
>>>> One of the issue we were facing on was referencing resources available
>>>> on the base board device tree from the addon overlay device tree.
>>>>
>>>> Using a nexus node [5] helps decoupling resources and avoid the
>>>> knowledge of the full base board from the overlay. Indeed, with nexus
>>>> node, the overlay need to know only about the nexus node itself.
>>>>
>>>> For instance, suppose a connector where a GPIO is connected at PinA. On
>>>> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
>>>> controller.
>>>>
>>>> The base board can describe this GPIO using a nexus node:
>>>> soc_gpio: gpio-controller {
>>>> #gpio-cells = <2>;
>>>> };
>>>>
>>>> connector1: connector1 {
>>>> /*
>>>> * Nexus node for the GPIO available on the connector.
>>>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC
>>>> gpio
>>>> * controller
>>>> */
>>>> #gpio-cells = <2>;
>>>> gpio-map = <0 0 &soc_gpio 12 0>;
>>>> gpio-map-mask = <0xf 0x0>;
>>>> gpio-map-pass-thru = <0x0 0xf>;
>>>> };
>>>>
>>>> The connector pin A GPIO can be referenced using:
>>>> <&connector1 0 GPIO_ACTIVE_HIGH>
>>>>
>>>> This implies that the overlay needs to know about exact label that
>>>> references the connector. This label can be different on a different
>>>> board and so applying the overlay could failed even if it is used to
>>>> describe the exact same addon board. Further more, a given base board
>>>> can have several connectors where the exact same addon board can be
>>>> connected. In that case, the same overlay cannot be used on both
>>>> connector. Indeed, the connector labels have to be different.
>>>>
>>>> The export-symbols node introduced by this current series solves this
>>>> issue.
>>>>
>>>> The idea of export-symbols is to have something similar to the global
>>>> __symbols__ node but local to a specific node. Symbols listed in this
>>>> export-symbols are local and visible only when an overlay is applied on
>>>> a node having an export-symbols subnode.
>>>>
>>>> Using export-symbols, our example becomes:
>>>> soc_gpio: gpio-controller {
>>>> #gpio-cells = <2>;
>>>> };
>>>>
>>>> connector1: connector1 {
>>>> /*
>>>> * Nexus node for the GPIO available on the connector.
>>>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC
>>>> gpio
>>>> * controller
>>>> */
>>>> #gpio-cells = <2>;
>>>> gpio-map = <0 0 &soc_gpio 12 0>;
>>>> gpio-map-mask = <0xf 0x0>;
>>>> gpio-map-pass-thru = <0x0 0xf>;
>>>>
>>>> export-symbols {
>>>> connector = <&connector1>;
>>>> };
>>>> };
>>>>
>>>> With that export-symbols node, an overlay applied on connector1 node
>>>> can
>>>> have the symbol named 'connector' resolved to connector1. Indeed, the
>>>> export-symbols node available at connector1 node is used when the
>>>> overlay is applied. If the overlay has an unresolved 'connector'
>>>> symbol,
>>>> it will be resolved to connector1 thanks to export-symbols.
>>>>
>>>> Our overlay using the nexus node can contains:
>>>> node {
>>>> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
>>>> };
>>>> It used the GPIO 0 from the connector it is applied on.
>>>>
>>>> A board with two connectors can be described with:
>>>> connector1: connector1 {
>>>> ...
>>>> export-symbols {
>>>> connector = <&connector1>;
>>>> };
>>>> };
>>>>
>>>> connector2: connector2 {
>>>> ...
>>>> export-symbols {
>>>> connector = <&connector2>;
>>>> };
>>>> };
>>>>
>>>> In that case, the same overlay with unresolved 'connector' symbol
>>>> can be
>>>> applied on both connectors and the correct symbol resolution
>>>> (connector1
>>>> or connector2) will be done.
>>>
>>> I might be missing something, but how is the correct connector
>>> (connector1
>>> or connector2) selected? Let's say I connect my addon board to
>>> connector2,
>>> then I apply the addon board's overlay to the base DTB. What connector
>>> just got referenced?
>>>
>>
>> A driver for the connector is needed.
>> The driver applies the overlay using of_overlay_fdt_apply().
>> The node the overlay has to be applied to is passed by the driver to
>> of_overlay_fdt_apply().
>>
>
> So every connector needs a driver? Most connectors are dumb connectors,
> just a bunch of wires broken out to a header.
>
> What if an addon board overlay uses multiple connectors?
>
> If you need a connector-specific driver, and that driver needs to know
> which node this overlay will be applied to, then why not just do a
> fixup directly to the overlay in the driver?
>
> Andrew
Well, even in the symbols based approach, a driver is needed since stuff
like nexus nodes does need a dummy driver (else the device enters
deferred probing). So it is not a big deal.
>
>> Even if obsolete because I added one more parameter (export_symbols_name)
>> in of_overlay_fdt_apply() in this current series, you can have a look
>> at the
>> following patch to see the connector driver:
>> https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-8-
>> bc4dfee61be6@bootlin.com/
>>
>> Best regards,
>> Hervé
>>
Ayush Singh
On Mon, Dec 9, 2024 at 11:47 AM Andrew Davis <afd@ti.com> wrote:
>
> On 12/9/24 11:03 AM, Herve Codina wrote:
> > On Mon, 9 Dec 2024 10:47:50 -0600
> > Andrew Davis <afd@ti.com> wrote:
> >
> >> On 12/9/24 9:18 AM, Herve Codina wrote:
> >>> Hi,
> >>>
> >>> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> >>> about issues we have with runtime hotplug on non-discoverable busses
> >>> with device tree overlays [1].
> >>>
> >>> On our system, a base board has a connector and addon boards can be
> >>> connected to this connector. Both boards are described using device
> >>> tree. The base board is described by a base device tree and addon boards
> >>> are describe by overlays device tree. More details can be found at [2].
> >>>
> >>> This kind of use case can be found also on:
> >>> - Grove Sunlight Sensor [3]
> >>> - mikroBUS [4]
> >>>
> >>> One of the issue we were facing on was referencing resources available
> >>> on the base board device tree from the addon overlay device tree.
> >>>
> >>> Using a nexus node [5] helps decoupling resources and avoid the
> >>> knowledge of the full base board from the overlay. Indeed, with nexus
> >>> node, the overlay need to know only about the nexus node itself.
> >>>
> >>> For instance, suppose a connector where a GPIO is connected at PinA. On
> >>> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> >>> controller.
> >>>
> >>> The base board can describe this GPIO using a nexus node:
> >>> soc_gpio: gpio-controller {
> >>> #gpio-cells = <2>;
> >>> };
> >>>
> >>> connector1: connector1 {
> >>> /*
> >>> * Nexus node for the GPIO available on the connector.
> >>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> >>> * controller
> >>> */
> >>> #gpio-cells = <2>;
> >>> gpio-map = <0 0 &soc_gpio 12 0>;
> >>> gpio-map-mask = <0xf 0x0>;
> >>> gpio-map-pass-thru = <0x0 0xf>;
> >>> };
> >>>
> >>> The connector pin A GPIO can be referenced using:
> >>> <&connector1 0 GPIO_ACTIVE_HIGH>
> >>>
> >>> This implies that the overlay needs to know about exact label that
> >>> references the connector. This label can be different on a different
> >>> board and so applying the overlay could failed even if it is used to
> >>> describe the exact same addon board. Further more, a given base board
> >>> can have several connectors where the exact same addon board can be
> >>> connected. In that case, the same overlay cannot be used on both
> >>> connector. Indeed, the connector labels have to be different.
> >>>
> >>> The export-symbols node introduced by this current series solves this
> >>> issue.
> >>>
> >>> The idea of export-symbols is to have something similar to the global
> >>> __symbols__ node but local to a specific node. Symbols listed in this
> >>> export-symbols are local and visible only when an overlay is applied on
> >>> a node having an export-symbols subnode.
> >>>
> >>> Using export-symbols, our example becomes:
> >>> soc_gpio: gpio-controller {
> >>> #gpio-cells = <2>;
> >>> };
> >>>
> >>> connector1: connector1 {
> >>> /*
> >>> * Nexus node for the GPIO available on the connector.
> >>> * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
> >>> * controller
> >>> */
> >>> #gpio-cells = <2>;
> >>> gpio-map = <0 0 &soc_gpio 12 0>;
> >>> gpio-map-mask = <0xf 0x0>;
> >>> gpio-map-pass-thru = <0x0 0xf>;
> >>>
> >>> export-symbols {
> >>> connector = <&connector1>;
> >>> };
> >>> };
> >>>
> >>> With that export-symbols node, an overlay applied on connector1 node can
> >>> have the symbol named 'connector' resolved to connector1. Indeed, the
> >>> export-symbols node available at connector1 node is used when the
> >>> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> >>> it will be resolved to connector1 thanks to export-symbols.
> >>>
> >>> Our overlay using the nexus node can contains:
> >>> node {
> >>> foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
> >>> };
> >>> It used the GPIO 0 from the connector it is applied on.
> >>>
> >>> A board with two connectors can be described with:
> >>> connector1: connector1 {
> >>> ...
> >>> export-symbols {
> >>> connector = <&connector1>;
> >>> };
> >>> };
> >>>
> >>> connector2: connector2 {
> >>> ...
> >>> export-symbols {
> >>> connector = <&connector2>;
> >>> };
> >>> };
> >>>
> >>> In that case, the same overlay with unresolved 'connector' symbol can be
> >>> applied on both connectors and the correct symbol resolution (connector1
> >>> or connector2) will be done.
> >>>
> >>
> >> I might be missing something, but how is the correct connector (connector1
> >> or connector2) selected? Let's say I connect my addon board to connector2,
> >> then I apply the addon board's overlay to the base DTB. What connector
> >> just got referenced?
> >>
> >
> > A driver for the connector is needed.
> > The driver applies the overlay using of_overlay_fdt_apply().
> > The node the overlay has to be applied to is passed by the driver to
> > of_overlay_fdt_apply().
> >
>
> So every connector needs a driver? Most connectors are dumb connectors,
> just a bunch of wires broken out to a header.
Yes. So write a dumb-connector driver for all the dumb/simple/generic
connectors.
Though once pinmuxing comes into play, I'm not sure that anything will
be dumb or generic.
Rob
© 2016 - 2025 Red Hat, Inc.