HACK: ARM: smccc-call: Use r12 to route secure monitor calls
Our ROM Secure Monitor(SM) uses the value in r12 to determine which
service is being requested by an SMC call. This goes against he ARM
recommended SMC Calling Convention(SMCCC), which partitions the values
in R0 for this task, OP-TEE's SM follows the ARM recommended convention.
We need a way to signal that a call is for our new SM and not for
the ROM SM in a way that is safe for the ROM SM, in case OP-TEE is
not installed. We do this by putting a value of 0x200 in r12 when the
call is for OP-TEE by modifying the SMCCC caller function.
There are four combinations of events:
If the ROM SM is present and we make a legacy style SMC call, as we
do in early boot, the call will not have r12 set to 0x200 as these
calls go through existing mach-omap2/ SMC handlers, so all is well.
If the ROM SM is present and we make an SMCCC style call, r12 will be
set to 0x200 and ROM SM will see this as an invalid service call and
safely return to the normal world. This should not happen.
If OP-TEE is present and we make a legacy style SMC call, r12 will
not be set to 0x200, and OP-TEE will emulate the functionality that
the call is requesting.
If OP-TEE is present and we make an SMCCC style call, r12 is checked
and as it will be 0x200 we can ignore it and treat the rest of the
registers in the standard SMCCC way.
Using a TI specific calling convention was rejected upstream[0], the
suggested solution was to change all legacy calls to perform runtime
switching based on the DT OP-TEE, this is not a reasonable solution
given how many platforms would be affected, so we will have to keep
this non-upstreamable HACK for now.
[0] https://patchwork.kernel.org/patch/9957687/
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Harinarayan Bhatta