On Fri, Jul 28, 2023 at 02:00:25PM +0300, Ilias Apalodimas wrote: > Hi Tom > > On Thu, 27 Jul 2023 at 19:43, Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Jul 27, 2023 at 05:07:11PM +0100, Abdellatif El Khlifi wrote: > > > > > Add MM communication support using FF-A transport > > > > > > This feature allows accessing MM partitions services through > > > EFI MM communication protocol. MM partitions such as StandAlonneMM > > > or smm-gateway secure partitions which reside in secure world. > > > > > > An MM shared buffer and a door bell event are used to exchange > > > the data. > > > > > > The data is used by EFI services such as GetVariable()/SetVariable() > > > and copied from the communication buffer to the MM shared buffer. > > > > > > The secure partition is notified about availability of data in the > > > MM shared buffer by an FF-A message (door bell). > > > > > > On such event, MM SP can read the data and updates the MM shared > > > buffer with the response data. > > > > > > The response data is copied back to the communication buffer and > > > consumed by the EFI subsystem. > > > > > > MM communication protocol supports FF-A 64-bit direct messaging. > > > > > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhl...@arm.com> > > > Tested-by: Gowtham Suresh Kumar <gowtham.sureshku...@arm.com> > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > Cc: Tom Rini <tr...@konsulko.com> > > > Cc: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > > Cc: Jens Wiklander <jens.wiklan...@linaro.org> > > > > > > --- > > > > > > Changelog: > > > =============== > > > > > > v17: > > > > > > * show a debug message rather than an error when FF-A is not detected > > [snip] > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index c5835e6ef6..8fbadb9201 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > config EFI_MM_COMM_TEE > > > - bool "UEFI variables storage service via OP-TEE" > > > - depends on OPTEE > > > + bool "UEFI variables storage service via the trusted world" > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > You didn't get my changes in here however. If you can do EFI_MM_COMM_TEE > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then > > you don't make this option depend on . If FF-A is only > > for use here, you make FF-A depend on this, and the FF-A specific > > variable depend on ARM_FFA_TRANSPORT. > > Abdellatif hinted at what's going on here. When I added this Kconfig > option to lx2160 FF-A wasn't implemented yet.
The defconfig has existed since May 2020, which is when you added EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I did until now and saw this series was disabling what was on the other platform. > Since FF-A isn't a new > communication mechanism but builds upon the existing SMCs to build an > easier API, I asked Abdellatif to hide this complexity. > We had two options, either make Kconfig options for either FF-A or the > traditional SMCs and remove the dependencies, or piggyback on FF-As > discovery mechanism and make the choice at runtime. The latter has a > small impact on code size, but imho makes developers' life a lot > easier. I'm not sure how much you can do a run-time option here since you're setting a bunch of default values for FF-A to 0 in Kconfig. If we're supposed to be able to get them at run time, we shouldn't need a Kconfig option at all. I'm also not sure how valid a use case it is where we won't know at build time what the rest of the firmware stack supports here. -- Tom
signature.asc
Description: PGP signature
