[PATCH v2 2/4] arm64: efi: Simplify arch_efi_call_virt() macro by using typeof()

Ard Biesheuvel ardb at kernel.org
Tue Jun 28 10:10:40 PDT 2022


On Tue, 28 Jun 2022 at 14:53, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> Currently, the arch_efi_call_virt() assumes all users of it will have
> defined a type 'efi_##f##_t' to make use of it. It is unnecessarily
> forcing the users to create a new typedef when __efi_rt_asm_wrapper()
> actually expects void pointer.
>
> Simplify the arch_efi_call_virt() macro by using typeof(p->f) which must
> be a pointer as required by __efi_rt_asm_wrapper() and eliminate the
> explicit need for efi_##f##_t type for every user of this macro.
>
> This is needed now in preparation to enable PRMT support on ARM64.
>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  arch/arm64/include/asm/efi.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index ad55079abe47..53376cdab175 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -29,8 +29,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
>
>  #define arch_efi_call_virt(p, f, args...)                              \
>  ({                                                                     \
> -       efi_##f##_t *__f;                                               \
> -       __f = p->f;                                                     \
> +       typeof(p->f) __f = p->f;                                        \
>         __efi_rt_asm_wrapper(__f, #f, args);                            \
>  })
>

Similar to the other patches, we could simply do

#define arch_efi_call_virt(p, f, args...) \
        __efi_rt_asm_wrapper((p)->f, #f, args)

here.

Note, though, that the second argument stringifies the struct field
name, which will contain "handler_addr" in the case of PRM, but this
is fine (we shouldn't hit that diagnostic for new code anyway, as it
is only used to check whether X18 was corrupted by the firmware)



More information about the linux-arm-kernel mailing list