Hi Heinrich,
On Thu, 17 Jun 2021 at 09:20, Heinrich Schuchardt <xypron.g...@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.g...@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
