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

[Simon Glass]

Hi Peter,

On Tue, 29 Aug 2023 at 04:33, Peter Robinson <pbrobinson at gmail.com> 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.
> > > >
> > > > I have started the process to upstream the binman bindings.
> > >
> > > I don't think they should be in DT at all, they don't describe
> > > anything to do with hardware, or generally even the runtime of a
> > > device, they don't even describe the boot/runtime state of the
> > > firmware, they describe build time, so I don't see what that has to do
> > > with device tree? Can you explain that? To me those sorts of things
> > > should live in a build time style config file.
> >
> > I beg to differ. Devicetree is more than just hardware and always has
> > been. See, for example the /chosen and /options nodes.
>
> Can you give me an example of "options" as grep doesn't give me a
> single one in the kernel tree? I think we can just agree to disagree
> here.

See here: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml

I don't mind disagreeing, so long as it doesn't result in any
restrictions on using devicetree in firmware. But it is very important
to the success of firmware that we can make full use of the
devicetree.

> > We need run-time configuration here, since we cannot know at build
> > time what we will be asked to do by a previous firmware phase.
>
> Can you provide an example as to how that is used during runtime? Do
> you mean runtime during the build process or runtime on the device?

I mean runtime on the device. An example is that we might want to
control whether the serial UART is enabled, without having to rebuild
each program in the firmware stack.

>
> > >
> > > > Perhaps we should use the issue tracker[1] to follow progress on all
> > > > of this. We need to clean it up.
> > > >
> > > > >
> > > > > > Instead of this, how about working on bringing the DT validation into
> > > > > > U-Boot so we can see what state things are in?
> > > > > >
> > > > > > Please send the bindings for Linaro's recent series (which I suspect
> > > > > > are motivating this series) so we can start the process.
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > [1] https://source.denx.de/u-boot/u-boot/-/issues
> >
> > Regards,
> > Simon

Regards,
Simon