An export-symbols node allows to export symbols for symbols resolution
performed when applying a device tree overlay.
When a device tree overlay is applied on a node having an export-symbols
node, symbols listed in the export-symbols node are used to resolve
undefined symbols referenced from the overlay.
This allows:
- Referencing symbols from an device tree overlay without the need to
know the full base board. Only the connector definition is needed.
- Using the exact same overlay on several connectors available on a given
board.
For instance, the following description is supported with the
export-symbols node:
- Base device tree board A:
...
foo_connector: connector1 {
export-symbols {
connector = <&foo_connector>;
};
};
bar_connector: connector2 {
export-symbols {
connector = <&bar_connector>;
};
};
...
- Base device tree board B:
...
front_connector: addon-connector {
export-symbols {
connector = <&front_connector>;
};
};
...
- Overlay describing an addon board the can be connected on connectors:
...
node {
...
connector = <&connector>;
...
};
...
Thanks to the export-symbols node, the overlay can be applied on
connector1 or connector2 available on board A but also on
addon-connector available on board B.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
.../devicetree/bindings/export-symbols.yaml | 43 +++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
diff --git a/Documentation/devicetree/bindings/export-symbols.yaml b/Documentation/devicetree/bindings/export-symbols.yaml
new file mode 100644
index 000000000000..0e404eff8937
--- /dev/null
+++ b/Documentation/devicetree/bindings/export-symbols.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/export-symbols.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Export symbols
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ An export-symbols node allows to export symbols for symbols resolution
+ performed when applying a device tree overlay.
+
+ When a device tree overlay is applied on a node having an export-symbols
+ node, symbols listed in the export-symbols node are used to resolve undefined
+ symbols referenced from the overlay.
+
+properties:
+ $nodename:
+ const: export-symbols
+
+patternProperties:
+ "^[a-zA-Z_]?[a-zA-Z0-9_]*$":
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A symbol exported in the form <symbol_name>=<phandle>.
+
+additionalProperties: false
+
+examples:
+ - |
+ /*
+ * Allows 'connector' symbol used in a device-tree overlay to be resolved to
+ * connector0 when the device-tree overlay is applied on connector0 node.
+ */
+ connector0: connector0 {
+ export-symbols {
+ connector = <&connector0>;
+ };
+ };
+...
--
2.47.0
Hi Hervé,
On Mon, 9 Dec 2024 16:18:19 +0100
Herve Codina <herve.codina@bootlin.com> wrote:
> An export-symbols node allows to export symbols for symbols resolution
> performed when applying a device tree overlay.
>
> When a device tree overlay is applied on a node having an export-symbols
> node, symbols listed in the export-symbols node are used to resolve
> undefined symbols referenced from the overlay.
>
> This allows:
> - Referencing symbols from an device tree overlay without the need to
> know the full base board. Only the connector definition is needed.
>
> - Using the exact same overlay on several connectors available on a given
> board.
>
> For instance, the following description is supported with the
> export-symbols node:
> - Base device tree board A:
> ...
> foo_connector: connector1 {
> export-symbols {
> connector = <&foo_connector>;
> };
> };
>
> bar_connector: connector2 {
> export-symbols {
> connector = <&bar_connector>;
> };
> };
> ...
>
> - Base device tree board B:
> ...
> front_connector: addon-connector {
> export-symbols {
> connector = <&front_connector>;
> };
> };
> ...
>
> - Overlay describing an addon board the can be connected on connectors:
> ...
> node {
> ...
> connector = <&connector>;
> ...
> };
> ...
>
> Thanks to the export-symbols node, the overlay can be applied on
> connector1 or connector2 available on board A but also on
> addon-connector available on board B.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> .../devicetree/bindings/export-symbols.yaml | 43 +++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
>
> diff --git a/Documentation/devicetree/bindings/export-symbols.yaml b/Documentation/devicetree/bindings/export-symbols.yaml
> new file mode 100644
> index 000000000000..0e404eff8937
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/export-symbols.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/export-symbols.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Export symbols
> +
> +maintainers:
> + - Herve Codina <herve.codina@bootlin.com>
> +
> +description: |
> + An export-symbols node allows to export symbols for symbols resolution
> + performed when applying a device tree overlay.
> +
> + When a device tree overlay is applied on a node having an export-symbols
> + node, symbols listed in the export-symbols node are used to resolve undefined
> + symbols referenced from the overlay.
> +
> +properties:
> + $nodename:
> + const: export-symbols
> +
> +patternProperties:
> + "^[a-zA-Z_]?[a-zA-Z0-9_]*$":
I think the '?' should not be there: "^[a-zA-Z_][a-zA-Z0-9_]*$".
Otherwise LGTM.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Luca, On Mon, 9 Dec 2024 18:27:22 +0100 Luca Ceresoli <luca.ceresoli@bootlin.com> wrote: ... > > +patternProperties: > > + "^[a-zA-Z_]?[a-zA-Z0-9_]*$": > > I think the '?' should not be there: "^[a-zA-Z_][a-zA-Z0-9_]*$". > You're right. I will update in the next iteration. Thanks, Hervé
On Mon, 09 Dec 2024 16:18:19 +0100, Herve Codina wrote:
> An export-symbols node allows to export symbols for symbols resolution
> performed when applying a device tree overlay.
>
> When a device tree overlay is applied on a node having an export-symbols
> node, symbols listed in the export-symbols node are used to resolve
> undefined symbols referenced from the overlay.
>
> This allows:
> - Referencing symbols from an device tree overlay without the need to
> know the full base board. Only the connector definition is needed.
>
> - Using the exact same overlay on several connectors available on a given
> board.
>
> For instance, the following description is supported with the
> export-symbols node:
> - Base device tree board A:
> ...
> foo_connector: connector1 {
> export-symbols {
> connector = <&foo_connector>;
> };
> };
>
> bar_connector: connector2 {
> export-symbols {
> connector = <&bar_connector>;
> };
> };
> ...
>
> - Base device tree board B:
> ...
> front_connector: addon-connector {
> export-symbols {
> connector = <&front_connector>;
> };
> };
> ...
>
> - Overlay describing an addon board the can be connected on connectors:
> ...
> node {
> ...
> connector = <&connector>;
> ...
> };
> ...
>
> Thanks to the export-symbols node, the overlay can be applied on
> connector1 or connector2 available on board A but also on
> addon-connector available on board B.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> .../devicetree/bindings/export-symbols.yaml | 43 +++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/export-symbols.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
compress: size (5) error for type phandle
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.example.dtb: uimage@100000: compress: b'lzma\x00' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241209151830.95723-2-herve.codina@bootlin.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Hi Rob, Krzysztof, Conor,
On Mon, 09 Dec 2024 10:26:26 -0600
"Rob Herring (Arm)" <robh@kernel.org> wrote:
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> compress: size (5) error for type phandle
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.example.dtb: uimage@100000: compress: b'lzma\x00' is not of type 'object', 'integer', 'array', 'boolean', 'null'
> from schema $id: http://devicetree.org/schemas/dt-core.yaml#
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241209151830.95723-2-herve.codina@bootlin.com
>
I am bothered with this issue and I can't see what's wrong with my binding
export-symbols.yaml and why it has impacts on other binding such as the
example in fixed-partitions.yaml.
Can you help me in understanding what I missed that leads to this behavior.
The idea in export-symbols.yaml was:
- Constraint the name of the node to be 'export-symbols' with:
properties:
$nodename:
const: export-symbols
- Constraint properties in the node to be in the form
'label_name = <phandle>;'
Many properties of this form are allowed.
- Do not allow any other kind of properties.
I thought that only bindings referencing export-symbols.yaml or bindings
using the 'export-symbols' node name would have been impacted but it seems
the it is not the case.
Best regards,
Hervé
© 2016 - 2025 Red Hat, Inc.