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

[Peter Robinson]

On Tue, 17 Dec 2024 at 20:29, Tom Rini <trini at konsulko.com> wrote:

> On Tue, Dec 17, 2024 at 01:17:42PM -0700, Simon Glass wrote:
> > 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.
>
> Which is
>
> https://patchwork.ozlabs.org/project/uboot/cover/20241123195616.305687-1-mjg59@srcf.ucam.org/#3418939
> and an open question to explain the use case more.
>
> > > > 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?
>

It's the mainline, there are numerous other vendors that are contributing,
there's NXP, ST, TI, plus numerous other volunteer contributors such as
myself. The fact that Linaro is contributing a lot at the moment is
irrelevant. Contributors to projects wax and wane depending on their own
requirements.


> It's mainline. The tree at https://source.denx.de/u-boot/u-boot is the
> mainline tree for the Das U-Boot project, and I am the maintainer of
> that tree and the nominal head of the U-Boot project. If you want to
> ignore the feedback you have been given by other people to do whatever
> you like, please don't call it U-Boot. It is not "Linaro" disagreeing
> with your ideas, it's a number of people. It's most frequently myself
> (neither I nor my company get any money from Linaro, nor Arm Ltd),
> Heinrich (employed at Canonical, like you) or Ilias (yes, Linaro).
>

Simon, you are free to fork the project, it's one of the main glorious
features of open source software! I was wondering what you were up to when
you were replying with applied to messages for patches that were still
under review.

What it does not give you the right to do is to use the infrastructure,
such as this mailing list, patchwork, CI and what ever else, of the project
you're forking. You don't see the many hardware vendors that have forks of
the project, which they are well within their rights to do, using the
project infrastructure for their forks.

There is nothing OK about what you are doing. The community has the right
to know what you are doing purely because of the fact you are using the
project's infrastructure. If you're going to fork it you have no
requirements to notify if you go off and do it in your own area of the
internet.

Peter