public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Masami Hiramatsu <masami.hiramatsu@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 17:01:47 +0300	[thread overview]
Message-ID: <YMynS8OrWMKCSDIw@enceladus> (raw)
In-Reply-To: <CAA93ih3XeCDXumMHDhaeWW3mW9DpsgMOo+WKBtoSRW_d+aNYRA@mail.gmail.com>

On Fri, Jun 18, 2021 at 10:52:51PM +0900, Masami Hiramatsu wrote:
> 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...
> 

It does 

> [...]
> >
> > -       /* 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,

Yep, I completely missed this during the rebasing.  I'll send a v3.

Thanks!
/Ilias

  reply	other threads:[~2021-06-18 14:02 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
2021-06-18 14:01     ` Ilias Apalodimas [this message]
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=YMynS8OrWMKCSDIw@enceladus \
    --to=ilias.apalodimas@linaro.org \
    --cc=agraf@csgraf.de \
    --cc=masami.hiramatsu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox