[PATCH v2 3/3] efi: Avoid using dm_scan_other()

[Tom Rini]

On Sat, Dec 16, 2023 at 09:57:41PM +0100, Heinrich Schuchardt wrote:
> On 12/16/23 21:46, Simon Glass wrote:
> > Hi,
> > 
> > On Tue, 21 Nov 2023 at 06:21, Tom Rini <trini at konsulko.com> wrote:
> > > 
> > > On Tue, Nov 21, 2023 at 01:18:09PM +0100, Heinrich Schuchardt wrote:
> > > > On 11/12/23 21:55, Simon Glass wrote:
> > > > > This function is defined by bootstd so using it precludes using that
> > > > > feature. Use the board_early_init_r() feature instead.
> > > > > 
> > > > > This requires moving quite a lot of code into the board directory, butt
> > > > > this is the normal place for code called by board_early_init_r()
> > > > > 
> > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > ---
> > > > > 
> > > > > Changes in v2:
> > > > > - Drop duplicate acpi_xsdt patch
> > > > > - Put the board_early_init_r code into board/
> > > > > 
> > > > >    board/efi/efi-x86_app/Makefile  |   5 +
> > > > >    board/efi/efi-x86_app/efi_app.c | 205 ++++++++++++++++++++++++++++++++
> > > > 
> > > > Our target should be to enable building the EFI app on all architectures.
> > > > 
> > > > Only x86 specific code should be added to board/efi/efi-x86_app/efi_app.c.
> > > 
> > > A later enhancement to make U-Boot as an EFI app more generic would be
> > > good, but outside the scope of this patch which is moving generic code
> > > out from "lib" and in to "board".
> 
> I cannot see that this patch is moving any code our of lib/.
> 
> But why should we move generic code into board?
> 
> > 
> > This patch was marked as old /archived in patchwork so has been
> > forgotten. I have marked it new and non-archived in the hope that it
> > can be applied to -master soon.
> 
> There is nothing x86 specific about the code. Generic code should be in
> lib/. Please, provide a new version of the patch.

It's not generic EFI code, it's generic "U-Boot as EFI application" code
and so the whole "board" needs a bit of a clean and re-work as we all
agree that there shouldn't be anything architecture specific about it,
only building the binary for the correct architecture. However, we just
aren't well structured to support that right now. Where on the list of
priorities does that have to fall rather than just allowing for
functionality to be tested / used? There's not yet IIRC efi-arm64_app
but what we have today (and would have had with Simon's patch) should
have just built and worked.

-- 
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/20231216/90dfc008/attachment.sig>