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

[Tom Rini]

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 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).

While I am open to, and am exploring how to formally change the project
from the old fashioned "Benevolent Dictator For Life" model to something
that reflects modern project management, Wolfgang passed the project hat
down to me a long time ago. If you don't like my leadership, moving past
the BDFL model and to something else will give you a chance to take the
reigns, so to speak.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241217/3c9690db/attachment.sig>