* [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro
@ 2022-06-28 14:18 Sudeep Holla
2022-06-28 16:29 ` Ard Biesheuvel
0 siblings, 1 reply; 4+ messages in thread
From: Sudeep Holla @ 2022-06-28 14:18 UTC (permalink / raw)
To: linux-arm-kernel, linux-efi; +Cc: Sudeep Holla, Ard Biesheuvel, Russell King
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 eliminating the explicit
need for efi_##f##_t type for every user of this macro.
This change is done to align with implementations on other similar
architectures.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/include/asm/efi.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
v1[1]->v2:
- Dropped the usage of even typeof() and simply call p->f(args)
as suggested by Ard
[1] https://lore.kernel.org/r/20220628125938.694256-1-sudeep.holla@arm.com/
diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index 27218eabbf9a..bb4d15101de4 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -24,12 +24,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
#define arch_efi_call_virt_setup() efi_virtmap_load()
#define arch_efi_call_virt_teardown() efi_virtmap_unload()
-#define arch_efi_call_virt(p, f, args...) \
-({ \
- efi_##f##_t *__f; \
- __f = p->f; \
- __f(args); \
-})
+#define arch_efi_call_virt(p, f, args...) ((p)->f(args))
#define ARCH_EFI_IRQ_FLAGS_MASK \
(PSR_J_BIT | PSR_E_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT | \
--
2.37.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro
2022-06-28 14:18 [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro Sudeep Holla
@ 2022-06-28 16:29 ` Ard Biesheuvel
2022-06-28 16:45 ` Russell King (Oracle)
0 siblings, 1 reply; 4+ messages in thread
From: Ard Biesheuvel @ 2022-06-28 16:29 UTC (permalink / raw)
To: Sudeep Holla, Russell King; +Cc: Linux ARM, linux-efi
On Tue, 28 Jun 2022 at 16:18, Sudeep Holla <sudeep.holla@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 eliminating the explicit
> need for efi_##f##_t type for every user of this macro.
>
> This change is done to align with implementations on other similar
> architectures.
>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
I'll queue this one up right away in the EFI tree, unless Russell has
something else in mind?
> ---
> arch/arm/include/asm/efi.h | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> v1[1]->v2:
> - Dropped the usage of even typeof() and simply call p->f(args)
> as suggested by Ard
>
> [1] https://lore.kernel.org/r/20220628125938.694256-1-sudeep.holla@arm.com/
>
> diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
> index 27218eabbf9a..bb4d15101de4 100644
> --- a/arch/arm/include/asm/efi.h
> +++ b/arch/arm/include/asm/efi.h
> @@ -24,12 +24,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
> #define arch_efi_call_virt_setup() efi_virtmap_load()
> #define arch_efi_call_virt_teardown() efi_virtmap_unload()
>
> -#define arch_efi_call_virt(p, f, args...) \
> -({ \
> - efi_##f##_t *__f; \
> - __f = p->f; \
> - __f(args); \
> -})
> +#define arch_efi_call_virt(p, f, args...) ((p)->f(args))
>
> #define ARCH_EFI_IRQ_FLAGS_MASK \
> (PSR_J_BIT | PSR_E_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT | \
> --
> 2.37.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro
2022-06-28 16:29 ` Ard Biesheuvel
@ 2022-06-28 16:45 ` Russell King (Oracle)
2022-06-28 16:49 ` Ard Biesheuvel
0 siblings, 1 reply; 4+ messages in thread
From: Russell King (Oracle) @ 2022-06-28 16:45 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: Sudeep Holla, Linux ARM, linux-efi
On Tue, Jun 28, 2022 at 06:29:52PM +0200, Ard Biesheuvel wrote:
> On Tue, 28 Jun 2022 at 16:18, Sudeep Holla <sudeep.holla@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 eliminating the explicit
> > need for efi_##f##_t type for every user of this macro.
> >
> > This change is done to align with implementations on other similar
> > architectures.
> >
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> I'll queue this one up right away in the EFI tree, unless Russell has
> something else in mind?
No, looks good, thanks.
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro
2022-06-28 16:45 ` Russell King (Oracle)
@ 2022-06-28 16:49 ` Ard Biesheuvel
0 siblings, 0 replies; 4+ messages in thread
From: Ard Biesheuvel @ 2022-06-28 16:49 UTC (permalink / raw)
To: Russell King (Oracle); +Cc: Sudeep Holla, Linux ARM, linux-efi
On Tue, 28 Jun 2022 at 18:45, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Tue, Jun 28, 2022 at 06:29:52PM +0200, Ard Biesheuvel wrote:
> > On Tue, 28 Jun 2022 at 16:18, Sudeep Holla <sudeep.holla@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 eliminating the explicit
> > > need for efi_##f##_t type for every user of this macro.
> > >
> > > This change is done to align with implementations on other similar
> > > architectures.
> > >
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: Russell King <linux@armlinux.org.uk>
> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > I'll queue this one up right away in the EFI tree, unless Russell has
> > something else in mind?
>
> No, looks good, thanks.
>
> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>
OK, thanks - queued in efi/next.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-28 16:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-28 14:18 [PATCH v2] ARM: efi: Simplify arch_efi_call_virt() macro Sudeep Holla
2022-06-28 16:29 ` Ard Biesheuvel
2022-06-28 16:45 ` Russell King (Oracle)
2022-06-28 16:49 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox