using "dt_node_prop_enabled" to filter out supported platforms
1. check node existing.
2. check prop in node.
3. check the prop is True.
Signed-off-by: Hake Huang <hake.huang@oss.nxp.com>
This small change concerns the following filter functions:
1. `dt_compat_enabled(C)`:
There's a node with compatible `C` and status "okay".
2. `dt_enabled_alias_with_parent_compat(A, C)`:
There's a node with alias `A` and status "okay", and its parent
has compatible `C`.
3. `dt_label_with_parent_compat_enabled(L, C)`:
There's a node with label `L`, and its parent has compatible `C`
and status "okay".
All three functions involve checking whether some node or its parent has
a given compatible, but the way this has been checked is inconsistent.
Function (1) has done it with this Python conditional:
compat in node.compats
while (2) and (3) have used:
parent.matching_compat == compat
The first check works well with nodes that have multiple compatibles,
and it is more aligned with the notion of "has_compat" as seen in the
devicetree macros for C, CMake, and Kconfig.
Arguably, `matching_compat` shouldn't have been used here, because it is
actually a property of a node's binding, moreso than of the node itself.
In practice, it's usually equal to the first compatible for which edtlib
has found a binding, which at first glance is just more constrained than
the `node.compats` check. However, there also exist obscure cases where
the `node.compats` are empty, while the `node.matching_compat` is not.
For now, the three functions can use a combined check, to improve
consistency and utility while avoiding breakage:
node.matching_compat == compat or compat in node.compats
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
It has been deprecated since Zephyr v2.6.0.
The filter that replaced it - `dt_enabled_alias_with_parent_compat` -
had shared code with it, which can now be inlined into `ast_expr()` to
match the parser's overall code structure.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This function takes a node label (not a label property) and returns
true if a node with such label exists and the node is enabled.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
In dt_label_with_parent_compat_enabled, it maybe that there is
no node matching expected label.
In this case don't generate error, but return False.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Function used for filtering "dt_compat_enabled_with_label" was not
working as expected as it was not taking into account that we're
looking for a children/parent combination:
Provided "compat" with enabled status should be the one of the parent
of the node matching given label.
Function is then reworked to take this into account.
And to make it's usage clear:
- function name is changed to be clearer on the intention
- args order is reversed to be more logical wrt the intention
Users of the function are also updated to take the change into
account.
Fixes#36093
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use edt.label2node in dt_compat_enabled_with_label DT filter.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Co-authored-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The function returns true if the node with the referenced
node label is compatible and enabled.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Originally added in 7733b94224.
This filter is not well-formed. It's meant to match nodes like
/leds/led_0 in this DTS:
/ {
aliases {
led0 = &led0;
};
leds {
compatible = "gpio-leds";
led0: led_0 {
gpios = <...>;
label = "LED 0";
};
};
};
Uses look like this:
filter: dt_compat_enabled_with_alias("gpio-leds", "led0")
But notice how the led_0 node doesn't have compatible "gpio-leds";
it's actually the *parent* node that has that compatible.
Replace this with a new filter, dt_enabled_alias_with_parent_compat(),
which is used like this:
filter: dt_enabled_alias_with_parent_compat("led0", "gpio-leds")
This has a name and argument order that makes the meaning of the
filter clearer.
Replace in-tree users with the new filter.
Deprecate the old filter and warn about its use using the standard
logging module.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Move the "module" classes used by sanitycheck into a new location under
pylib, where we can have other python libraries reside instead of having
them all over the place.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2020-12-11 14:13:02 -05:00
Renamed from scripts/sanity_chk/expr_parser.py (Browse further)
