Re: Proposal: Officially allow "incomplete" trees as a base

Doug Anderson
2025-11-19T00:46:17Z

Hi,

On Tue, Nov 18, 2025 at 3:48 PM Julius Werner <jwerner@chromium.org> wrote:
>
> > 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'm certainly not dead-set on it and I definitely realize it would be
a pain. ...though it wouldn't necessarily "break" the format--you just
wouldn't be able to use any "incomplete" DTBs unless you implemented
this new feature.

From my point of view, the main issue the merging solves is handling
"socketed" boards that could have any of a small number of SoCs
plugged into them (usually minor revs of the same SoC). It's not the
absolutely most critical use case in the world, but I know that we
will need it in-house and I'm trying to come up with a solution that
will work everywhere. Once we decide to go with a downstream solution
just for that one use case then there's no reason not to do everything
else in a downstream manner.

Personally, I've never really loved that the SoC compatible strings
are conventionally just jammed onto the end of the top-level
compatible and I'm totally happy with it being elsewhere (a different
property, a different node, etc). Mostly I ended up with this merging
scheme because I thought that was what DT folks were pushing for. If
I'm wrong then I'm more than happy with a different scheme.

> 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.

Yes, I totally agree and this is an important conversation to have
too. I still like the "/loaders" proposal but I'm not dead-set on it.

That being said, the two problems are separate even if they're related
to each other. I was attempting to focus on allowing the base DTBs to
land first and once we get agreement then move onto the second. I'll
also note that Chen-Yu is talking about the problem at Linux Plumbers.
I won't be there, but I'm going to try to attend that session
remotely.

-Doug