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

[Tom Rini]

On Fri, Sep 08, 2023 at 09:37:12AM -0500, Jassi Brar wrote:
> 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."
> 
> 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's the same language-lawyering that's been going on since device trees
moved from the neat thing Apple-based PowerPC platforms provided (and
extended), and then got ad-hoc'd to support other PowerPC platforms, and
then was used to solve "Linus is sick of the patch conflicts on ARM"
problems.  And everyone is tired of talking about the exceptions to "it
must be hardware" because if your software isn't where the
software-burned-into-the-hardware wants it to be, the hardware won't
work and so on.

-- 
Tom

p.s. Yes, I know Apple didn't invent device trees either.
-------------- 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/20230908/10d0cc08/attachment.sig>