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

[Simon Glass]

Hi Rob,

On Mon, 18 Sept 2023 at 11:00, Rob Herring <robh at kernel.org> wrote:
>
> On Thu, Sep 14, 2023 at 5:42 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Rob,
> >
> > On Wed, 13 Sept 2023 at 16:39, Rob Herring <robh at kernel.org> wrote:
> > >
> > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > > >
> > > > > 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.
> > >
> > > Yes. The exact title for 1275[1] is: IEEE Standard for Boot
> > > (Initialization Configuration)
> > > Firmware: Core Requirements and Practices
> > >
> > > I see "configuration" in there. However, in the OF case, it's
> > > generally how firmware configured the hardware and what it discovered.
> > > That's a little different than telling the OS how to configure the
> > > hardware which is what we do with FDT.
> >
> > For the /options node it says "The properties of this node are the
> > system’s configuration variables."
> >
> > Then there is section 7.4.4 which has a large list of options which
> > don't seem to be so narrowly defined.
> >
> > In any case, this is not quite the point, which IMO is that we need DT
> > to support firmware use cases, whether or not a 29-year-old spec
> > thought of it or not. In fact it is amazing to me how forward-looking
> > Open Firmware was.
> >
> > > Then there's stuff that's how
> > > to configure Linux which we try to reject.
> >
> > Fair enough: Linux has user-space for that.
>
> Yep, the question I usually ask is who needs to configure something
> and what determines the config. Changing things with sysfs is much
> easier than changing the DT provided by firmware.
>
> > >
> > > Once we get into configuration of the OS/client (including u-boot),
> > > making that an ABI is a lot harder and if we use DT for that, I don't
> > > think it should be an ABI.
> > >
> > > > > 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.
> > >
> > > There's not any restriction.
> > >
> > > My intention with dtschema schemas is to only have "spec level"
> > > schemas. (Stuff we'd add to DTSpec (but don't because no one wants to
> > > write specs).) Hardware specific stuff lives somewhere else. That
> > > happens to be the Linux tree because that is where all the h/w support
> > > is (nothing else is close (by far)). Last I checked, we've got ~3700
> > > schemas and ~1500 unconverted bindings.
> >
> > That scope is quite a bit narrower than I understood it to be. It
> > seems to leave a significant gap between the Linux repo and yours.
> >
> > >
> > > > 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.
> > >
> > > Until someone has some great idea to start using them. If the OS
> > > doesn't need something, then why pass it in the first place? What
> > > purpose does it serve? It's an invitation for someone somewhere to
> > > start using them.
> > >
> > > The downside of keeping the nodes is it creates an ABI where there
> > > doesn't need to be one necessarily.
> >
> > I'd love to get away from the idea that DT is just for the OS. We are
> > trying to use it for firmware-to-firmware communication, too. The
> > programs on each side of that interface may be different projects. For
> > that, we do need to have a binding, otherwise we end up with series
> > like this one.
>
> I don't think DT is just for the OS, but DT for the OS is an ABI and
> other cases may not be. Or they just don't need to follow all the same
> rules. Zephyr is doing their own thing for example.
>
> I don't think /options/u-boot is an ABI. AIUI, u-boot populates the
> node and consumes it. No ABI there (or limited to SPL to u-boot
> proper). I suppose a prior firmware stage could populate it, but that
> doesn't scale as then the prior stage has to know details of the next
> stage.

I still don't understand the distinction, or really why U-Boot (or
u-boot) is different. The main reason for the /options/u-boot node is
so that prior phase firmware can tell U-Boot what to do. It is similar
to the /chosen node for the OS. If it is not an ABI, how can any
project rely on it? It is absolutely not just U-Boot generating
something for its own consumption. Where is that idea even coming
from? We even have an OF_HAS_PRIOR_STAGE Kconfig option for it in
U-Boot, specifically for TF-A, etc.

As to the scaling, I agree. That suggests we try to make things
generic, i.e. have an /options node with these sorts of generic
settings. Candidates for that are console and logging controls, for
example. I would prefer that to /options/u-boot, as you know.

>
> > > > 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.
> > >
> > > I don't think we should decide what to do here based on said
> > > certification program. It can adapt to what's decided. Probably, the
> > > /option nodes will be stripped out or ignored for certification.
> > >
> > > I accepted u-boot options node schema into dtschema, but now have
> > > second thoughts on that. Now I'm getting more u-boot specific
> > > (perhaps, not clear) stuff and widevine stuff internal to a TEE.
> >
> > Where should these bindings go such that ARM / Linaro are not trying
> > to remove them? I would be OK with moving them out somewhere else, but
> > how are people supposed to deal with such fragmentation? My
> > understanding was that dt-schema was an attempt to set up a neutral
> > area where bindings could be accepted that were not just for
> > Linux...did that change?
>
> No change, just not communicated I guess. And again, bindings are not
> "just for Linux". They are hosted there because that is where *all*
> the hardware support is (by far). But we'll probably never get past
> the "Linux binding" perception no matter what we do or how many times
> I say it.
>
> To rephrase things a bit, I'm happy to host anything that's
> multi-project, not a large number of bindings, and not a
> device/hardware specific binding. The device specific bindings live in
> the kernel tree primarily. For any new binding (foos/#foo-cell type
> ones), I want to see multiple users. Really for these, probably best
> to start with them in Linux repo (or elsewhere) and then promote them
> to dtschema. That gives a little flexibility in changing/abandoning
> them.

So now I am not sure what you are suggesting. Are you wanting bindings
in many places (yours, Linux, U-Boot, TF-A, ...)? I am sure you are
aware that if we put bindings in U-Boot they will not be considered as
bindings at all, including by Linaro.

To restate the problem, we need (and until your previous email I
thought we had) a unified repo where cross-project, firmware-targeted
bindings can be accepted and agreed by interested projects.

>
> Removing nodes and/or properties and where things live are mostly
> independent discussions. SystemReady can adapt to whatever is decided
> for the former. In general, IMO, when passing DT from stage N to N+1,
> the N+1 stage should remove things which only apply to N+2 stage. For
> example, kexec removes /chosen and recreates it for the next kernel.

Sounds good. But note that the reason for that is a conflict, since
the node is used for different things - i.e. the two kernels need
different settings. That is quite different from the case I am talking
about, where the settings either apply globally (to interested
projects) or to a single project (for all boot phases of that
project). In my case, I believe there is no need to remove anything.

Regards,
Simon

PS Zephyr is absolutely doing its own thing. Apart from the fact that
it doesn't even have a runtime DT, the bindings are entirely within
the project. and bear little relation to Linux bindings. I was not
around for that decision, but I suspect part of the rationale was that
many of the MCUs which Zephyr targets are not supported by Linux. Of
course, that is not fully true and I believe it will become less true
with time. Then, perhaps, in 5 years it will be Zephyr's turn to think
about bindings more deeply.