On Tue, Sep 15, 2015 at 07:26:45PM +0100, Will Deacon wrote:

On Mon, Sep 14, 2015 at 09:30:30AM +0100, Jens Wiklander wrote:

quoted

On Fri, Aug 21, 2015 at 01:43:31PM +0200, Jens Wiklander wrote:

quoted

On Fri, Aug 21, 2015 at 10:24:30AM +0100, Will Deacon wrote:

quoted

On Thu, Aug 20, 2015 at 12:37:29PM +0100, Jens Wiklander wrote:

quoted

On Wed, Aug 19, 2015 at 05:50:09PM +0100, Will Deacon wrote:

quoted

On Wed, Aug 19, 2015 at 09:40:25AM +0100, Jens Wiklander wrote:

quoted

+       mov     x28, x0
+       ldp     w0, w1, [x28, #SMC_PARAM_W0_OFFS]
+       ldp     w2, w3, [x28, #SMC_PARAM_W2_OFFS]
+       ldp     w4, w5, [x28, #SMC_PARAM_W4_OFFS]
+       ldp     w6, w7, [x28, #SMC_PARAM_W6_OFFS]
+       smc     #0
+       stp     w0, w1, [x28, #SMC_PARAM_W0_OFFS]
+       stp     w2, w3, [x28, #SMC_PARAM_W2_OFFS]
+       ldp     x28, x30, [sp], #16
+       ret
+ENDPROC(smccc_call32)

Could we deal with this like we do for PSCI instead? (see
__invoke_psci_fn_smc). We could also then rename psci-call.S to fw-call.S
and stick this in there too.

I assume you're referring to when to use "hvc" and "smc".

No, I mean use a C prototype to avoid marshalling the parameters in assembly
like this. As Rutland pointed out, the return value is a bit messy, but
the arguments align nicely with the PCS afaict.

If possible I'd like the function to have the same prototype for both
arm and arm64. For arm it's not possible to supply more than 4
parameters. To fully support SMC Calling Convention we need to be able
to pass 8 parameters and have 4 return values. The OP-TEE driver in this
patch set depends on this. I don't see how we can avoid the marshalling
here.

We could have two versions of the SMCCC functions, one simplified which
only uses registers and one complete like this one with marshalling.

Will, what do think about this?

I still think you should make use of a C prototype to avoid explicit
parameter marshalling in assembly. If you want to maintain a compatible
API between arm and arm64, then you can easily have an intermediate
function in arm64 that sits between the API entry point and the assembly.

Yes, I see how that's convenient for passing argument values in
registers, but that doesn't help with storing the returned values in
x0..x3 into something accessible in C. Am I missing something?

Thanks,
Jens