Whenever a child-binding: dict has a compatible, we ought to make
that available in EDT._compat2binding. If we don't, we can't look it
up later.
This has adverse effects like missing child bindings which describe
buses.
Fixes: #32071
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Commit 0d4dca10b2 ("scripts: edtlib:
child binding compatibles match parents") was a hack meant to keep the
edtlib.Binding class in place without modifying some twister behavior
that needed further changes to work properly with first-class binding
objects.
This is a hack and is no longer necessary, so back out of this change.
Child Binding objects now have None compatible properties unless the
binding YAML explicitly sets a compatible.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Allow users to set the new EDT constructor argument which errors out
on deprecated properties via a command line argument.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We'd like to start eliminating deprecated properties from upstream
Zephyr devicetrees. To make that possible in the build system, add an
EDT kwarg that does just that.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Commit 6bf761fc0a ("dts: Remove support
for deprecated DTS binding syntax") removed most of the support for
the 'legacy' bindings syntax.
A few straggler keys are still around in the bindings check code,
though. This allows some legacy keys which should cause errors to pass
silently instead.
Fix the error handling and print good errors for cases which are
removed, just in case someone is still using them somewhere.
Clean up some other error messages in the same function while we're
here.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This macro returns a node's name with unit-adddress, given its node
identifier.
The node name is useful information for the user to utilize for debug
information, similar to DT_NODE_PATH, or DT_LABEL.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Change the use of a f-string to a normal string as there is nothing
that needs formatting in the particular instance.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
While using the encoded path to a device tree node guarantees a unique
identifier for the corresponding device there is a limit on the number
of characters of that name that can be captured when looking up a
device by name from user mode, and the path can exceed that limit.
Synthesize a unique name from the node dependency ordinal instead, and
update the gen_defines script to record the name associated with the
full path in the extern declaration.
Add a build-time check that no device is created with a name that
violates the user mode requirement.
Also update the network device DTS helper functions to use the same
inference for dev_name and label that the real one does, since they
bypass the real one.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Before we had a bindings index in the documentation, the generated
header file was (somewhat unfortunately) often our best reference for
what a particular binding or property within a binding ends up doing,
so it made good sense to put the description in the generated file.
Now that we have HTML documentation that's a bit more digestible than
the generated file, though, we can just point users at that. Do that
and remove the inline description from the generated file.
This makes it possible to put C-style multiline comments in the
descriptions themselves, which will be done in subsequent patches.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This macro returns a node's full path, given its node identifier.
The entire path to a node is useful information for the user which can
be added to build-time error messages.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Generate a header (device_extern.h) that handles extern of possible
device structs that would come from devicetree. This removes the need
for DEVICE_DT_DECLARE and DEVICE_DT_INST_DECLARE which we can remove.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
There are some drivers in the tree that support devices on multiple
different buses, although so far this has not been represented in
device tree using the bus concept. In order to convert these drivers &
bindings to refer to a formal bus in device tree we need to be able to
match bindings which lack an explicit "on-bus: ..." value against any
parent bus. This will also be needed for any external bindings, since
those would not be aware of on-bus (as it's a Zephyhr-specific
extension).
The two drivers I'm particularly targeting is the ns16550 UART driver
(drivers/serial/uart_ns16550.c) and the DW I2C driver
(drivers/i2c/i2c_dw.c). They both support devices with a fixed MMIO
address as well as devices connected and discovered over PCIe. The
only issue is that instead of encoding the bus information the proper
DT way these bindings use a special "pcie" property in the DT node
entries to indicate whether the node is on the PCIe bus or not.
Being able to convert the above two drivers to use the DT bus concept
allow the removal of "hacks" like this:
if DT_INST_PROP(0, pcie) || \
DT_INST_PROP(1, pcie) || \
DT_INST_PROP(2, pcie) || \
DT_INST_PROP(3, pcie)
to the more intuitive:
if DT_ANY_INST_ON_BUS_STATUS_OKAY(pcie)
This also has the benefit that the driver doesn't need to make any
arbitrary assumptions of how many matching devices there may be but
works for any number of matches. This is already a problem now since
e.g. the ns16550 driver assumes a maximum of 4 nodes, whereas
dts/x86/elkhart_lake.dtsi defines up to 9 different ns16550 nodes.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The DTS language permits zeroing out phandles in a phandle array to
say "there's nothing at this index", and dtlib manages that correctly,
but edtlib and gen_defines.py aren't equipped to do so.
Fix this by allowing None elements in the lists of ControllerAndData
values returned by edtlib for such properties.
Handle that in gen_defines.py by setting the generated
DT_N_<node>_P_<prop>_IDX_<i>_EXISTS macro to 0 in such cases.
The DT_N_<node>_P_<prop>_LEN macro still accounts for the entire
length of the phandle-array; it's just that some indexes may be
missing data.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
These are likely enough defined by mistake to emit a warning for.
Adjust tests to match, tweaking the test_warnings() setup: now that
we've got several test cases, it's a bit cleaner not to have to
copy/paste the ('edtlib', WARNING, ...) part of every expected log
record tuple.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The edtlib strategy for emitting warnings is to print directly to
standard error. This in turn requires hacks to drop stored references
to stderr in various _warn_file attributes so the EDT objects can be
pickled.
In general, I think it's not really appropriate for library modules
like edtlib to be printing to stderr directly. The user should be able
to configure logging for general utility data munging modules like
this as they please, and not just deciding what file to print to.
Move this around so the standard logging module is used instead. We
can preserve backwards compatibility in gen_defines by customizing the
'edtlib' logging module behavior so it prints the exact same thing it
always has.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Whenever a devicetree binding defines a string property whose
enumerated values are all tokenizable, generate C macros for each
property value that are the corresponding tokens.
Note that "token" is distinct from "identifier": both 'foo' and '123'
are valid tokens, but only 'foo' is a valid identifier. We permit some
strings which are not valid identifiers in anticipation that the
generalization may be useful, e.g. when defining macros that paste the
token onto a prefix that makes the whole thing an identifier.
Fixes: #21273
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add enum_tokenizable and enum_upper_tokenizable to PropertySpec. These
allow a PropertySpec to declare that it both has an enumeration of
values and all of them are strings which are "tokenizable". Don't
bother extending Property with these; the user can access the
information through Property.spec now, so the extra delegation is
unnecessary.
See the docstrings for details on what "tokenizable" means. The basic
idea is that we should be able to use the DT binding's enum values as
C 'enum' enumerators in a "reasonable way".
Add val_as_token to Property. This produces a canonical token for the
property value.
Add tests for this feature in particular and property enumerations in
general.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
In the 'normal' case of a property whose definition is taken from a
binding YAML file, a fair number (three at present) of the attributes
available on Property objects are directly taken from the
corresponding PropertySpec object.
Refactor the internals of how a Property gets initialized so that it
has a direct reference to its PropertySpec, and make those attributes
properties which just delegate to the PropertySpec (which in turn just
delegate to the binding). Additionally, expose the PropertySpec
directly.
This will make it easier to extend the Property class with additional
attributes that normally come from the PropertySpec without having to
touch all the locations where Property.__init__ is called.
In the case of the 'default' properties, we handle this by dummying
out some PropertySpec objects. These dummy PropertySpecs in turn
require a dummy Binding.
This change has the advantage that it improves the degree to which
these defaults are checked, e.g. it makes sure that 'status' is one of
the permitted values.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a use case for checking the results of a DT_PROP_HAS_IDX()
call with COND_CODE_1(). That won't work because its expansion is an
integer comparison; COND_CODE_1() expects a literal 1 or 0.
Adjust the macro implementation so it expands to a literal 1 or 0.
Make this work even when the index argument needs an expansion while
we're at it.
Fixes: #29833
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes: #29758
Commit 7165b77a81 ("scripts: edtlib:
refactor for first class bindings") introduced a Binding class.
Its child_binding instance attribute has a compatible which can be
None. Adjust this behavior so the child Binding object has the same
compatible as the parent binding which ultimately has a compatible.
Without this, sanitycheck's expr_parser is doing some matching on
compatibles in child nodes that is producing unexpected results.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The child_binding object should default to having a path and
compatible that matches the parent's. Mark it as xfail because the
compatible part is failing.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a convenience function for creating a bunch of Binding objects
from files in a directory.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add the ability to mark a property as 'deprecated' to get a warning that
it will be removed in the future.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
_prop_val comment referred to one of the arguments called "optional"
however the code has changed to call that argument "required" now. Fix
up the comment block to use the correct argument name and semantics of
that argument.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
