Re: [Xen-devel] [PATCH v2 6/6] xen/arm: Replace call_smc with arm_smccc_smc

[Julien Grall <julien.grall@xxxxxxx>]

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).
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel