Message-ID: <aS674_yXxYwJzHX9@shell.armlinux.org.uk>
Date: Tue, 2 Dec 2025 10:13:55 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Doug Anderson <dianders@...omium.org>
Cc: devicetree-spec@...r.kernel.org, boot-architecture@...ts.linaro.org,
	Chen-Yu Tsai <wenst@...omium.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>
Subject: Re: Proposal: Officially allow "incomplete" trees as a base

On Mon, Dec 01, 2025 at 12:58:57PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Mon, Dec 1, 2025 at 10:28 AM Russell King (Oracle)
> <linux@...linux.org.uk> wrote:
> >
> > On Mon, Dec 01, 2025 at 09:42:40AM -0800, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Nov 18, 2025 at 2:43 PM Doug Anderson <dianders@...omium.org> wrote:
> > > >
> > > > This is a continuation of the discussion that started in reply to my
> > > > patch adding basic device trees for Pixel 10 phones [1].
> > > >
> > > >
> > > > Problem statement:
> > > > ------------------
> > > >
> > > > We would like an officially accepted scheme that lets us more
> > > > efficiently ship compiled device trees for a handful of related
> > > > products by breaking the device trees up into a common "base" device
> > > > tree and then applying "overlay" device trees atop the base to make a
> > > > full and complete device tree.
> > > >
> > > > To make it more concrete, we'd like to build a "base" device tree that
> > > > describes a SoC and then have the overlays be enough to make a full
> > > > description of a board. In theory, one could also imagine wanting to
> > > > expand this to 3 or more levels (perhaps SoC, baseboard, derived
> > > > boards), though this is not planned at this time.
> > > >
> > > > The primary reason for wanting to break device trees like this is
> > > > efficiency of the shipped binary device trees. A large portion of a
> > > > final device tree just describes the SoC. We save space in the final
> > > > compiled device trees if they don't need to contain as much duplicated
> > > > information.
> > > >
> > > > A secondary reason for wanting to break device trees like this is to
> > > > more nicely handle when a board has a socketed SoC that can be
> > > > replaced with a finite (and small) number of different SoCs (usually
> > > > revisions of the same SoC). Even if this secondary reason is
> > > > considered invalid or too difficult, the primary reason still
> > > > describes a compelling need.
> > > >
> > > > In order to make this proposal work, it's expected that a bootloader
> > > > will understand the scheme and will know how to combine the overlay
> > > > atop the base before passing a complete device tree to the main OS.
> > >
> > > It's been roughly two weeks since I sent out this proposal. Do DT
> > > folks have any comments? Are the goals I have stated understood? Do
> > > people agree that these goals are reasonable? Is there any question
> > > that there is a need to solve these problems not just for Google, but
> > > for the community as a whole? I'm happy to reach out to people and
> > > have them reply "yes, I have this problem too" if it would somehow
> > > help. I don't doubt that there are still people at Qualcomm who would
> > > like a solution even if I think Elliot isn't driving it there
> > > anymore...
> > >
> > > How do we make forward progress? Does anyone have any comments on
> > > Julius's reply? At the moment, I think there are some conflicts with
> > > what Julius would like to see (no changes to the rules for how
> > > overlays are applied) and what Rob said previously (we need to find
> > > some way to combine the compatible strings). Did I misunderstand? Can
> > > we find a common ground?
> >
> > My feeling on this (and I don't have much time to consider it tonight)
> > is that this isn't going to get a quick answer.
> >
> > This answer is based on my authorship of various device trees, and is
> > solely my own opinion, and in no way represents any position by my
> > employer.
> >
> > While the DT files are dual-licensed, the license that applies to the
> > copy in the kernel is GPL v2, because the kernel as a whole is GPL v2
> > licensed. The dual-licensing of the DT files is to permit them to be
> > taken from the kernel and used in e.g. boot loaders etc.
> >
> > However, as the license that applies to the kernel copy is GPL v2, and
> > GPL v2 requires distribution in source code form, or an offer valid
> > for two years of the corresponding source code etc (check the GPL v2
> > for the exact terms) it could be inappropriate for the kernel tree
> > to distribute binary DT blobs without their corresponding source.
> >
> > It seems to me that this is a problem for lawyers, and you're probably
> > not going to get a quick answer on it.
> >
> > So, I'd suggest patience, and don't expect this topic to move quickly.
> 
> It seems like perhaps I wasn't clear enough in my description of the
> problem I'm trying to solve.

I didn't have time last night to properly read your proposal - certainly
not to go back to your original post, but from what I did read in your
follow up, it seemed that you were proposing that e.g. the SoC level
should be in binary form.

The confusion came from "build a "base" device tree" which implied to
me taking the e.g. SoC .dtsi and turning that into its binary form.

Sorry for misunderstanding.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists