scripts: dts: fix CMake DT API helper for compatible properties #96875
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Our build system DT API has a dt_comp_path() function used to look up paths of nodes with a given compatible. This relies on the generated edt.pickle.cmake file in the build directory to look inside the concrete devicetree for the current application build. The script gen_dts_cmake.py is responsible for generating edt.pickle.cmake. It currently generates the data needed by dt_comp_path() by looking inside each edtlib.Node object's "props" attribute. This attribute in turn is fed by the "properties:" key in the node's YAML binding. This leads to an edge case which is breaking the dt_comp_path() API. In most cases, we don't notice this edge case because base.yaml, which is included by nearly all bindings, has a definition for "compatible" in its "properties:" map. However, bindings are not required to include base.yaml, and bindings do not have to explicitliy define a "compatible" entry in their "properties:". An example of a binding that does neither is fixed-partitions.yaml: it only has #address-cells and #size-cells in its "properties:". Nonetheless, "compatible:" is always a valid property name because it's defined in the DT spec, and we should make the CMake API robustly detect all nodes with a given compatible, regardless of whether that node's binding explicitly defines it or not. To make this happen, rely on the edtlib.Node.compats attribute instead of edtlib.Node.props. The compats attribute is always defined even if the node's YAML binding doesn't have an explicit entry for "compatible". Signed-off-by: Martí Bolívar <[email protected]>
|
decsny
approved these changes
Oct 1, 2025
pdgendt
approved these changes
Oct 1, 2025
nordicjm
approved these changes
Oct 2, 2025
rruuaanng
approved these changes
Oct 2, 2025
tejlmand
approved these changes
Oct 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #96761
Our build system DT API has a dt_comp_path() function used to look up paths of nodes with a given compatible. This relies on the generated edt.pickle.cmake file in the build directory to look inside the concrete devicetree for the current application build.
The script gen_dts_cmake.py is responsible for generating edt.pickle.cmake. It currently generates the data needed by dt_comp_path() by looking inside each edtlib.Node object's "props" attribute. This attribute in turn is fed by the "properties:" key in the node's YAML binding. This leads to an edge case which is breaking the dt_comp_path() API.
In most cases, we don't notice this edge case because base.yaml, which is included by nearly all bindings, has a definition for "compatible" in its "properties:" map. However, bindings are not required to include base.yaml, and bindings do not have to explicitliy define a "compatible" entry in their "properties:". An example of a binding that does neither is fixed-partitions.yaml: it only has #address-cells and #size-cells in its "properties:".
Nonetheless, "compatible" is always a valid property name because it's defined in the DT spec, and we should make the CMake API robustly detect all nodes with a given compatible, regardless of whether that node's binding explicitly defines it or not.
To make this happen, rely on the edtlib.Node.compats attribute instead of edtlib.Node.props. The compats attribute is always defined even if the node's YAML binding doesn't have an explicit entry for "compatible".