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

Tue Sep 19 23:38:40 CEST 2023

On Tue, Sep 19, 2023 at 02:25:49PM -0600, Simon Glass wrote:
> 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.

Well, maybe we aren't different, we just need to figure out for
ourselves what is useful to have in DT, and what isn't because no one
else will use it and it's not the best mechanism for our use either.  Or
there might be cases where it is useful to us to do it that way and we
just delete that part of the tree prior to passing on to the OS.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230919/250d72f7/attachment.sig>