[PATCH v16 09/10] arm_ffa: efi: introduce FF-A MM communication

[Tom Rini]

On Thu, Jul 27, 2023 at 10:34:50AM +0100, Abdellatif El Khlifi wrote:
> Hi Tom,
> 
> On Wed, Jul 26, 2023 at 03:39:12PM -0400, Tom Rini wrote:
> > On Wed, Jul 26, 2023 at 10:45:02AM +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.elkhlifi at arm.com>
> > > Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar at arm.com>
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > Cc: Tom Rini <trini at konsulko.com>
> > > Cc: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > > Cc: Jens Wiklander <jens.wiklander at linaro.org>
> > 
> > So, at this point in the series we impact lx2160ardb_tfa_stmm which is
> > the only config in the tree prior to this series that sets
> > CONFIG_EFI_MM_COMM_TEE. I'm not going to block this series[1] on
> > updating lx2160ardb_tfa_stmm as well, but I do want to make sure the
> > maintainers there are aware and can update the config to support the
> > current state of this technology.
> > 
> > [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=365876&state=*
> > -- 
> 
> Following a decision made with Ilias, the new MM comms design works as follows:
> 
> - Try to communicate using FF-A bus first
> - If that fails, try to communicate using Optee. So, platforms that don't support FF-A
>   in the Secure side can still use Optee communication
> 
> This is done through the code below [1].
> 
> This logic needs CONFIG_ARM_FFA_TRANSPORT=y in the defconfig.
> 
> I added CONFIG_ARM_FFA_TRANSPORT=y to lx2160ardb_tfa_stmm_defconfig, CONFIG_EFI_MM_COMM_TEE is enabled and it builds fine.
> 
> Is it expected that lx2160ardb_tfa_stmm maintainers add CONFIG_ARM_FFA_TRANSPORT=y to lx2160ardb_tfa_stmm_defconfig ?

Ah, it sounds like the Kconfig logic this patch adds is wrong then. Is
there a use case for ARM_FFA_TRANSPORT without CONFIG_EFI_MM_COMM_TEE=y
? If yes, then it's just that the FF-A related symbols for
EFI_MM_COMM_TEE need to depend on ARM_FFA_TRANSPORT.  If no,
ARM_FFA_TRANSPORT needs to depend on EFI_MM_COMM_TEE (and these new
symbols depend on ARM_FFA_TRANSPORT).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230727/6bab0be4/attachment.sig>