[PATCH 1/1] efi_loader: improve block device integration with DM

[Matwey V. Kornilov]

Can we just (temporarily) revert

f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot")

until this issue is resolved properly? Because, currently it seems
like the commit breaking the things was introduced at some point and
cannot be fixed within a reasonable amount of time since it seems that
the issue is related to the EFI implementation design.


сб, 26 июн. 2021 г. в 21:31, Simon Glass <sjg at chromium.org>:
>
> Hi Heinrich,
>
> On Thu, 17 Jun 2021 at 09:20, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >
> > Up to now when devices became available after executing the UEFI
> > sub-system initialization where not available for EFI applications.
> >
> > With the patch block devices are added to the UEFI object list whenever
> > they are probed.
> >
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > ---
> >  drivers/core/device.c               |  7 +++
> >  include/efi_loader.h                |  6 +++
> >  lib/efi_driver/Makefile             |  1 +
> >  lib/efi_driver/efi_dm_integration.c | 36 +++++++++++++++
> >  lib/efi_loader/efi_disk.c           | 72 +++++++++++++++++------------
> >  5 files changed, 93 insertions(+), 29 deletions(-)
> >  create mode 100644 lib/efi_driver/efi_dm_integration.c
> >
> > diff --git a/drivers/core/device.c b/drivers/core/device.c
> > index cb960f8ec4..7355a5c2a9 100644
> > --- a/drivers/core/device.c
> > +++ b/drivers/core/device.c
> > @@ -14,6 +14,7 @@
> >  #include <asm/global_data.h>
> >  #include <asm/io.h>
> >  #include <clk.h>
> > +#include <efi_loader.h>
> >  #include <fdtdec.h>
> >  #include <fdt_support.h>
> >  #include <malloc.h>
> > @@ -579,6 +580,12 @@ int device_probe(struct udevice *dev)
> >         if (dev->parent && device_get_uclass_id(dev) == UCLASS_PINCTRL)
> >                 pinctrl_select_state(dev, "default");
> >
> > +       if (CONFIG_IS_ENABLED(EFI_LOADER)) {
> > +               ret = efi_post_probe_device(dev);
> > +               if (ret)
> > +                       goto fail_uclass;
> > +       }
>
> Huge flashing NAK on this.
>
> Way back in the early days I mentioned that UEFI should not have its
> own tables but should use driver model directly. It was discussed but
> 'do it later' was the answer.
>
> To the extend that UEFI needs extra info to be tacked onto devices we
> should figure out a consistent way to do it.
>
> What I proposed 5-ish years ago is lots in the mists of time, but it
> is something like:
>
> - use driver model for *everything*
> - use struct udevice everywhere
> - avoid using parallel tables
> - things on the UEFI side then become dynamic rather than static
> - so there is no need for fixups
> - figure out what extra info is needed and come up with a generic way
> to attach it to devices
>
> So this is definitely not the right approach.
>
> Regards,
> Simon



-- 
With best regards,
Matwey V. Kornilov