[PATCH 1/3] efi: Correct logic for OF_EMBED and OF_SEPARATE co-existing

Simon Glass sjg at chromium.org
Tue Dec 17 21:17:42 CET 2024


Hi Tom,

On Tue, 17 Dec 2024 at 12:57, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Dec 17, 2024 at 12:46:17PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 17 Dec 2024 at 07:25, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Dec 17, 2024 at 08:00:56AM -0600, Simon Glass wrote:
> > >
> > > > While we do plan to switch to OF_SEPARATE now it is supported, it seems
> > > > worth at least showing how OF_EMBED could be used instead, just for the
> > > > record.
> > > >
> > > > So make the Makefile rule conditional on OF_SEPARATE and adjust fdtdec
> > > > to avoid a build error when OF_EMBED is used.
> > > >
> > > > Finally. the dtb symbol has a double underscore, so update it to avoid a
> > > > build warning.
> > > >
> > > > With future patches, OF_EMBED will no-longer be used with the EFI app,
> > > > so it is expected that it will eventually stop working.
> > > >
> > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > Fixes: 2e7bf25f6bf ("Support separate DTB files with the UEFI app")
> > > > ---
> > > >
> > > >  Makefile                       | 2 +-
> > > >  include/asm-generic/sections.h | 2 +-
> > > >  lib/fdtdec.c                   | 2 +-
> > > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > Applied to sjg/master, thanks!
> > >
> > > Since you've picked up several series that no one was objecting to and
> > > providing reasonable feedback on and applied them to your own tree, do
> > > you plan to squash/rebase them and repost so they can be applied to
> > > master / next at some point?
> >
> > The original EFI-app series actually had objections in toto. Did you
> > not see the comments from Heinrich?
>
> I assume you mean:
> https://patchwork.ozlabs.org/project/uboot/patch/20241123195616.305687-2-mjg59@srcf.ucam.org/#3419029
> which is a question.

Apart from the general tone, it was mostly the cover letter.

>
> > I've offered to send pull requests every now and then, to keep things
> > in sync, if that is your goal? But I don't believe I can do that for
> > particular patches/series. It is going to be hard enough for me to
> > just maintain my own tree, let along dealing with your/Linaro tree.
>
> I find you calling the mainline project tree "your/Linaro tree"
> offensive. And I'm again asking you to explain in public what you are
> doing exactly.

I'm sorry you are offended. Please suggest a better name that I can
use. Honestly, from my point of view, it feels like a
Linaro-controlled tree. There's nothing particularly wrong with that,
but I would like the freedom to continue to innovate U-Boot, without
Linaro telling me what to do. Does that sound OK to you?

Regards,
Simon


More information about the U-Boot mailing list