[PATCH 1/3] arm64: efi: Simplify arch_efi_call_virt macro by not using efi_##f##_t type
Ard Biesheuvel
ardb at kernel.org
Sat Jun 25 09:01:37 PDT 2022
On Sat, 25 Jun 2022 at 12:11, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Fri, Jun 24, 2022 at 07:45:14PM +0200, Ard Biesheuvel wrote:
> > On Fri, 24 Jun 2022 at 17:23, 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 typecasting p->f to (void *)
> > > as required by __efi_rt_asm_wrapper() and eliminate the explicit need
> > > for efi_##f##_t type for every user of this macro.
> > >
> >
> > Can't we just use typeof() here?
>
> I had tried that, but unless p->f is pointer of some type, we will get
> the warning as it is passed without a cast to __efi_rt_asm_wrapper().
>
> > __efi_rt_asm_wrapper() was intended as a temporary thing, so I'd
> > prefer to avoid starting to rely on the void* type of its first
> > argument.
> >
>
> Fair enough. Can we expect p->f to be some pointer then ? If yes, then
> PRMT driver needs to change the handler_addr from u64 to some pointer
> which sounds OK to me.
>
We are dealing with function pointers here, so passing those as u64 is
just sloppy.
More information about the linux-arm-kernel
mailing list