Hi Stefano,
On 09/27/2018 11:41 PM, Stefano Stabellini wrote:
On Wed, 26 Sep 2018, Julien Grall wrote:
Hi Stefano,
On 09/26/2018 12:57 AM, Stefano Stabellini wrote:
On Tue, 25 Sep 2018, Julien Grall wrote:
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 941eec921b..02737e6caa 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -42,42 +42,53 @@ uint32_t smccc_ver;
static uint32_t psci_cpu_on_nr;
+#define PSCI_RET(res) ((int32_t)(res).a0)
+
int call_psci_cpu_on(int cpu)
{
- return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
__pa(init_secondary), 0);
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
__pa(init_secondary),
+ &res);
+
+ return (int32_t)res.a0;
}
Can't we use PSCI_RET(res) here?
I missed that one. I will update it.
Also in general, should we care about the type mismatch int32_t vs. int
which is the return type of this function?
The only issue I could see is if sizeof(int) < sizeof(int32_t). If that
happen, then psci.c would be our least concern as we always assume int would
at least 32-bit wide.
I would prefer to keep the return of the function int and casting the result
with (int32_t). The latter is helpful to know what is the size of the result
(a0 is 64-bit).
It is a good idea to keep the cast. I don't have a strong opinion on
whether the functions should return int or int32_t. The only question is
whether we want to cast to (int32_t) or to (int). I would prefer to cast
to the same type of the return of the function. So if we keep int as
return type, then casting to (int). However, given that in practice it
makes no difference, I can ack the patch in any case.
I would prefer to stick with the current approach.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
