[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [[PATCH v3] 4/4] xen/arm: Replace call_smc with arm_smccc_smc
Hi Andrew, On 10/01/2018 02:11 PM, Andrew Cooper wrote: On 01/10/18 13:46, Julien Grall wrote:call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to do SMCCC call, replace all call to the former by the later. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> --- Changes in v3: - Use PSCI_RET where needed --- xen/arch/arm/Makefile | 1 - xen/arch/arm/platforms/exynos5.c | 3 ++- xen/arch/arm/platforms/seattle.c | 4 ++-- xen/arch/arm/psci.c | 37 +++++++++++++++++++++++++------------ xen/arch/arm/smc.S | 21 --------------------- xen/include/asm-arm/processor.h | 3 --- 6 files changed, 29 insertions(+), 40 deletions(-) delete mode 100644 xen/arch/arm/smc.S diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index b9b141dc84..37fa8268b3 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -39,7 +39,6 @@ obj-y += processor.o obj-y += psci.o obj-y += setup.o obj-y += shutdown.o -obj-y += smc.o obj-y += smp.o obj-y += smpboot.o obj-y += sysctl.o diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c index c15ecf80f5..e2c0b7b878 100644 --- a/xen/arch/arm/platforms/exynos5.c +++ b/xen/arch/arm/platforms/exynos5.c @@ -26,6 +26,7 @@ #include <asm/platforms/exynos5.h> #include <asm/platform.h> #include <asm/io.h> +#include <asm/smccc.h>static bool secure_firmware; @@ -249,7 +250,7 @@ static int exynos5_cpu_up(int cpu)iounmap(power);if ( secure_firmware )- call_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0); + arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL);return cpu_up_send_sgi(cpu);} diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c index 893cc17972..64cc1868c2 100644 --- a/xen/arch/arm/platforms/seattle.c +++ b/xen/arch/arm/platforms/seattle.c @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst = */ static void seattle_system_reset(void) { - call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); }static void seattle_system_off(void){ - call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); }PLATFORM_START(seattle, "SEATTLE")diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index 941eec921b..4ae6504f3e 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 PSCI_RET(res.a0); }Sorry if I'm jumping into the middle of a conversation, but why force all callers to manually extract the return value when it is a fixed register? The SMCCC allows up to 4 return value (a0 ... a3). At the moment, most of the caller in Xen only care about one result value. But this will change soon (see OP-TEE support in Xen). Wouldn't it be far easier to do this: #define arcm_smccc_smc(...) \ ({ \ struct arm_smccc_res res; \ \ if ( cpus_have_const_cap(ARM_SMCCC_1_1) ) \ res = arm_smccc_1_1_smc(__VA_ARGS__); \ else \ res = arm_smccc_1_0_smc(__VA_ARGS__); \ \ (int)res.a0; \ We can't possibly cast here. The interpretation of a0 is different from one call to another. }) Which also allows the compiler to optimise out the structure if it isn't read, and also avoids the caller needing to pass a NULL pointer for "I don't want the result". While I understand the value, I don't think this would be correct if we want to implement an interface with the SMCCC. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |