If the overlay's target is only created in a previous fragment, it
doesn't exist in the unmodified base device tree. For the phandle
overwrite check this can be ignored because in this case the base tree
doesn't contain a phandle that could be overwritten.
Adapt the corresponding check to not error out if that happens but just
continue with the next fragment.
This is currently triggered by
arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso in the kernel
repository which creates /panel in its first fragment and modifies it in
its second.
Reported-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/all/CAL_JsqL9MPycDjqQfPNAuGfC6EMrdzUivr+fuOS7YgU3biGd4A@mail.gmail.com/
Fixes: 1fad065080 ("libfdt: overlay: ensure that existing phandles are not overwritten")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Message-ID: <20240626075551.2493048-2-u.kleine-koenig@baylibre.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We've recently added "syntactic sugar" support to generate runtime dtb
overlays using similar syntax to the compile time overlays we've had for
a while. This worked with the &label { ... } syntax, adjusting an existing
labelled node, but would fail with the &{/path} { ... } syntax attempting
to adjust an existing node referenced by its path.
The previous code would always try to use the "target" property in the
output overlay, which needs to be fixed up, and __fixups__ can only encode
symbols, not paths, so the result could never work properly.
This adds support for the &{/path} syntax for overlays, translating it into
the "target-path" encoding in the output. It also changes existing
behaviour a little because we now unconditionally one fragment for each
overlay section in the source. Previously we would only create a fragment
if we couldn't locally resolve the node referenced. We need this for
path references, because the path is supposed to be referencing something
in the (not yet known) base tree, rather than the overlay tree we are
working with now. In particular one useful case for path based overlays
is using &{/} - but the constructed overlay tree will always have a root
node, meaning that without the change that would attempt to resolve the
fragment locally, which is not what we want.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
So far, the tests for generating runtime overlays with dtc weren't checking
the syntactic sugar. This adds such a test.
Furthermore the existing tests were only minimally testing dtc's output
for the overlay. This adds a test comparing the dtc output with the
more or less manually constructed overlays we already have for testing
libfdt's overlay application code. This does require some minor changes
to that manually constructed overlay which don't change the sematics but
re-order / rename things to match the way dtc does it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This changes the names of the testfiles for a number of the testcases of
the dtc overlay generation functionality to make them shorter and a bit
cleaerer what's going on. In addition we move some of the check_path
sanity checks closer to the dtc commands they verify.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add a number of tests for dynamic objects/overlays.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add some test infrastructure to test that the overlay can be merged, but
also that poorly formatted fixups would fail as expected.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[dwg: Don't execute bad overlay tests without overlay aware dtc]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Uwe Kleine-König