From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>, u-boot@lists.denx.de
Subject: Re: [PATCH 1/1] efi_loader: CloseProtocol in efi_fmp_find
Date: Tue, 11 Oct 2022 16:35:41 +0900 [thread overview]
Message-ID: <20221011073541.GB39168@laputa> (raw)
In-Reply-To: <7d7b2d2d-ef72-7e42-c503-78cabc967f49@canonical.com>
On Tue, Oct 11, 2022 at 07:58:11AM +0200, Heinrich Schuchardt wrote:
>
>
> On 10/11/22 02:49, AKASHI Takahiro wrote:
> > The commit message is not accurate.
> >
> > On Fri, Oct 07, 2022 at 04:06:23PM +0200, Heinrich Schuchardt wrote:
> > > The CloseProtocol() boot service requires a handle as first argument.
> > > Passing the protocol interface is incorrect.
> >
> > Correct, but
> >
> > > CloseProtocol() only has an effect if called with a non-zero value for
> > > agent_handle. HandleProtocol() uses an opaque agent_handle when invoking
> > > OpenProtocol() (currently NULL).
> >
> > No. OpenProtocol() is called with efi_root as an agent handle.
> > So, calling CloseProtocol() is a right thing at the end.
>
> Typically an agent handle is used to relate to a driver exposing the driver
> binding protocol.
Why can't we, other than a driver, call HandleProtocol()
as a convenient way of accessing an interface?
> The root node does not expose the driver binding protocol.
So do you mean the current implementation of HandleProtocol() is wrong?
> Why would you want to create an open protocol information entry here?
To access get_image_info() quickly.
> Do you think anything with the code after the patch is wrong?
No reason to replace handle_protocol().
Another example is here:
efi_load_image_from_path()
efi_handle_protocol(device, guid, (void **)&load_file_protocol));
...
efi_close_protocol(device, guid, efi_root, NULL);
I believe that this function is anything but a driver.
I think using HandleProtocol() (or preferably OpenProtocol()) and CloseProtocol()
in pair seems totally sane.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >
> > > Therefore HandleProtocol() should be
> > > avoided.
> > >
> > > * Replace the LocateHandle() call by efi_search_protocol().
> >
> > LocateHandle() -> efi_handle_protocol()
> >
> > So you could have fixed this way:
> > EFI_CALL(efi_close_protocol(handle, ..., &efi_root, NULL);
> >
> > I preferred to use EFI_CALL() over this file as you can see.
> >
> > -Takahiro Akashi
> >
> > > * Remove the CloseProtocol() call.
> > >
> > > Fixes: 8d99026f0697 ("efi_loader: capsule: support firmware update")
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > ---
> > > lib/efi_loader/efi_capsule.c | 14 ++++++--------
> > > 1 file changed, 6 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > index b6bd2d6af8..397e393a18 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -159,12 +159,14 @@ efi_fmp_find(efi_guid_t *image_type, u8 image_index, u64 instance,
> > > efi_status_t ret;
> > > for (i = 0, handle = handles; i < no_handles; i++, handle++) {
> > > - ret = EFI_CALL(efi_handle_protocol(
> > > - *handle,
> > > - &efi_guid_firmware_management_protocol,
> > > - (void **)&fmp));
> > > + struct efi_handler *fmp_handler;
> > > +
> > > + ret = efi_search_protocol(
> > > + *handle, &efi_guid_firmware_management_protocol,
> > > + &fmp_handler);
> > > if (ret != EFI_SUCCESS)
> > > continue;
> > > + fmp = fmp_handler->protocol_interface;
> > > /* get device's image info */
> > > info_size = 0;
> > > @@ -215,10 +217,6 @@ efi_fmp_find(efi_guid_t *image_type, u8 image_index, u64 instance,
> > > skip:
> > > efi_free_pool(package_version_name);
> > > free(image_info);
> > > - EFI_CALL(efi_close_protocol(
> > > - (efi_handle_t)fmp,
> > > - &efi_guid_firmware_management_protocol,
> > > - NULL, NULL));
> > > if (found)
> > > return fmp;
> > > }
> > > --
> > > 2.37.2
> > >
next prev parent reply other threads:[~2022-10-11 7:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 14:06 [PATCH 1/1] efi_loader: CloseProtocol in efi_fmp_find Heinrich Schuchardt
2022-10-07 15:18 ` Ilias Apalodimas
2022-10-11 0:49 ` AKASHI Takahiro
2022-10-11 5:58 ` Heinrich Schuchardt
2022-10-11 7:35 ` AKASHI Takahiro [this message]
2022-10-11 11:08 ` Heinrich Schuchardt
2022-10-11 11:12 ` Heinrich Schuchardt
2022-10-12 0:11 ` AKASHI Takahiro
2022-10-12 0:09 ` AKASHI Takahiro
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=20221011073541.GB39168@laputa \
--to=takahiro.akashi@linaro.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=ilias.apalodimas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox