public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Peter Robinson <pbrobinson@gmail.com>
Cc: Simon Glass <sjg@chromium.org>,
	Sughosh Ganu <sughosh.ganu@linaro.org>,
	u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Date: Mon, 28 Aug 2023 13:53:16 -0400	[thread overview]
Message-ID: <20230828175316.GI3953269@bill-the-cat> (raw)
In-Reply-To: <CALeDE9MMiA9HVfbeOV3tGqfAAC9oYf9qvizBW0T=hLmqcYD=qw@mail.gmail.com>

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

On Mon, Aug 28, 2023 at 05:37:45PM +0100, Peter Robinson wrote:
> On Mon, Aug 28, 2023 at 5:20 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi,
> >
> > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu <sughosh.ganu@linaro.org> wrote:
> > >
> > >
> > > Provide a way for removing certain devicetree nodes and/or properties
> > > from the devicetree. This is needed to purge certain nodes and
> > > properties which may be relevant only in U-Boot. Such nodes and
> > > properties are then removed from the devicetree before it is passed to
> > > the kernel. This ensures that the devicetree passed to the OS does not
> > > contain any non-compliant nodes and properties.
> > >
> > > The removal of the nodes and properties is being done through an
> > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be
> > > behind any Kconfig symbol.
> > >
> > > I have only build tested this on sandbox, and tested on qemu arm64
> > > virt platform. This being a RFC, I have not put this through a CI run.
> > >
> > > Sughosh Ganu (5):
> > >   dt: Provide a way to remove non-compliant nodes and properties
> > >   fwu: Add the fwu-mdata node for removal from devicetree
> > >   capsule: Add the capsule-key property for removal from devicetree
> > >   bootefi: Call the EVT_FT_FIXUP event handler
> > >   doc: Add a document for non-compliant DT node/property removal
> > >
> > >  cmd/bootefi.c                                 | 18 +++++
> > >  .../devicetree/dt_non_compliant_purge.rst     | 64 ++++++++++++++++
> > >  drivers/fwu-mdata/fwu-mdata-uclass.c          |  5 ++
> > >  include/dt-structs.h                          | 11 +++
> > >  lib/Makefile                                  |  1 +
> > >  lib/dt_purge.c                                | 73 +++++++++++++++++++
> > >  lib/efi_loader/efi_capsule.c                  |  7 ++
> > >  7 files changed, 179 insertions(+)
> > >  create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst
> > >  create mode 100644 lib/dt_purge.c
> >
> > What is the point of removing them? Instead, we should make sure that
> > we upstream the bindings and encourage SoC vendors to sync them. If we
> > remove them, no one will bother and U-Boot just becomes a dumping
> > ground.
> 
> Well things like the binman entries in DT are U-Boot specific and not
> useful for HW related descriptions or for Linux or another OS being
> able to deal with HW so arguably we're already a dumping ground to
> some degree for not defining hardware.

It's about validation and Simon is literally in the process of having
the binman bindings upstreamed.

-- 
Tom

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

  reply	other threads:[~2023-08-28 17:53 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 [this message]
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
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=20230828175316.GI3953269@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=pbrobinson@gmail.com \
    --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