Hi,
On Mon, Dec 1, 2025 at 5:07 PM Rob Herring robh@kernel.org wrote:
I would be interested in some experiments around making this change with existing DTs. Take a board DT and add the overlay boilerplate (that may be nothing more than add '/plugin/') and remove the SoC include. Does that apply to a compiled SoC DTB and is the result the same as before?
Think of it as moving from building C code using a #include of every .c file to build a single .o to linking multiple individual .o files. No one would argue the former is better.
I suspect it would work some of the time, but it wouldn't be guaranteed. In the very least, the base SoC "dtb" would fail to validate because it would be missing a documented top-level compatible. :-P ...but if we ignore that, I'd imagine these things could break:
1. If a SoC is relying on a "label" that's provided by the boards, it could break.
2. If any of the boards "delete" things from the SoC, it could break.
3. Board files could have been relying on the "bindings" #includes in the base SoC file.
I guess the first two things are much more common between all of the "dtsi" files included to make up a board than they are between the main SoC "dtsi" file and the others, and the third one is "easily" fixed.
OK, so I did a quick experiment and quickly found an example of #2. Take a look at "sc7180-acer-aspire1.dts" and you'll find:
/delete-node/ &tz_mem; /delete-node/ &ipa_fw_mem;
Those delete nodes from the SoC tree.
I also found an example of #3. sc7180-trogdor.dtsi refers to "GCC_MSS_CFG_AHB_CLK", but it doesn't include "dt-bindings/clock/qcom,gcc-sc7180.h".
All of the above could be fixed, but it stops being a "quick" experiment. ;-) Essentially, if people weren't trying to follow the rules of the overlay-to-base boundary it's likely they've crossed them, as in the above case. :-P
If continuing the above experiment would help convince someone, I could certainly continue it. I guess I just don't have too much of a doubt that it could be made to work OK. I think it would be _less_ efficient overall to ship full DTBs generated like that because we'll have compiled the base device tree with "-@". The only way to become more efficient would be to actually ship the base DTB + overlays.
-Doug