Pin the types-PyYAML version to 6.0.7. Version 6.0.8 is causing CI
errors for other pull requests, so we need this in to get other PRs
moving.
Fixes: #46286
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It can be useful to know what the index of a particular child is in
the list of nodes. Add a a helper for computing that and some test
cases.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Don't let a malformed devicetree escape as a DTError. Wrap it in an
EDTError instead, so callers can just rely on the edtlib APIs as is
generally expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
A GCC linemarker of the form:
# 1 "filename" 2 3 4
or so is not currently being handled, because the current regular
expression assumes the "flags" values (the numbers after "filename")
are limited to a single value. Tweak the regular expression to allow
for up to 4 flags, which is what GCC documents it may emit:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/cpp/Preprocessor-Output.html
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This adds some tests in test_edtlib.py and test.dts to check all
common possible combination of ranges property usage and handling
by edtlib.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
As described in IEEE Std 1275-1994, the PCIe bindings uses the ranges
property to describe the PCI I/O and memory regions.
Add parsing of this property in edtlib.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Currently all the *-names and *-cells properties are derived from the
name of the base <name>s property. This is a limitation because:
- It forces the base property name to be plural ending in -s
- It doesn't allow the english exception of plural words ending in -es
With this patch we add one additional property 'specifier-space' that
can be used to explicitly specify the base property name.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Suggested-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Node names are subject to the rules in table 2.1 of the devicetree
specification v0.3, while properties are subject to rules in table
2.2. These rules mean that some property names are invalid node names.
However, the same regular expression is being used to validate the
names of nodes and properties in dtlib. This leads to invalid node
names being allowed to pass. Fix this issue by moving the node name
handling code to the Node constructor and checking against the
characters in table 2.1.
The test cases claim that the existing behavior matches dtc. I can't
reproduce that. I get errors when I use invalid characters (like "?")
in a node name. For example:
foo.dts:3.8-11: ERROR (node_name_chars): /node?: Bad character '?' in
node name
Try to make the dtlib error message reminiscent of that.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is unused since the very beginning of the module's introduction.
It looks like it was abandoned in favor of the approach where each
token can have only one capturing group.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This became useless when _init_tokens() was refactored not to use
global variables (in "dtlib: use IntEnum for token IDs"), and the
linter is complaining about it now.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Similarly to what was done for dtlib, use f-strings in places where it
improves readability. Some places, e.g. __repr__ methods that
construct a string using something like
"<SomeType, {}>".format(", ".join(...))
are better left off as-is.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The library was originally developed before Python 3.6 was the minimum
supported version. Use f-strings now that we can do that, as they tend
to be easier to read.
There are a few places where str.format() makes sense to preserve,
specifically where the same argument is used multiple times; leave
those alone.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
If the user passes None, set the internal attribute to an empty dict
instead. This lets us avoid some None checking and simplifies things
without changing semantics -- if the user *does* pass an empty dict,
the results are the same.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a common extension for YAML files. We don't have to allow it
in upstream zephyr, but we should allow downstream DTS_ROOTs to have
this ability.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Commit c4079e4be2
("scripts: rework edtlib warnings-turned-errors") was trying to abort
on unknown vendor prefix, but the error log is not fatal.
Fix it by using the same error handling function we use when aborting
due to deprecated property usage.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
There are way too many one-off vendor prefixes set up for individual
boards to bother tracking them in vendor-prefixes.txt. As a practical
matter, the compatible for the root node doesn't matter anyway. So
just relax our check for that node.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Create a "global" gen_defines.py option and edtlib.EDT constructor
kwarg that turns edtlib-specific warnings into errors. This applies to
edtlib-specific warnings only. Warnings that are just dupes of dtc
warnings are not affected.
Use it from twister to increase DT testing coverage in upstream zephyr.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
An unknown vendor prefix is now a warning. We augment the list of
vendor prefixes passed by the user with a grandfathered-in bunch from
Linux.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
As a first step towards being more forgiving on invalid inputs, allow
string-valued aliases properties that do not point to valid nodes when
the user requests permissiveness.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Modeled after dtc's --force option, the idea is this will try harder
and harder over time to produce an object despite malformed input.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
I made an alignment error in a dts binding, but the build was
successful. After some debugging I found the following warning
explaining the problem:
'/home/casper/src/zephyrproject/zephyr/dts/bindings/gpio/
gpio-keys.yaml' appears in binding directories but isn't valid
YAML: while parsing a block mapping
in "<unicode string>", line 11, column 8
did not find expected key
in "<unicode string>", line 18, column 9
I think this should be an error as there shouldn't be any invalid yaml.
Signed-off-by: Casper Meijn <casper@meijn.net>
