From: Masami Hiramatsu <masami.hiramatsu@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Takahiro Akashi <takahiro.akashi@linaro.org>,
Michal Simek <michal.simek@xilinx.com>,
Alexander Graf <agraf@csgraf.de>,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 2/3 v2] efi_loader: Force a sinlge FMP instance per hardware store
Date: Fri, 18 Jun 2021 22:52:51 +0900 [thread overview]
Message-ID: <CAA93ih3XeCDXumMHDhaeWW3mW9DpsgMOo+WKBtoSRW_d+aNYRA@mail.gmail.com> (raw)
In-Reply-To: <20210618105115.257938-2-ilias.apalodimas@linaro.org>
Hi Ilias,
2021年6月18日(金) 19:51 Ilias Apalodimas <ilias.apalodimas@linaro.org>:
>
> Chapter 23 of the EFI spec (rev 2.9) says:
> "A specific updatable hardware firmware store must be represented by
> exactly one FMP instance".
> This is not the case for us, since both of our FMP protocols can be
> installed at the same time because they are controlled by a single
> 'dfu_alt_info' env variable.
> So make the config options depend on each other and allow the user to
> install one of them at any given time. If we fix the meta-data provided
> by the 'dfu_alt_info' in the future, to hint about the capsule type
> (fit or raw) we can revise this and enable both FMPs to be installed, as
> long as they target different firmware hardware stores
>
> Note that we are not using a Kconfig 'choice' on purpose, since we
> want to allow both of those to be installed and tested in sandbox
This sounds like changing the Kconfig, thus...
[...]
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -918,15 +918,15 @@ static void efi_capsule_scan_done(void)
> }
>
> /**
> - * arch_efi_load_capsule_drivers - initialize capsule drivers
> + * efi_load_capsule_drivers - initialize capsule drivers
> *
> - * Architecture or board specific initialization routine
> + * Generic FMP drivers backed by DFU
> *
> * Return: status code
> */
> -efi_status_t __weak arch_efi_load_capsule_drivers(void)
> +efi_status_t __weak efi_load_capsule_drivers(void)
> {
> - __maybe_unused efi_handle_t handle;
> + __maybe_unused efi_handle_t handle = NULL;
> efi_status_t ret = EFI_SUCCESS;
>
> if (IS_ENABLED(CONFIG_EFI_CAPSULE_FIRMWARE_FIT)) {
> @@ -975,10 +975,6 @@ efi_status_t efi_launch_capsules(void)
>
> index = get_last_capsule();
>
> - /* Load capsule drivers */
> - ret = arch_efi_load_capsule_drivers();
> - if (ret != EFI_SUCCESS)
> - return ret;
I think this part of the change should be included in the next patch.
Thank you,
>
> /*
> * Find capsules on disk.
> --
> 2.32.0.rc0
>
--
Masami Hiramatsu
next prev parent reply other threads:[~2021-06-18 13:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 10:51 [PATCH 1/3 v2] efi: Fix to use null handle to create new handle for efi_fmp_raw Ilias Apalodimas
2021-06-18 10:51 ` [PATCH 2/3 v2] efi_loader: Force a sinlge FMP instance per hardware store Ilias Apalodimas
2021-06-18 13:52 ` Masami Hiramatsu [this message]
2021-06-18 14:01 ` Ilias Apalodimas
2021-06-18 10:51 ` [PATCH 3/3 v2] efi_loader: Always install FMPs Ilias Apalodimas
2021-06-18 19:22 ` [PATCH 1/3 v2] efi: Fix to use null handle to create new handle for efi_fmp_raw Heinrich Schuchardt
2021-06-19 4:23 ` Masami Hiramatsu
2021-06-22 4:46 ` Ilias Apalodimas
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=CAA93ih3XeCDXumMHDhaeWW3mW9DpsgMOo+WKBtoSRW_d+aNYRA@mail.gmail.com \
--to=masami.hiramatsu@linaro.org \
--cc=agraf@csgraf.de \
--cc=ilias.apalodimas@linaro.org \
--cc=michal.simek@xilinx.com \
--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 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.