This is done to get the target path for the overlay nodes which is very useful
in many cases. For example, Xen hypervisor needs it when applying overlays
because Xen needs to do further processing of the overlay nodes, e.g. mapping of
resources(IRQs and IOMMUs) to other VMs, creation of SMMU pagetables, etc.
Signed-off-by: Vikram Garhwal <fnu.vikram@xilinx.com>
Message-Id: <1637204036-382159-2-git-send-email-fnu.vikram@xilinx.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>
The overlay path ends with trailing zero. When adding this path
as property value, this character should be removed. This is the case
when the overlay adds a node with an alias.
Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
Message-Id: <20191111080444.9819-2-stefan@olimex.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Symbols from overlays are merged into the target tree, and are required to
have the form:
/fragment@XXX/__overlay__/...
If any symbols don't have this form, the overlay is rejected.
But there's not really anything wrong with an overlay having "local"
labels referring to a fragment node or some other metadata, that's not
expected to end up in a target tree.
So change our overlay application to simply ignore such symbols rather than
fail.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When applying overlays, we merge symbols from the overlay into the target
tree. At the moment the logic for this assumes all symbols in the overlay
are attached to a node of the form:
/fragment@XXX/__overlay__/relative/path
And will end up applied to the relative/path node under the fragment's
target.
However, this disallows the case of a symbol in the form just:
/fragment@XXX/__overlay__
This does have a pretty obvious sensible meaning: attach the new symbol
directly to the fragment's target, but we don't currently do that.
It's pretty easy to workaround this limitation in one's overlays, but it's
also easy to handle in the overlay applying code, so we might as well
extend it to cover this case.
Reported-by: Christophe Braillon
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Replace instances of dual GPLv2 or BSD license boilerplate with SPDX tags.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20190620211944.9378-3-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The typos have been discovered with the "codespell" utility.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190520081209.20415-1-thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use the fdt_find_max_phandle() function instead of the deprecated
fdt_get_max_phandle() function.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Message-Id: <20190326153302.17109-2-thierry.reding@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Many of the libfdt entry points call some sort of sanity check function
before doing anything else. These need to do slightly different things for
the various classes of functions.
The read-only version is shared with the exported fdt_check_header(), which
limits us a bit in how we can improve it. For that reason split the two
functions apart (though the exported one just calls the ro one for now).
We also rename the functions for more consistency - they're all named
fdt_XX_probe_() where the XX indicates which class of functions they're
for. "probe" is a better "term" than the previous check, since they really
only do minimal validation.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The overlay support has been introduced, but the copyright and license
header was missing. Make sure that this is no longer the case.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
overlay_update_local_node_references() saves the result of
fdt_subnode_offset() into variable tree_child but checks for variable
ret afterwards. As this does not make sense, check tree_child instead of
ret.
This bug has been found by compiling with clang. The compiler reported
the following warning:
libfdt/fdt_overlay.c:275:7: error: variable 'ret' may be
uninitialized when used here
[-Werror,-Wconditional-uninitialized]
if (ret == -FDT_ERR_NOTFOUND)
^~~
libfdt/fdt_overlay.c:210:9: note: initialize the variable 'ret' to
silence this
warning
int ret;
^
= 0
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This fixes a great many sparse warnings on the fdt and libfdt sources.
These are mostly due to incorrect mixing of endian annotated and native
integer types.
This includes fixing a couple of quasi-bugs where we had endian conversions
the wrong way around (this will have the right effect in practice, but is
certainly conceptually incorrect).
This doesn't make the whole tree sparse clean: there are many warnings in
bison and lex generated code, and there are a handful of other remaining
warnings that are (for now) more trouble than they're worth to fix (and
are not genuine bugs).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The fdt_overlay_apply() function purports to support the edge cases where
an overlay has no fixups to be applied, or a base tree which has no
symbols (the latter can only work if the former is also true). However it
gets it wrong in a couple of small ways:
* In the no fixups case, it doesn't fail immediately, but will attempt
fdt_for_each_property_offset() giving -FDT_ERR_NOTFOUND as the node
offset, which will fail. Instead it should succeed immediately, since
there's nothing to do.
* In the case of no symbols, it again doesn't fail immediately. However
if there is an actual fixup it will fail with an unexpected error,
because -FDT_ERR_NOTFOUND is passed to fdt_getprop() when attempting to
look up the symbols. We should instead return -FDT_ERR_NOTFOUND
directly.
Both of these errors lead to the code returning misleading error codes in
failing cases.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Some base device tree might not have any __symbols__ nodes, since they
might not have any phandle at all.
Similarly, if an overlay doesn't use any base device tree phandles, its
__fixups__ node will be empty.
In such cases, we don't want to stop the phandle parsing, but rather just
ignore the error reported about the missing node.
If it's actually an issue for the overlay we're trying to apply on a given
base device tree, it will be caught later on, but we cannot make the
assumption that early in the application process.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The __local_fixups__ node as a structure that mimics the structure of the
main overlay part.
This means that if we have a child node somewhere in the local fixups
sub-tree and if that node is not present in the main tree, the overlay is
poorly formatted, and we should report it as such.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Using 'index' as a local variable name shadows the standard library index()
function. This causes warnings on at least some compiler versions. The
recently added overlay code has a number of instances of this.
This patch replaces 'index' with 'poffset', since 'index' is being used to
mean "offset within a property value" in these cases.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The device tree overlays are a good way to deal with user-modifyable
boards or boards with some kind of an expansion mechanism where we can
easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
Add a new function to merge overlays with a base device tree.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Vikram Garhwal