Use Galak's idea from
https://github.com/zephyrproject-rtos/zephyr/pull/18313 to read the
'properties: compatible: constraint: "foo"' string from bindings in a
more robust way.
First, check if any of the compatible strings are in the file (needed as
an optimization). If any of them are, do a more careful check for the
'properties: compatible: constraint: ...' value matching a compatible,
to filter out false positives from comments and the like.
This commit a no-op in itself besides making things a bit more robust,
but it'll make later work easier (supporting multiple compatibles for a
binding, in a dt-schema-like way).
Co-authored-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Renaming bindings to consistently be called foo-controller.yaml for
controllers and foo-device.yaml for devices (last one mostly makes sense
for devices on buses and the like).
I was thinking of having a plain foo.yaml be the controller as well, but
!include interrupt.yaml
reads much worse than
!include interrupt-controller.yaml
Another advantage of this approach is that no binding changes meaning
(which could be risky). It's just adding suffixes to filenames.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Sanity-checking each !included file separately was inherited from the
old scripts. It makes it messy to check that combinations of fields make
sense, e.g. to check 'const:' or 'default:' against 'type:', since those
fields might come from different files (this is handy, since it makes
sense to just add/change a 'const:' value, for example).
Drop the requirement that each !included file is a complete binding in
itself, and treat them as binding fragments instead. Only check the
final merged binding.
This also means that !included files no longer need to have a
'description:' or 'title:' (those have always been unused for !included
files), so remove those, and add comments that explain what the
fragments are for instead. That should demystify bindings a bit.
Also fix the descriptions of i2c.yaml, i2s.yaml, spi.yaml, and
uart.yaml. They're for controllers, not devices. These are copy-paste
error from the corresponding device .yaml files.
Piggyback some indentation consistency nits in binding-template.yaml.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Similar to edtlib._err(). Just saves a bunch of 'raise DTError'.
Also add tests for some errors from the global to_num() and to_nums()
functions that were untested.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The public DT.get_node() function was used during parsing to look up
paths in references like &{/foo/bar}, along with an ugly
'DT._is_parsing' flag to adapt its behavior (to not mention aliases in
error messages).
Split out common node lookup code needed during parsing and by
get_node() instead, and stop using get_node() during parsing. This
allows '_is_parsing' to be removed and untangles things a bit.
Piggyback some other small reference-related cleanups, and fix an issue
with the filename/linenr being given twice in some error messages.
This commit also removes the index of path components from error
messages, but just the string is probably good enough.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Convert type from compound to phandle-array for various bindings that
have properties like like <FOO>-gpios, pwms, clocks,
interrupt-extended, etc. that are phandle-array's.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Require either type TYPE_EMPTY ('ranges;') or TYPE_NUMS
('ranges = < 1 2 ... >;').
Putting the check in _check_dt() means it will run for all nodes,
including nodes without bindings, which is handy.
The _split() function already gives a decent error message if 'ranges'
has unexpected length, so skip checking the length.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Deriving the type from looking at Property.val gets awkward e.g. when
there are many types that make Property.val a list. Instead, save the
type as given in the binding in Property.type.
Let Property.type just be a string. This has typo potential, but is nice
and flexible (and easy to print), and errors will probably be pretty
obvious.
Show the type in Property.__repr__() as well. This automatically gives
some test coverage.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add two new type-checked property types 'phandles' and 'phandle-array'
to edtlib.
'phandles' is for pure lists of phandles, with no other data, like
foo = < &bar &baz ... >
'phandle-array' is for lists of phandles and (possibly) numbers, like
foo = < &bar 1 2 &baz 3 4 ... >
dt-schema also has the 'phandle-array' type.
Property.val (in edtlib) is set to an array of Device objects for the
'phandles' type.
For the 'phandle-array' type, no Property object is created. This type
is only used for type checking.
Also refactor how types that do not create a Property object
('phandle-array' and 'compound') are handled. Have _prop_val() return
None for them.
The new types are implemented with two new TYPE_PHANDLES and
TYPE_PHANDLES_AND_NUMS types at the dtlib level. There is also a new
Property.to_nodes() functions for fetching the Nodes for an array of
phandles, with type checking.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Previously, Property.to_node() would allow assignments like
x = < 1 >;
as long as 1 happened to be a valid phandle. This was deliberate, but
might hide errors, and would make the planned 'phandles' (list of
phandles) and 'phandle-array' (list of phandles and numbers) types a bit
too similar to 'type: array'.
Change Property.to_node() to only accept
x = < &foo >;
This is probably all we need, and if you really need to accept manually
specified phandles, it can be worked around in other ways.
Piggyback some consistency nits in error messages from the
Property.to_*() functions.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The contents of 'sub-node:' was assigned as-is as the binding, bypassing
_check_binding(). This also hid an error in
test-bindings/sub-node-parent.yaml.
Require 'sub-node:' to just have 'properties:' in it, and sanity-check
the properties like for regular bindings.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
* Add "#address-cells" and "#size-cells" to base.yaml as properties
that can exist on any node. Cleanup other bindings that inherit
from the base.yaml.
* Add "status" property with an enum of valid options.
* Add "interrupt-parent" to base.yaml. It's a phandle to the node
which is the interrupt controller for the interrupt.
* Add "interrupt-extended" to base.yaml. Provides a way to specify
an interrupt-parent and specifier in a single property. Useful if
a device has multiple interrupts in which different interrupts go
to different interrult controllers.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We don't want any defines generated for 'status', 'interrupt-parent',
and 'interrupts-extended' properties. So skip them in write_props if
we see them.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
In most cases #<FOO>-cells should be a constant. For example in spi
controller #address-cells should be 1, and #size-cells should be 0.
Use the const attribute to specify such single known values. Add const
value to missing bindings which have cells.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add a 'const' property to bindings for any properties that are expected
to have a specifi known value. For example, #address-cells for an I2C
bus should always be '1'. So we can do something like the following in
the I2C bus binding:
"#address-cells":
type: int
category: required
const: 1
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Move the enum checking before we early out for '#' and '-map' properties
so they can benefit from it. Also make the error messages for failed
'enum' check more informative by including the paths to the .dts file
and the binding for the node.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Change binding for ST sensors property 'irq-gpios' to optional for the
cases of in which its obvious from the driver that the property is
optional (there's an ifdef based on the #define
DT_INST_0_ST_LIS2DH_IRQ_GPIOS_*).
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Fix a bug where in tx data PDU enqueued, while a ctrl PDU is
deferred due to Encryption setup being in progress, is
leaked causing HCI Tx Buffer Overflow crash.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix check in start encryption to disallow new encryption
setup while there is one already in progress.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix MIC failure on re-encryption procedure when responding
at the same time to peer initiated feature request.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix control tx queue handling to correctly pause control PDU
responses during encryption setup.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Added implementation to cache Data Length Procedure when
another control procedure is in progress.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Workaround, defer peer initiated encryption while local
initiated procedure with instant is not complete. Peer
master has sent CONN_UPDATE_IND in response to
CONN_PARAM_REQ, and also has initiated a Encryption Setup
thereafter. In this case, avoid corruption of the connection
update context by deferring the Encryption Setup.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix implementation to correctly cache the control procedures
initiatable by local and peer. And, fix feature exchange and
version information procedures from being disallowed by
having then as cached requests to the controller.
Relates to #15256.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
All compiler flag checks are cached for build-time performance reasons
except for the test that tests the toolchain itself.
It is believed that this test was left uncached because at the time,
there was not enough trust in the caching mechanism. But time has
shown that the caching mechanism is safe. So cache this test as well.
This improves build-time performance and also reduces noise in the
logs.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When guessing the build folder, the current path might not exist at all,
leading to an uncaught exception when trying to list its folders. Fix
this by making sure the path exists at all first.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This adds a simple infinite loop when double exception is raised.
Without this, if double exception occurs, it would execute
arbitrary code.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This provides an implemention for z_soc_irq_is_enabled()
as it is needed for multi-level interrupts.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This follows the z_arch_irq_en-/dis-able() so that the SoC
definitions are responsible for functions related to multi-level
interrupts.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
