It can be convenient to "iterate" over the elements of a property, in
the same way it is convenient to "iterate" over enabled instances.
Add a new macro for doing this, along with a DT_INST_FOREACH_PROP_ELEM
variant.
This is likely to be more convenient than UTIL_LISTIFY or FOR_EACH in
some situations because:
- it handles inputs of any length
- compiler error messages will be shorter and more self-contained
- it is easier to use with phandle-array type properties, which
require more complicated macro boilerplate when used with
util_macro.h APIs
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a helper which allows you to skip the intricacies of instance
numbers to express the intent of "give me a random enabled node with
this compatible; I don't care which one".
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Make sure that child bindings with their own compatibles are treated
as first-class bindings. Do this by making sure that nodes whose
bindings are defined via 'child-binding:' are picked up as bus nodes,
instead of a parent bus node of the same type.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Mark all variants of the DT_DMAS_LABEL APIs:
* DT_DMAS_LABEL_BY_IDX
* DT_DMAS_LABEL_BY_NAME
* DT_INST_DMAS_LABEL_BY_IDX
* DT_INST_DMAS_LABEL_BY_NAME
As deprecated in favor of utilizing:
* DT_DMAS_CTLR_BY_IDX
* DT_DMAS_CTLR_BY_NAME
* DT_DMAS_CTLR
* DT_INST_DMAS_CTLR_BY_IDX
* DT_INST_DMAS_CTLR_BY_NAME
* DT_INST_DMAS_CTLR
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
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>
Add two new macros for getting the chip select GPIO controller from a
SPI device:
- DT_SPI_DEV_CS_GPIOS_CTLR()
- DT_INST_SPI_DEV_CS_GPIOS_CTLR()
Now that we can get struct device pointers at build time directly from
a devicetree node identifier, it's useful to be able to get a
node_id for a CS GPIO controller from the SPI device, because that's
necessary for setting up the gpio_dev in a struct spi_cs_control.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This returns the node identifier for a node's bus. For example, for a
device on an I2C bus, it would return a node identifier for the I2C
bus controller.
We already have a DT_BUS() and DT_INST_BUS_LABEL(), but there hasn't
been a request or need for DT_INST_BUS() up until now, so it didn't
exist yet.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Provide a helper to extract the devicetree node_id for a CLOCKS
controller from a clocks phandle array. This can be used with
DEVICE_DT_GET() to directly reference the corresponding controller
device.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Co-authored-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
It can be useful to check if an unknown devicetree node identifier
refers to a known node. Add a helper for this. Under the hood, we take
advantage of the ordinals API, which provides the unique identifiers
we need.
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>
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>
Many of the messages that are printed on failed test assertions in the
devicetre API tests provide little value (e.g. merely restating some
expression in the test) or are outright confusing (do they print the
thing that should have happened, or what went wrong?).
The ztest framework already prints the expression that failed, so
there's no need for this.
There are some exceptions, like in test_dep_ord(), where the messages
do print useful information, namely failing array indexes.
Keep those, but give the file a cleanup by removing the cruft. There
are alread cases where we use "" or NULL for self-explanatory
assertions in this file; we're just expanding that practice.
No changes to test results expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Convert tests to DEVICE_{DT_}DEFINE instead of DEVICE_AND_API_INIT
so we can deprecate DEVICE_AND_API_INIT in the future.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
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>
Test macro DT_PROP_BY_PHANDLE_IDX_OR. There are two tests, one when
the property exists and other when the property is not set.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Provide a helper to extract the devicetree node_id for a GPIO
controller from a gpio phandle array. This can be used with
DEVICE_DT_GET() to directly reference the corresponding controller
device.
Signed-off-by: Peter Bigot <peter.bigot@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>
Add the first API functions that directly deal with node dependency
ordinals as determined by edtlib:
- DT_DEP_ORD(node_id): node_id's ordinal
- DT_REQUIRES_DEP_ORDS(node_id): list of dep ordinals for node_id's
direct dependencies
- DT_SUPPORTS_DEP_ORDS(node_id): list of dep ordinals for nodes
depending directly on node_id
- DT_INST_ equivalents
This is not meant to be an exhaustive set of macros related to
dependency ordinals; rather, it's a starting out point meant to enable
initial struct device dependency tracking work. We can add more if
needed.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
In case a "required: False" enum binding doesn't mention a
default value, but a default value makes sense to be set in the code,
DT_ENUM_IDX_OR could be used to provide the default idx to be used.
New macro comes with appropriate tests.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Add a variety of property and specifier cell accessors that fall back
on a default value supplied by the caller if the devicetree does not
contain the requested data.
This is useful for avoiding use of COND_CODE_1() and similarly tricky
macros in applications and drivers.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Move some common macros shared between different unit test functions
up to the top of the file to make them easier to spot and keep them a
bit tidier.
This cleanup excludes macros that are only used for specific purposes
in a single function.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is preparation for an additional test suite specifically for the
legacy API which will be added next.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>