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 --]
next prev parent 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