Hi Yann,

It is better to introduce the abstract the MHU communication.

The current communication between the platform and RSE is tightly coupled with MHU.  This layer would abstract the 
communication interface, allowing different underlying mechanisms (such as MHU, or alternative protocols) to be used seamlessly without altering
the higher-level logic.
By decoupling the communication mechanism from MHU, you can make these psa call available for every platform. The abstraction layer can provide
a unified API , which would internally select the appropriate method (MHU or other) based on the platform's capabilities.

I agree with David that using the existing flag PLAT_MHU_VERSION could be misleading. It would be better to repurpose this macro as
PLAT_MHU=<NO_MHU, MHUv1, MHUv2, ...> and use it accordingly in the code. Adding another option on top of the existing PLAT_MHU_VERSION
macro may unnecessarily clutter the macros.

I'm curious to know where you plan to use these psa_call functions, as the current definition of this is in rse_comm.c, which I believe may not be
right place for your needs if you want to generalise this definition.

Thanks,
Manish Badarkhe
From: David Vincze <David.Vincze@arm.com>
Sent: 24 September 2024 08:41
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>; Yann Gautier <yann.gautier@foss.st.com>
Cc: Tamas Ban <Tamas.Ban@arm.com>; Raef Coles <Raef.Coles@arm.com>; Manish Badarkhe <Manish.Badarkhe@arm.com>; Olivier Deprez <Olivier.Deprez@arm.com>
Subject: Re: [TF-A] PSA calls with RSE comms and MHU
 

Hi Yann,

You are right, the RSE comms is basically a custom RPC protocol between the application processor and RSE which is coupled

with MHUs (acting as the data link layer). The RSE comms sounds like it’s specific to this platform component (RSE) but the protocol
itself could be extended to other platforms as well I believe. The platform dependency here is the MHU, how the data is transferred.

 

Your approach could work, adding an extra data layer between the abstract MHU communication (include/drivers/arm/mhu.h) and the RSE comms
protocol – hiding the platform specifics of the data transfer. However, setting PLAT_MHU_VERSION to 0 would be misleading to some extent I think.

I would rather introduce a new build option for clarity.

What others think?

Regards,
David

 

From: Olivier Deprez <Olivier.Deprez@arm.com>
Date: Monday, 23 September 2024 at 14:14
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>, Yann Gautier <yann.gautier@foss.st.com>
Cc: Tamas Ban <Tamas.Ban@arm.com>, Raef Coles <Raef.Coles@arm.com>, David Vincze <David.Vincze@arm.com>, Manish Badarkhe <Manish.Badarkhe@arm.com>
Subject: Re: [TF-A] PSA calls with RSE comms and MHU

+few stakeholders in Cc

 

From: Yann Gautier via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 23 September 2024 11:28

To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>

Subject: [TF-A] PSA calls with RSE comms and MHU

 

Hello,

I would like to use PSA calls for an application on STM32MP2 platform.
I've seen the psa_call() API that I could use, in
drivers/arm/rse/rse_comms.c.

The problem is that it is based on MHU mailbox, which I don't have on
STM32MP2.
So I was planning plan to disentangle RSE comms and MHU, having a new
file in the same directory to manage MHU.
This code should then be under a flag, I could re-use PLAT_MHU_VERSION.
Setting it to 0, would mean no MHU.

AFAICT TF-M uses that split with a dedicated file:
rse_comms_hal.c: Abstracts MHU message sending and receiving.
(see
https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html).


Do you think this approach sounds right?


Thanks,
Yann
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org