I found four additional code points in tfm_svcalls.c that needed to be enhanced to handle msg.type >= PSA_IPC_CALL.

3 of the four were like this:

if (msg->msg.type != PSA_IPC_CALL) {

Which I changed to:

if (msg->msg.type < PSA_IPC_CALL) {

The 4th occurrence was in the switch statement within 'tfm_svcall_psa_reply()'. I moved the 'case PSA_IPC_CALL:' logic into the default block and surrounded it with:

if (msg->msg.type >= PSA_IPC_CALL) { ... } else { tfm_panic(); }

With these changes in place, the new psa_call() 'type' argument appears to make its way peacefully and effectively through the plumbing.

Alan

-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Friday, July 26, 2019 2:28 PM To: Ken Liu (Arm Technology China) Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c:

msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr);

Should be:

msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr);

Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL.

Alan

From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

Summer-ARM closed this task as "Resolved".

TASK DETAIL https://developer.trustedfirmware.org/T435

EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/

To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit