public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Simon Glass <sjg@chromium.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Peter Robinson <pbrobinson@gmail.com>,
	Sughosh Ganu <sughosh.ganu@linaro.org>,
	u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Date: Fri, 8 Sep 2023 10:43:40 -0400	[thread overview]
Message-ID: <20230908144340.GF305624@bill-the-cat> (raw)
In-Reply-To: <CABb+yY0VJDu+L2C10E1O-uAU-p0OwuTq6XVF2XbYuOc2fBqoww@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

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@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2023-09-08 14:43 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26  9:06 [RFC PATCH 0/5] Allow for removal of DT nodes and properties Sughosh Ganu
2023-08-26  9:06 ` [RFC PATCH 1/5] dt: Provide a way to remove non-compliant " Sughosh Ganu
2023-08-26 10:22   ` Heinrich Schuchardt
2023-08-28  8:27     ` Sughosh Ganu
2023-08-26 10:39   ` Heinrich Schuchardt
2023-08-28  8:27     ` Sughosh Ganu
2023-08-28 18:08   ` Tom Rini
2023-08-26  9:06 ` [RFC PATCH 2/5] fwu: Add the fwu-mdata node for removal from devicetree Sughosh Ganu
2023-08-26  9:06 ` [RFC PATCH 3/5] capsule: Add the capsule-key property " Sughosh Ganu
2023-08-26  9:06 ` [RFC PATCH 4/5] bootefi: Call the EVT_FT_FIXUP event handler Sughosh Ganu
2023-08-26 10:27   ` Heinrich Schuchardt
2023-08-28  9:32     ` Sughosh Ganu
2023-08-28 10:57       ` Heinrich Schuchardt
2023-08-28 17:54         ` Simon Glass
2023-08-26  9:06 ` [RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal Sughosh Ganu
2023-08-26 10:01   ` Heinrich Schuchardt
2023-08-28 10:18     ` Sughosh Ganu
2023-08-28 17:54   ` Simon Glass
2023-08-28 18:34     ` Sughosh Ganu
2023-08-28 18:39       ` Tom Rini
2023-08-30  7:24         ` Ilias Apalodimas
2023-08-30 14:22           ` Tom Rini
2023-08-31  2:49           ` Simon Glass
2023-08-31  7:52             ` Ilias Apalodimas
2023-08-31 13:28               ` Tom Rini
2023-08-29 17:25       ` Simon Glass
2023-08-30  6:37         ` Sughosh Ganu
2023-08-26 10:07 ` [RFC PATCH 0/5] Allow for removal of DT nodes and properties Heinrich Schuchardt
2023-08-28  8:31   ` Sughosh Ganu
2023-08-28 16:19 ` Simon Glass
2023-08-28 16:37   ` Peter Robinson
2023-08-28 17:53     ` Tom Rini
2023-08-28 17:54     ` Simon Glass
2023-08-28 20:29       ` Peter Robinson
2023-08-28 22:09         ` Simon Glass
2023-08-29 10:33           ` Peter Robinson
2023-08-29 20:31             ` Simon Glass
2023-08-30  8:19               ` Peter Robinson
2023-08-31  3:38                 ` Simon Glass
2023-09-06 14:21           ` Rob Herring
2023-09-06 14:59             ` Simon Glass
2023-09-06 21:58             ` Tom Rini
2023-09-06 22:04             ` Tom Rini
2023-09-06 23:30               ` Heinrich Schuchardt
2023-09-07  1:59                 ` Tom Rini
2023-09-07  5:20             ` Ilias Apalodimas
2023-09-07 12:23               ` Simon Glass
2023-09-08 10:13                 ` Ilias Apalodimas
2023-09-08 14:54                   ` Tom Rini
2023-09-08 15:28                     ` Ilias Apalodimas
2023-09-11 19:06                       ` Tom Rini
2023-09-12  6:03                         ` Ilias Apalodimas
2023-09-08 14:37                 ` Jassi Brar
2023-09-08 14:43                   ` Tom Rini [this message]
2023-09-08 18:04                   ` Mark Kettenis
2023-09-13 22:39                     ` Rob Herring
2023-09-14 22:41                       ` Simon Glass
2023-09-14 23:38                         ` Tom Rini
2023-09-15  9:49                           ` Ilias Apalodimas
2023-09-18 17:00                         ` Rob Herring
2023-09-19 20:25                           ` Simon Glass
2023-09-19 21:38                             ` Tom Rini
2023-09-21 13:58                             ` Rob Herring
2023-09-21 17:43                               ` Simon Glass
2023-08-28 17:54   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230908144340.GF305624@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=pbrobinson@gmail.com \
    --cc=robh@kernel.org \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox