From: Simon Glass <sjg@chromium.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Alexander Graf <agraf@csgraf.de>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
"Matwey V . Kornilov" <matwey.kornilov@gmail.com>,
Michael Walle <michael@walle.cc>
Subject: Re: [PATCH 1/1] efi_loader: improve block device integration with DM
Date: Sat, 26 Jun 2021 12:31:43 -0600 [thread overview]
Message-ID: <CAPnjgZ2ABYGQEL_e5GsvCJzgN3UswMZbb5j2nuYZ1p0nEuccww@mail.gmail.com> (raw)
In-Reply-To: <20210617151532.10350-1-xypron.glpk@gmx.de>
Hi Heinrich,
On Thu, 17 Jun 2021 at 09:20, Heinrich Schuchardt <xypron.glpk@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@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
next prev parent reply other threads:[~2021-06-26 18:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 15:15 [PATCH 1/1] efi_loader: improve block device integration with DM Heinrich Schuchardt
2021-06-18 7:24 ` Matwey V. Kornilov
2021-06-26 18:31 ` Simon Glass [this message]
2021-07-07 7:45 ` Matwey V. Kornilov
2021-07-07 7:58 ` Michael Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPnjgZ2ABYGQEL_e5GsvCJzgN3UswMZbb5j2nuYZ1p0nEuccww@mail.gmail.com \
--to=sjg@chromium.org \
--cc=agraf@csgraf.de \
--cc=matwey.kornilov@gmail.com \
--cc=michael@walle.cc \
--cc=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).