Message-ID: <CAGXv+5HU2y-8AZhXDjneaTdD1yr2h06OXbkozcQJj2mBcR1HmQ@mail.gmail.com>
Date: Wed, 3 Dec 2025 15:34:25 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Linus Walleij <linusw@...nel.org>, devicetree-spec@...r.kernel.org, 
	boot-architecture@...ts.linaro.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>, 
	Simon Glass <sjg@...omium.org>, Yu-Ping Wu <yupingso@...omium.org>
Subject: Re: Proposal: Officially allow "incomplete" trees as a base

On Wed, Dec 3, 2025 at 6:11 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Mon, Dec 1, 2025 at 7:31 PM Chen-Yu Tsai <wenst@...omium.org> wrote:
> >
> > > Separately, it can be noted that we always _wanted_ a similar solution
> > > for ChromeOS, but we never quite got there... ;-)
> >
> > FTR ChromeOS is moving in that direction: splitting SKU differences
> > based on components into overlays that get applied to the base by the
> > bootloader.
> >
> > In the simplest example we could have one base dts and two overlays
> > for two different DSI panel models:
> >
> >   - base.dtb
> >     - panel-model-a.dtbo
> >     - panel-model-b.dtbo
> >
> > The problem we then run into is that the base.dtb will only have the
> > generic model compatible "google,foo", not the sku and revision
> > specific ones like "google,foo-sku1-rev2".
> >
> > And we'd really like to avoid having _more_ overlays just to add the
> > final specific compatible string, as that kind of defeats the purpose
> > of using overlays to reduce the number of dts files.
>
> I think you may have simplified the above a little too much to the
> point where it's confusing. At least I'm a bit confused. I _think_ the
> problems you're talking about are the kinds of things we run into when
> we take overlays above just two levels. I'm imagining:
>
> - base.dtb
> - board1-rev1.dtbo
> - board2-rev1.dtbo
> - board1-rev2.dtbo
> - board2-rev2.dtbo
> - panel-a.dtbo
> - panel-b.dtbo
>
> So I think you're saying that you'd start with the "base.dtb" and then
> extend it with exactly one of the "board" overlays and then exactly
> one of the "panel" overlays. Is that right?

For now I think we just experiment with having one end "model" or
"product" as the base.dtb. The panel-*.dtbo selected describe the
optional components, while the board-rev??.dtbo just provides the
top level compatible and model.

In an example that I plan to send out this week, I would rework:

  - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri.dtsi
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku0.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku1.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku2.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku3.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku4.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku5.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku6.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku7.dts

into:

  - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri.dts
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-max98390-es8326.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-max98390-rt5682s.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-tas2563-es8326.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-tas2563-rt5682s.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-panel-boe.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-panel-ivo.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku0.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku1.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku2.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku3.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku4.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku5.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku6.dtso
    - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku7.dtso

The "mt8188-geralt-ciri-sku?.dtso" files only contain the following
boilerplate:

    /dts-v1/;
    /plugin/;

    &{/} {
        model = "Google Ciri sku? board (rev4)";
        compatible = "google,ciri-sku?", "google,ciri", "mediatek,mt8188";
    };

The base "mt8188-geralt-ciri.dts" would already have a generic board-
specific compatible:

    model = "Google Ciri board";
    compatible = "google,ciri", "mediatek,mt8188";

> So I'd imagine that each of the "board" overlays could have "full"
> compatible strings. For instance, I'd imagine "board2-rev2" could
> have:
>
> compatible = "google,booard2-rev2", "socVendor,soc"
>
>
> The problem you're struggling with (I think) is that the panel
> overlays won't be represented in the compatible string (and "model")
> even though (historically) we always did in ChromeOS (they were
> included in the "sku" part of the compatible string).
>
> Did I get that right?

In a sense you've generalized the problem I was describing.

In my example, the top level compatible gets fixed up by the final
SKU-specific overlay. But that's 8 extra files to do one bit of
fixup that supposedly the bootloader could be taught to do, and
could do even better. The bootloader knows exactly which SKU and
revision it's running on and can insert the information appropriately.
We could get rid of those awkwardly long compatible string sequences:

  compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146",
               "google,tentacruel-sku262145", "google,tentacruel-sku262144",
               "google,tentacruel", "mediatek,mt8186";

Going back to what I think you're describing, is that instead of one
base board DTB for each product, we could have one base DTB for the
reference design (in place of the .dtsi file we currently have), and
make products and component selection all use overlays.

If we do that, then inserting the correct top level compatible and model
becomes more important, since we do have things such as the ChromeOS OF
component prober working based on top level compatible. Also, the model
is present in logs, and would be very misleading to say one device name
while in reality it is a different one.

> > I proposed internally maybe having the bootloader fix up the final
> > compatible string, but I think we need some rough consensus upstream
> > whether this is acceptable or not.
>
> Maybe we need to come to some agreement about when the top-level
> compatible string needs to be changed. In the above, I'd perhaps argue
> that the panel isn't a major enough change that it needs to change the
> top-level compatible string. That would solve the problem, right? What
> do others think? Certainly for "probe-able" components we don't change
> the top-level compatible string. Can anyone point to any official
> documentation about the top-level compatible string?

I'd certainly like more documentation as well.


ChenYu

Powered by blists - more mailing lists