It is possible the overall length of "interrupt-map" is shorter than
expected. A likely scenario is if "#address-cells" in the interrupt
parent is not accounted for and there is only a single map entry. With
multiple entries, one of the other tests would likely fail.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Message-ID: <20240531133149.1498139-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The value passed to the <ctype.h> functions shall be the value of an unsigned
char or EOF. It is implementation-defined if the char type is signed or
unsigned. Cast to unsigned char to avoid undefined behaviour on systems where
char is signed.
This cast is already present in other parts of the code base.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If an endpoint node has a 'reg' property which consists of more than
one cell (4 bytes) and given that matching '#address-cells' and '#size-cells'
properties are specified on the port node an assertion is triggered in
check_graph_child_address() before the relevant diagnostic checks in
check_graph_reg() (called by check_graph_port() and check_graph_endpoint()) are executed.
The issue is fixed by making graph_child_address depend on the
graph_port and graph_endpoint checks.
Additionally the assertion can also be triggered if the length of the
'reg' property is less than 4 bytes e.g. by specifying
'reg = "a";'. In that case however other warnings are produced
highlighting the malformed property before dtc crashes.
Example dts file triggering the issue:
/dts-v1/;
/ {
bar: bar {
port {
bar_con: endpoint {
remote-endpoint = <&foo_con>;
};
};
};
foo {
port {
#address-cells = <1>;
#size-cells = <1>; // should always be 0
foo_con: endpoint@1 {
reg = <1 2>; // causes assertion failure instead of diagnostic
remote-endpoint = <&bar_con>;
};
};
};
};
Signed-off-by: Johannes Beisswenger <johannes.beisswenger@cetitec.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Dts files which contain an 'endpoint' node as a direct child of the
root node cause a segmentation fault inside check_graph_node(). This
type of error can easily happen when a 'remote-endpoint' property is
accidentally placed outside the corresponding endpoint and port nodes.
Example with 'endpoint' node:
/dts-v1/;
/ { endpoint {}; };
Example with remote-endpoint property:
/dts-v1/;
/ {
foo {
remote-endpoint = <0xdeadbeef>;
};
};
Signed-off-by: Johannes Beisswenger <johannes.beisswenger@cetitec.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently if there is a valid 10-bit address the following warning is
always displayed due to the 7-bit check failing due to reg > 0x7f
"I2C address must be less than 7-bits, got "0x800000a6". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix the property"
Fix this issue by checking if a 10-bit address is expected, and is valid in separate if statements.
Fixes: 8259d59f ("checks: Improve i2c reg property checking")
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If the corresponding '#xxx-cells' value is much too large, an integer
overflow can prevent the checks in check_property_phandle_args() from
correctly determining that the checked property is too short for the
given cells value. This leads to an infinite loops.
This patch fixes the bug, and adds a testcase for it. Further
information in https://github.com/dgibson/dtc/issues/64
Reported-by: Anciety <anciety@pku.edu.cn>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a check for parsing 'interrupt-map' properties. The check primarily
tests parsing 'interrupt-map' properties which depends on and the parent
interrupt controller (or another map) node.
Note that this does not require '#address-cells' in the interrupt-map
parent, but treats missing '#address-cells' as 0 which is how the Linux
kernel parses it. There's numerous cases that expect this behavior.
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20211015213527.2237774-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The interrupt provider check currently checks if an interrupt provider
has #interrupt-cells, but not whether #interrupt-cells is present
outside of interrupt-providers. Rework the check to cover the latter
case.
Cc: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20211011191245.1009682-4-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
'#address-cells' is only needed when parsing 'interrupt-map' properties, so
remove it from the common interrupt-provider test.
Cc: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20211011191245.1009682-3-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If '#interrupt-cells' doesn't pass checks, no reason to run interrupt
provider check.
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20211011191245.1009682-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The upper limit of the bus-range is specified by the second cell of the
bus-range property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Message-Id: <20210629114304.2451114-1-thierry.reding@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness in
comparisons in various parts in checks.c.
Fix those by making all affected variables unsigned. This covers return
values of the (unsigned) size_t type, phandles, variables holding sizes
in general and loop counters only ever counting positives values.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20210618172030.9684-5-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In several places we check for a returned phandle value to be valid,
for that it must not be 0 or "-1".
Wrap this check in a static inline function in dtc.h, and use ~0U instead
of -1 on the way, to keep everything in the unsigned realm.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20210618172030.9684-4-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In a number of places we check if one number is a multiple of another,
using a modulus. In some of those cases the divisor is potentially zero,
which needs special handling or we could trigger a divide by zero.
Introduce an is_multiple_of() helper to safely handle this case, and use
it in a bunch of places. This should close Coverity issue 1501687, maybe
others as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With the prior commit, this check is now redundant.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20210526010335.860787-4-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There's already a check for '#.*-cells' properties, so let's enable it for
all the ones we already know about.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20210526010335.860787-3-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Makes the logic more clear
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Message-Id: <20210504035944.8453-4-ilya.lipnitskiy@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There are no instances of nr-gpio in the Linux kernel tree, only
"[<vendor>,]nr-gpios", so make the check stricter.
nr-gpios without a "vendor," prefix is also invalid, according to the DT
spec[0], and there are no DT files in the Linux kernel tree with
non-vendor nr-gpios. There are some drivers, but they are not DT spec
compliant, so don't suppress the check for them.
[0]:
Link: cb53a16a1e/schemas/gpio/gpio-consumer.yaml (L20)
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Message-Id: <20210504035944.8453-2-ilya.lipnitskiy@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Treat a node-name and property name at the same level of tree as
a warning
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Message-Id: <20210210193912.799544-1-kumar.gala@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The devicetree spec limits the valid character set to:
A-Z
a-z
0-9
,._+-
while property can additionally have '?#'. Change the check to match
the spec.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Message-Id: <20210209184641.63052-1-kumar.gala@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some PCI bridge nodes have child nodes such as an interrupt controller
which are not PCI devices. Allow these nodes which don't have a
unit-address.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20200928201942.3242124-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The i2c bindings in the kernel tree describe support for 10 bit
addressing, which must be indicated with the I2C_TEN_BIT_ADDRESS flag.
When this is set the address can be up to 10 bits. When it is not set
the address is a maximum of 7 bits.
See Documentation/devicetree/bindings/i2c/i2c.txt.
Take into account this flag when checking the address is valid.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20200622031005.1890039-3-joel@jms.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
dtc does a sanity check on reg properties that they are within the 10
bit address range for i2c slave addresses. In the case of multi-master
buses or devices that act as a slave, the binding may describe an
address that the bus will listen on as a device. Do not warn when this
flag is set.
See Documentation/devicetree/bindings/i2c/i2c.txt.
This fixes the following build warnings reported by Stephen and by Arnd:
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4:
Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:
I2C bus unit address format error, expected "40000010"
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:128.3-30:
Warning (i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10:reg:
I2C address must be less than 10-bits, got "0x40000010"
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20200622031005.1890039-2-joel@jms.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
An interrupt provider (an actual interrupt-controller node or an
interrupt nexus) should have both #address-cells and #interrupt-cells
properties explicitly defined.
Add an extra test for this. We check for the #interrupt-cells property
already, but this does not cover every controller so far, only those that
get referenced by an interrupts property in some node. Also we miss
interrupt nexus nodes.
A missing #address-cells property is less critical, but creates
ambiguities when used in interrupt-map properties, so warn about this as
well now.
This removes the now redundant warning in the existing interrupts test.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200515141827.27957-2-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In check_unit_address_vs_reg() warning message already says 'reg _or_
ranges' when reg or ranges are present but unit name is missing. Add
this message for compatibility to say "reg _or_ ranges" when unit name
is present but neither reg nor ranges are present.
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org>
Message-Id: <20200308165643.19281-1-arkadiusz@drabczyk.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Generalize the existing 'ranges' check to also work for 'dma-ranges'
which has the same parsing requirements.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20200303193931.1653-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The 'alias_paths' check verifies that each property in /aliases is a valid
path to another node. However this can cans false positives trees where
the /aliases node has a phandle property, which isn't in this format but
is allowed. In particular this situation can be common with trees dumped
from some real OF systems (which typically generate a phandle for every
node).
Special case this to avoid the spurious error.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Replace instances of GPLv2 or later boilerplate with SPDX tags.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20190620211944.9378-2-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If running on a tree with an 'interrupt-parent' property which contains
an invalid phandle (0 or -1, not merely for a node which doesn't exist),
then check_interrupts_property() will trip the assertion in
get_node_by_phandle().
There's logic that almost detects this, but it only handles the overlay
case, where we can't fully check because the links will be fixed up later.
For the non-overlay case, this is definitely a bad property, but we
shouldn't crash. Fix it by failing the check early.
Fixes: c1e55a5513 ("checks: fix handling of unresolved phandles for dts plugins")
Fixes: ee3d26f696 ("checks: add interrupts property check")
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 4038fd9005 ("dtc: add ability to make nodes conditional on them
being referenced") added the new /omit-if-no-ref/ directive to mark
nodes as eligible to be discarded if not referenced. The mechanism to
process this happens before the symbol generation phase. This means even
if symbol generation is requested and the node has a label, it will be
discarded if there are no references to it within the same file.
This is probably not what people expect. When using symbol generation to
compile base device trees for applying overlays, nodes with labels could
be referenced by the overlays, and therefore should be preserved.
Check if the node has a label and symbol generation was requested before
dropping the node.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Message-Id: <20190327035352.24036-1-wens@csie.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Should be "endpoint" rather than "endpont"
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Message-Id: <6fcb6e160163467b706c312ffe307ee8a5d9255d.1552328099.git.leonard.crestez@nxp.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There are various SoCs that have 2 different peripheral blocks at the
same register offset. However, we might have one block marked as
status = "disabled" and the other status = "ok". In such cases we
shouldn't warn about duplicate unit-address.
Here's a cut down example that we would warning about before:
/dts-v1/;
/ {
#address-cells = <0x01>;
#size-cells = <0x01>;
soc {
#address-cells = <0x01>;
#size-cells = <0x01>;
compatible = "simple-bus";
ranges;
i2c0: i2c@40003000 {
compatible = "nordic,nrf-i2c";
reg = <0x40003000 0x1000>;
status = "ok";
};
spi0: spi@40003000 {
compatible = "nordic,nrf-spi";
reg = <0x40003000 0x1000>;
status = "disabled";
};
};
};
We introduce 'unique_unit_address_if_enabled' check that is disabled by
default.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 3616b9a811 ("checks: Use source position information for check
failures") causes crashes when there's a check message with multiple
source annotations. Drop the errant addition to the str pointer left
over from the previous version.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that we retain source position information of nodes and properties,
make that the preferred file name (and position) to print out in check
failures. This will greatly simplify finding and fixing check errors
because most errors are in included source .dtsi files and they get
duplicated every time the source file is included.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Printing to stderr as we build up the check message results in
interleaving of messages when multiple instances of dtc are running.
Change the message output to use an intermediate buffer for constructing
the message and then output the message to stderr with a single fputs.
While perhaps there is no guarantee that fputs will be atomic, this gets
rid of any interleaved output that previously occurred on Linux.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The entire check_msg function is under the if condition except for
va_start/va_end. Move these and invert the if condition saving a level
of indentation.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If the SPI bus controller is being used for 'spi-slave' mode some of the
checks we have need to change:
In 'spi-slave' mode #address-cells should be 0, as any children don't
have a reg property.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Since commit 7975f64222 ("Fix widespread incorrect use of strneq(),
replace with new strprefixeq()") simple-bus checks have been silently
skipped. The problem was 'end - str' is one more than the string length
and the strnlen in strprefixeq fails. This can't be fixed simply by
subtracting one as it is possible to have multiple '\0' at the end of
the property. Fix this by making the 'compatible' property string list
check a dependency, and then we can assume the property is null
terminated and we can just use streq() for comparisons.
Add some tests so the problem doesn't happen again.
Fixes: 7975f64222 ("Fix widespread incorrect use of strneq(), replace with new strprefixeq()")
Reported-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add SPI bus type detection and checks. The node name is the
preferred way to find SPI buses as there is no common compatible or
property which can be used. There are a few common properties used in
child nodes, so they can be used as a fallback detection method. This
lets us warn if the SPI controller is not properly named 'spi@...'.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add I2C bus type detection and checks. The node name is used to find I2C
buses as there is no common compatible or property which can be used to
identify I2C controllers/buses. There are some common I2C properties,
but they are not used frequently enough to match on.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A number of platforms have a need to reduce the number of DT nodes,
mostly because of two similar constraints: the size of the DT blob, and
the time it takes to parse it.
As the DT is used in more and more SoCs, and by more projects, some
constraints start to appear in bootloaders running from SRAM with an
order of magnitude of 10kB. A typical DT is in the same order of
magnitude, so any effort to reduce the blob size is welcome in such an
environment.
Some platforms also want to reach very fast boot time, and the time it
takes to parse a typical DT starts to be noticeable.
Both of these issues can be mitigated by reducing the number of nodes in
the DT. The biggest provider of nodes is usually the pin controller and
its subnodes, usually one for each valid pin configuration in a given
SoC.
Obviously, a single, fixed, set of these nodes will be used by a given
board, so we can introduce a node property that will tell the DT
compiler to drop the nodes when they are not referenced in the tree, and
as such wouldn't be useful in the targetted system.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Having a 'bus-range' property for PCI bridges should not be required,
so remove the warning when missing. There was some confusion with the
Linux kernel printing a message that no property is present and the OS
assigned the bus number. This message was intended to be informational
rather than a warning.
When the firmware doesn't enumerate the PCI bus and leaves it up to the
OS to do, then it is perfectly fine for the OS to assign bus numbers
and bus-range is not necessary.
There are a few cases where bus-range is needed or useful as Arnd
Bergmann summarized:
- Traditionally Linux avoided using multiple PCI domains, but instead
configured separate PCI host bridges to have non-overlapping
bus ranges so we can present them to user space as a single
domain, and run the kernel without CONFIG_PCI_DOMAINS.
Specifying the bus ranges this way would and give stable bus
numbers across boots when the probe order is not fixed.
- On certain ARM64 systems, we must only use the first
128 bus numbers based on the way the IOMMU identifies
the device with truncated bus/dev/fn number. There are probably
others like this, with various limitations.
- To leave some room for hotplugged devices, each slot on
a host bridge can in theory get a range of bus numbers
that are available when assigning bus numbers at boot time
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When refactoring node path printing, the code checking for duplicate
node names was accidentally changed to print the name of the parent
node, instead of the name of the duplicated child node.
Fixes: 88960e3989 ("checks: centralize printing of node path in check_msg")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add checks for DT graph bindings. These checks check node names,
unit-addresses and link connections on ports, port, and endpoint nodes.
The graph nodes are matched by finding nodes named 'endpoint' or with a
'remote-endpoint' property. We can't match on 'ports' or 'port' nodes
because those names are used for non-graph nodes. While the graph nodes
aren't really buses, using the bus pointer to tag matched nodes is
convenient.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Child nodes with the same unit-address (and different node names) are
either an error or just bad DT design. Typical errors are the unit-address
is just wrong (i.e. doesn't match reg value) or multiple children using the
same overlapping area. Overlapping regions are considered an error in new
bindings, but do exist in some existing trees. This check should flag
most but not all of those errors. Finding all cases would require doing
address translations and creating a full map of address spaces.
Mixing more than one address/number space at a level is bad design. It only
works if both spaces can use the same #address-cells and #size-cells sizes.
It also complicates parsing have a mixture of types of child nodes. The
best practice in this case is adding child container nodes for each
address/number space or using additional address bits/cells to encode
different address spaces.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Overlay fragments are traditionally named "fragment@NNN" but don't have
have a 'reg' property, amongst other differences from normal nodes. Really
we should treat overlay fragments fundamentally differently, but for the
moment, suppress the common warnings about the fragment names with this
simple hack.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rob Herring (Arm)