linux-kernel - Re: Proposal: Officially allow "incomplete" trees as a base

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAODwPW_51fKOfDQbTUFCum13M621Uxi2Zw2YHng0DrrwwvZhRQ@mail.gmail.com>
Date: Tue, 18 Nov 2025 15:48:32 -0800
From: Julius Werner <jwerner@...omium.org>
To: Doug Anderson <dianders@...omium.org>
Cc: devicetree-spec@...r.kernel.org, boot-architecture@...ts.linaro.org, 
	Chen-Yu Tsai <wenst@...omium.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk@...nel.org>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux ARM <linux-arm-kernel@...ts.infradead.org>, 
	William McVicker <willmcvicker@...gle.com>, Julius Werner <jwerner@...omium.org>, 
	Conor Dooley <conor+dt@...nel.org>, Peter Griffin <peter.griffin@...aro.org>, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, André Draszik <andre.draszik@...aro.org>, 
	yupingso@...omium.org
Subject: Re: Proposal: Officially allow "incomplete" trees as a base

> 4. When applying an overlay to a device tree that's "incomplete", the
> top level overlay will be merged instead of replaced.
>
> Example for 2 levels:
>
> base (incomplete) compatible: "socvendor,mysoc-rev1", "socvendor,mysoc";
> overlay compatible: "boardvendor,myboard-rev1", "boardvendor,myboard";
> merged compatible: "boardvendor,myboard-rev1", "boardvendor,myboard",
>                    "socvendor,mysoc-rev1", "socvendor,mysoc";
>
> Possible example if we support 3 levels:
>
> SoC (incomplete) compatible: "socvendor,mysoc-rev1", "socvendor,mysoc"
> overlay1 (incomplete) compatible: "referencevendor,referencecodename";
> overlay2 compatible: "boardvendor,myboard-rev1", "boardvendor,myboard"
> merged compatible: "boardvendor,myboard-rev1", "boardvendor,myboard",
>                    "referencevendor,reference-codename",
>                     , "socvendor,mysoc";

Sorry, I only cursorily followed the previous discussion so I may have
missed the exact need for this part. But I would caution against any
proposal that changes the basic rules of how an overlay is applied.
The definition of how overlays work has (I think?) been stable for
over a decade now, and is implemented in bootloaders that often cannot
easily be updated. I absolutely support your effort to get more
upstream standardization for managing base device trees and overlays
(which I think need to be flexible for arbitrary layers, not just SoC
and board), but let's not break the overlay code in old bootloaders
while doing it.

Is there really a need to merge the compatible strings in your case? I
think in the vast majority of platform identification cases, code only
cares about matching the most precise string (i.e.
"boardvendor,myboard-rev1"). If we do feel like having the whole chain
of identification is necessary, it could be achieved by just
copy&pasting the extra strings into the overlay file. If we have
cross-validation between base and overlay source files we could also
have the validation check that the overlays correctly contain all
compatible strings from their base tree. If we know that the base
trees aren't standalone anyway, we could also just invent other
property names that identify them (e.g. `soc-compatible =
"socvendor,mysoc";`). Anything other than breaking the overlay format
would be preferable in my opinion.

I also feel like we need a better standardized way to tie base device
trees to overlays, like your `/loaders` node proposal in an earlier
email, although maybe that's an orthogonal discussion (but related,
especially if there's supposed to be cross-validation between base
trees and overlays). The compatible string is just not a scalable way
for bootloaders to make this determination, there may be a lot more
differentiation than just "SoC" and "board", and the scheme almost
certainly needs to be platform/bootloader-specific because every
hardware vendor has their own ideas about how to group and reuse parts
of a platform. This information doesn't necessarily need to be *in*
the device tree, it could also just be in a separate YAML file in the
same repo (since bootloaders will almost certainly want to have it
transformed into their own out-of-band descriptor at build-time
anyway, so that they can compress the device tree itself and don't
have to decompress each one for matching), but it needs to be
somewhere.