With -Wsign-compare, compilers warn about a mismatching signedness
in comparisons in fdt_move().
This stems from "bufsize" being passed in as a signed integer, even
though we would expect a buffer size to be positive.
Short of changing the prototype, check that bufsize is not negative, and
cast it to an unsigned type in the comparison.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20201001164630.4980-3-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in a comparison in fdt_add_string_().
Make all variables unsigned, and express the negative offset trick via
subtractions in the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20201001164630.4980-2-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in a comparison in fdt_node_offset_by_phandle().
Uses a better suited bitwise NOT operator to denote the special value of
-1, which automatically results in an unsigned type.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-14-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness in
a comparison in overlay_update_local_node_references().
This happens because the division of a signed int by an unsigned int
promotes the dividend to unsigned first (ANSI C standard 6.1.3.8).
As in this case we basically just divide by 4, we can do the division
separately earlier, which preserves the original type.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-12-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in a comparison in fdt_resize().
A negative buffer size will surely do us no good, so let's rule this
case out first.
In the actual comparison we then know that a cast to an unsigned type is
safe.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-10-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in a comparison in fdt_splice_().
Since we just established that oldlen is not negative, we can safely
cast it to an unsigned type.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-8-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness in
comparisons in fdt_get_string().
In the first two cases, we have just established that the signed values
are not negative, so it's safe to cast the values to an unsigned type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-7-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in a comparison in fdt_grab_space_().
All the involved values cannot be negative, so let's switch the types of
the local variables to unsigned to make the compiler happy.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-4-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about a mismatching signedness
in comparisons in fdt_mem_rsv().
Since all involved values must be positive, change the used types to be
unsigned.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-3-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
With -Wsign-compare, compilers warn about mismatching signedness in
comparisons in fdt_offset_ptr().
This mostly stems from "offset" being passed in as a signed integer,
even though the function would not really tolerate negative values.
Short of changing the prototype, check that offset is not negative, and
use an unsigned type internally.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Message-Id: <20200921165303.9115-2-andre.przywara@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some systems don't install third party software includes in a default
path (like FreeBSD), add yaml cflags to fix compilation.
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
fdt_check_node_offset_() checks for a valid offset but also changes the
offset by calling fdt_next_tag(). Hence, do not skip this function if
ASSUME_VALID_INPUT is set but only omit the initial offset check in that
case.
As this function works very similar to fdt_check_prop_offset_(), do the
offset check there as well depending on ASSUME_VALID_INPUT.
Message-Id: <1913141.TlUzK5foHS@noys4>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If used on its own, util.h needs stdlib.h for exit(), malloc() and
realloc().
Signed-off-by: Andrei Ziureaev <andrei.ziureaev@arm.com>
Message-Id: <20200721155900.9147-2-andrei.ziureaev@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Prevent undefined behavior when shifting by a number that's bigger than
or equal to the width of the first operand.
Signed-off-by: Andrei Ziureaev <andrei.ziureaev@arm.com>
Message-Id: <20200714154542.18064-2-andrei.ziureaev@arm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
fdt_check_header assumes that its argument points to a complete header
and can read data beyond the FDT_V1_SIZE bytes which fdt_check_full
can provide.
fdt_header_size can safely return a header size with FDT_V1_SIZE bytes
available and will return a usable value even for a corrupted header.
Signed-off-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Message-Id: <20200709041451.338548-1-patrick.oppenlander@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When using overlays, a target-path property pointing to the root node is
quite common. However, "dtc -O dts" prints it as a byte array:
target-path = [2f 00];
instead of a string:
target-path = "/";
For guess_value_type() to consider a value to be a string, it must
contain less nul bytes than non-nul bytes, thus ruling out strings
containing only a single character. Allow printing such strings by
relaxing the condition slightly.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Message-Id: <20200623094343.26010-1-geert+renesas@glider.be>
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>
Signed-off-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Message-Id: <20200616011217.15253-1-patrick.oppenlander@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Message-Id: <20200618042117.131731-1-patrick.oppenlander@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This condition uses bitwise OR but should be logical OR. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: kernel test robot <lkp@intel.com>
Message-Id: <20200615160033.87328-1-sjg@chromium.org>
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>
implemented originally for the QEMU consumer of libfdt.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20200512103315.1926-1-cfontana@suse.de>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Because of the convention of packed representations in property layouts,
it's not uncommon to have integer values in properties which aren't
naturally aligned. Thus, there are several places in the dtc code where we
cast a potentially unaligned byte pointer into an integer pointer and load
it directly. On a number of architectures (including sparc64 and arm) this
won't work and will cause a fault. In some cases it may be trapped and
emulated by the kernel, but not always.
Therefore, replace such direct unaligned reads with a helper which will
handle unaligned data reads (a variant on the fdtXX_ld() functions already
used in libfdt).
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>
libfdt: fix undefined behaviour in fdt_splice_()
Along the lines of commit d0b3ab0a0f ("libfdt: Fix undefined behaviour
in fdt_offset_ptr()"), fdt_splice_() similarly may not use pointer
arithmetic to do overflow checks. (The left side of the checks added by
d4c7c25c9e ["libfdt: check for potential overrun in _fdt_splice()"]
doesn't really lend itself to similar replacement though.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Message-Id: <f2d09e81-7cb8-c5cc-9699-1ac05b0626ff@suse.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We've accumulated some new features and a bunch of fixes. Also the
versioning on v1.5.1 was messed up :(. Prepare for another release.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently the test runner script always expects to be run from within the
tests/ subdirectory of a dtc source tree: it looks for dtc and other
binaries in the parent of the current directory and for the libfdt shared
library in ../libfdt.
That works great with make check and for testing a build you've just made.
However, sometimes it's useful to test a dtc & libfdt which have already
been installed on the system, or which for whatever reason are located
somewhere else.
This patch allows the test runner script to do this when TEST_BINDIR and/or
TEST_LIBDIR environment variables are set.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Support for YAML output in dtc is optional (to cover systems that don't
have libyaml). Currently the tests for yaml output test if the libyaml
package is locally installed.
That duplicates similar logic in the Makefile, and worse it will cause
failed tests if the user explicitly disables YAML support, rather than
simply not having libyaml installed.
Fix this by having the test script use the NO_YAML variable exported by
make. Fall back to the current test if the variable isn't set, such as
when running the script manually.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
One of our testcases creates a .bak file from invoking sed. Fix that to be
removed by make clean, and also ignore it in git to avoid clutter.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently the test script bases whether to run the Python tests on whether
it can see a built Python module. That can easily be fooled if there is
a stale module there.
Instead, have it actually look at the NO_PYTHON variable exported from the
Makefile. If the variable doesn't exist (such as if we're running the
script manually) fall back on the old logic.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We have several $(NO_*) variables used to disable optional features.
$(NO_PYTHON) is encoded as empty for "include Python support" and anything
else for "disable Python support".
However the other variables - $(NO_YAML) and $(NO_VALGRIND) - use 0 for
"include" and 1 for "disable". Change $(NO_PYTHON) to work consistently
with the others.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Make automatically passes its variables through the environment, so
we don't need to explicitly copy this one into the test script.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently run_tests.sh needs the $PYTHON environment variable set to
correctly run pylibfdt tests. The Makefile does this for make check, but
it breaks if the script is run manually. Add a fallback to handle that
case.
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>
This error indicates a logic bug in the code calling libfdt, so VALID_DTB
is not really the right check. Update it to use VALID_INPUT instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-4-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If libfdt returns -FDT_ERR_INTERNAL that generally indicates a bug in the
library. Add a new assumption for these cases since it should be save to
disable these checks regardless of the input.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-3-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a little more detail in a few of these comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-2-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fix 'saftey' and 'additional' typos noticed in the assumption series.
Reword the ASSUME_NO_ROLLBACK slightly to improve clarity.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200302190255.51426-1-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This function is used to perform a full check of the device tree. Allow
it to be excluded if all assumptions are enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-9-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a way to remove this check and the reordering code, which is
unnecessary if the dtb is known to be correctly ordered.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-8-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling FDT_ASSUME_LATEST to disable version checks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-7-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling FDT_ASSUME_NO_ROLLBACK to disable rolling back after a
failed operation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200220214557.176528-6-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Allow enabling ASSUME_VALID_INPUT to disable sanity checks on the device
tree and the parameters to libfdt. This assumption covers that cases where
the problem could be with either.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-5-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Support ASSUME_VALID_DTB to disable some sanity checks
If we assume that the DTB itself is valid then we can skip some checks and
save code space. Add various conditions to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-4-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a new ASSUME_MASK option, which allows for some control over the
checks used in libfdt. With all assumptions enabled, libfdt assumes that
the input data and parameters are all correct and that internal errors
cannot happen.
By default no assumptions are made and all checks are enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-3-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There does not seem to be a strong reason to inline this function. Also
we are about to add some extra code to it which will increase its size.
Move it into fdt.c and use a simple declaration in libfdt.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Message-Id: <20200220214557.176528-2-sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This reverts commit 18d7b2f4ee.
This doesn't work for properties such as 'interrupt-map' that has
phandle in the middle of an entry. It would also not work for a 0 or -1
phandle value that acts as a NULL.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20200124144657.29749-1-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
gcc 10 will default to -fno-common, which causes this error at link
time:
(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:
dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
26 | extern YYLTYPE yylloc;
| ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
127 | extern YYLTYPE yylloc;
| ^~~~~~
cc1: all warnings being treated as errors
which means the declaration is completely redundant and can just be
dropped.
Signed-off-by: Dirk Mueller <dmueller@suse.com>
Message-Id: <20200114175341.2994-1-dmueller@suse.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Andre Przywara