[RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Mark Kettenis]

> From: Jassi Brar <jassisinghbrar at gmail.com>
> Date: Fri, 8 Sep 2023 09:37:12 -0500
> 
> Hi Simon,
> 
> On Thu, Sep 7, 2023 at 3:08 PM Simon Glass <sjg at chromium.org> wrote:
> > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas
> > >
> > > > > I beg to differ. Devicetree is more than just hardware and always has
> > > > > been. See, for example the /chosen and /options nodes.
> > > >
> > > > There are exceptions...
> > > >
> > >
> > > We've been this over and over again and frankly it gets a bit annoying.
> > > It's called *DEVICE* tree for a reason.  As Rob pointed out there are
> > > exceptions, but those made a lot of sense.  Having arbitrary internal ABI
> > > stuff of various projects in the schema just defeats the definition of a
> > > spec.
> >
> > Our efforts should not just be about internal ABI, but working to
> > provide a consistent configuration system for all firmware elements.
> >
> Sure, programmatically we can pass any data/info via DT, however it is
> only meant to map hardware features onto data structures.
> 
> devicetree.org  landing page
>     "The devicetree is a data structure for describing hardware."
> 
> devicetree-specification-v0.3.pdf  Chapter-2 Line-1
>    "DTSpec specifies a construct called a devicetree to describe
> system hardware."

But it doesn't say that it describes *only* hardware.  And it does
describe more than just hardware.  There is /chosen to specify
firmware configuration and there are several examples of device tree
bindings that describe non-discoverable firmware interfaces in the
Linux tree.  And it has been that way since the days of IEEE 1275.
There are also bindings describing things like the firmware partition
layout.

> If we want to digress from the spec, we need the majority of
> developers to switch sides :)  which is unlikely to happen and rightly
> so, imho.

It isn't even clear what the spec is.  There is the document you
reference above, there are the yaml files at
https://github.com/devicetree-org/dt-schema and then there are
additional yaml files in the Linux tree.  As far as I know it isn't
written down anywhere that those are the only places where device tree
bindings can live.

Anyway, let's face it, there is some consensus among developers that
what Simon has done in U-Boot is pushing the use of devicetree beyond
the point where a significant fraction of developers thinks it makes
sense.  And I think I agree with that.  But you can't beat him with
the spec to make your point.

Now the devicetree is cleverly constructed such that it is possible to
define additional bindings without the risk of conflicting with
bindings developed by other parties.  In particular if U-Boot is
augmenting a device tree with properties that are prefixed with
"u-boot," this isn't going to hurt an operating system that uses such
an augmented device tree.

The real problem is that some folks developed a certification program
that allegedly requires schema verification and now propose adding
code to U-Boot that doesn't really solve any problem.  My proposed
solution would be to change said certification program to allow
firmware to augment the device tree with properties and nodes with
compatibles that are in the namespace controlled by the firmware.

Cheers,

Mark