From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 3/9] efi_driver: add name to driver binding protocol
Date: Thu, 17 Jan 2019 14:33:16 +0900 [thread overview]
Message-ID: <20190117053314.GS20286@linaro.org> (raw)
In-Reply-To: <4cbb8730-9c02-7572-2852-b2c359371b29@gmx.de>
You raised a couple of questions to me.
On Tue, Jan 15, 2019 at 04:41:08AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > This new field will be shown as a driver's name in "efitool drivers"
> > command.
>
> We can have drivers supplied by U-Boot
I assume that what you mention here is a UCLASS_EFI driver.
What's the problem is;
efi_add_driver() adds EFI_DRIVER_BINDING_PROTOCOL with
*efi_driver_binding_extended_protocol* interface, which is NOT compatible
with EFI_DRIVER_BINDING_PROTOCOL.
On the other hand, for example, in your efi_selftest_controller test
a test driver is set up by installing EFI_DRIVER_BINDING_PROTOCOL
with EFI_DRIVER_BINDING_PROTOCOL interface.
So we have no way to distinguish the two cases(handles) and cannot
deal with them properly.
> and drivers supplied by an EFI
> binary that we recently installed via the bootefi command.
>
> A driver installed via the bootefi command will not have allocated
> memory for the extra fields.
There is no good example of driver of such kind.
I don't know how we can retrieve a meaningful "driver name."
> So you cannot use the name field in your "efitool drivers" command.
Any suggestion?
Thanks,
-Takahiro Akashi
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> > include/efi_driver.h | 1 +
> > lib/efi_driver/efi_uclass.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/efi_driver.h b/include/efi_driver.h
> > index 840483a416a4..ee8867816094 100644
> > --- a/include/efi_driver.h
> > +++ b/include/efi_driver.h
> > @@ -34,6 +34,7 @@ struct efi_driver_ops {
> > * This structure adds internal fields to the driver binding protocol.
> > */
> > struct efi_driver_binding_extended_protocol {
> > + const char *name;
> > struct efi_driver_binding_protocol bp;
> > const struct efi_driver_ops *ops;
> > };
> > diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
> > index bb86ffd399c3..8bbaa02d490e 100644
> > --- a/lib/efi_driver/efi_uclass.c
> > +++ b/lib/efi_driver/efi_uclass.c
> > @@ -271,6 +271,7 @@ static efi_status_t efi_add_driver(struct driver *drv)
> > bp->bp.stop = efi_uc_stop;
> > bp->bp.version = 0xffffffff;
> > bp->ops = drv->ops;
> > + bp->name = drv->name;
> >
> > ret = efi_create_handle(&bp->bp.driver_binding_handle);
> > if (ret != EFI_SUCCESS) {
> >
>
next prev parent reply other threads:[~2019-01-17 5:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 2:55 [U-Boot] [PATCH v4 0/9] cmd: add efitool for efi environment AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 1/9] cmd: add efitool command AKASHI Takahiro
2019-01-15 3:31 ` Heinrich Schuchardt
2019-01-17 4:27 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 2/9] cmd: efitool: add devices command AKASHI Takahiro
2019-01-15 5:09 ` Heinrich Schuchardt
2019-01-17 4:48 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 3/9] efi_driver: add name to driver binding protocol AKASHI Takahiro
2019-01-15 3:41 ` Heinrich Schuchardt
2019-01-17 5:33 ` AKASHI Takahiro [this message]
2019-01-17 6:58 ` Heinrich Schuchardt
2019-01-21 7:47 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 4/9] cmd: efitool: add drivers command AKASHI Takahiro
2019-01-15 3:39 ` Heinrich Schuchardt
2019-01-15 2:55 ` [U-Boot] [PATCH v4 5/9] cmd: efitool: add dh command AKASHI Takahiro
2019-01-15 4:55 ` Heinrich Schuchardt
2019-01-17 6:01 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 6/9] cmd: efitool: add images command AKASHI Takahiro
2019-01-15 4:58 ` Heinrich Schuchardt
2019-01-17 6:02 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 7/9] cmd: efitool: add memmap command AKASHI Takahiro
2019-01-15 4:26 ` Heinrich Schuchardt
2019-01-17 7:03 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 8/9] cmd: efitool: export uefi variable helper functions AKASHI Takahiro
2019-01-15 5:28 ` Heinrich Schuchardt
2019-01-17 7:30 ` AKASHI Takahiro
2019-01-15 2:55 ` [U-Boot] [PATCH v4 9/9] cmd: env: add "-e" option for handling UEFI variables AKASHI Takahiro
2019-01-15 3:47 ` Heinrich Schuchardt
2019-01-15 13:23 ` Alexander Graf
2019-01-15 13:26 ` Alexander Graf
2019-01-15 9:16 ` [U-Boot] [PATCH v4 0/9] cmd: add efitool for efi environment Alexander Graf
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=20190117053314.GS20286@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.