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