Message-ID: <CAD=FV=U54Uwny=kHY+VjG5DGCSHeRUCcWMG=hG88ov8hC6Ynew@mail.gmail.com>
Date: Wed, 3 Dec 2025 08:25:01 -0800
From: Doug Anderson <dianders@...omium.org>
To: Chen-Yu Tsai <wenst@...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

Hi,

On Tue, Dec 2, 2025 at 11:34 PM Chen-Yu Tsai <wenst@...omium.org> wrote:
>
> On Wed, Dec 3, 2025 at 6:11 AM Doug Anderson <dianders@...omium.org> wrote:
> >
> > > 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 wasn't saying that you'd just have the same "compatible" for every
derivative of a reference board. That seems over the top. I was
thinking that you'd even have a unique "compatible" for each revision
of each board instance. I'm simply suggesting that you don't need a
per-SKU "compatible". Those don't add any real benefit, do they?

In your Ciri example above, you could get rid of all of the "sku"
overlay files since you've said that all they're doing is updating the
"compatible". Since (I think) you're only trying to support "rev4"
based on your model string, that would leave you just one file for
Ciri. If you had more than one revision then you'd have more than one,
but it doesn't need to be multiplied by the SKUs, right?

-Doug

Powered by blists - more mailing lists