Hi,
On Mon, Dec 1, 2025 at 7:31 PM Chen-Yu Tsai wenst@chromium.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?
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?
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?
-Doug