arch/arm/mach-omap2/omap-mpuss-lowpower.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
because omap_pm_ops.finish_suspend points directly to the assembly
routine omap4_finish_suspend, which lacks the expected KCFI type
metadata.
Add a small C wrapper with the exact callback prototype and use it for
finish_suspend.
Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index f18ef45e2..1c51b2f97 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -111,6 +111,11 @@ static struct cpu_pm_ops omap_pm_ops = {
.hotplug_restart = dummy_cpu_resume,
};
+static int omap4_finish_suspend_wrapper(unsigned long cpu_state)
+{
+ return omap4_finish_suspend(cpu_state);
+}
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -437,7 +442,7 @@ int __init omap4_mpuss_init(void)
}
if (cpu_is_omap44xx()) {
- omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.finish_suspend = omap4_finish_suspend_wrapper;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
omap_pm_ops.hotplug_restart = omap4_secondary_startup;
--
2.43.0On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote:
> With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> because omap_pm_ops.finish_suspend points directly to the assembly
> routine omap4_finish_suspend, which lacks the expected KCFI type
> metadata.
It sounds like omap4_finish_suspend() should be defined with
SYM_TYPED_FUNC_START then? Is that the case for all of the other
functions that are added to omap_pm_ops?
> Add a small C wrapper with the exact callback prototype and use it for
> finish_suspend.
>
> Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index f18ef45e2..1c51b2f97 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -111,6 +111,11 @@ static struct cpu_pm_ops omap_pm_ops = {
> .hotplug_restart = dummy_cpu_resume,
> };
>
> +static int omap4_finish_suspend_wrapper(unsigned long cpu_state)
> +{
> + return omap4_finish_suspend(cpu_state);
> +}
> +
> /*
> * Program the wakeup routine address for the CPU0 and CPU1
> * used for OFF or DORMANT wakeup.
> @@ -437,7 +442,7 @@ int __init omap4_mpuss_init(void)
> }
>
> if (cpu_is_omap44xx()) {
> - omap_pm_ops.finish_suspend = omap4_finish_suspend;
> + omap_pm_ops.finish_suspend = omap4_finish_suspend_wrapper;
> omap_pm_ops.resume = omap4_cpu_resume;
> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> omap_pm_ops.hotplug_restart = omap4_secondary_startup;
> --
> 2.43.0
>
--
Cheers,
Nathan
On Tue, 12 May 2026 16:34:42 +0900 Nathan Chancellor <nathan@kernel.org> wrote: > On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote: > > With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower() > > because omap_pm_ops.finish_suspend points directly to the assembly > > routine omap4_finish_suspend, which lacks the expected KCFI type > > metadata. > > It sounds like omap4_finish_suspend() should be defined with > SYM_TYPED_FUNC_START then? Is that the case for all of the other > functions that are added to omap_pm_ops? > omap_cpu_resume: the address is written to some cpu register and on that way casted to u32. So therefore does not trigger CFI. Same for secondary_startup which is also assembler code. scu_prepare is C. DO you have a pointer to any documentation: :~/linux$ grep -R SYM_TYPED_FUNC_START Documentation/ Regards, Andreas
On Tue, May 12, 2026 at 10:02:07AM +0200, Andreas Kemnade wrote:
> On Tue, 12 May 2026 16:34:42 +0900
> Nathan Chancellor <nathan@kernel.org> wrote:
>
> > On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote:
> > > With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> > > because omap_pm_ops.finish_suspend points directly to the assembly
> > > routine omap4_finish_suspend, which lacks the expected KCFI type
> > > metadata.
> >
> > It sounds like omap4_finish_suspend() should be defined with
> > SYM_TYPED_FUNC_START then? Is that the case for all of the other
> > functions that are added to omap_pm_ops?
> >
> omap_cpu_resume: the address is written to some cpu register and
> on that way casted to u32. So therefore does not trigger CFI.
> Same for secondary_startup which is also assembler code.
> scu_prepare is C.
>
> DO you have a pointer to any documentation:
> :~/linux$ grep -R SYM_TYPED_FUNC_START Documentation/
I don't think we have any formal documentation for SYM_TYPED_FUNC_START
(it should probably be documented via kernel-doc?) but you can read the
commit message of the change that added it for more information:
e84e008e7b02 ("cfi: Add type helper macros")
--
Cheers,
Nathan
On Tue, 12 May 2026 22:57:57 +0900
Nathan Chancellor <nathan@kernel.org> wrote:
> On Tue, May 12, 2026 at 10:02:07AM +0200, Andreas Kemnade wrote:
> > On Tue, 12 May 2026 16:34:42 +0900
> > Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > > On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote:
> > > > With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> > > > because omap_pm_ops.finish_suspend points directly to the assembly
> > > > routine omap4_finish_suspend, which lacks the expected KCFI type
> > > > metadata.
> > >
> > > It sounds like omap4_finish_suspend() should be defined with
> > > SYM_TYPED_FUNC_START then? Is that the case for all of the other
> > > functions that are added to omap_pm_ops?
> > >
> > omap_cpu_resume: the address is written to some cpu register and
> > on that way casted to u32. So therefore does not trigger CFI.
> > Same for secondary_startup which is also assembler code.
> > scu_prepare is C.
> >
> > DO you have a pointer to any documentation:
> > :~/linux$ grep -R SYM_TYPED_FUNC_START Documentation/
>
> I don't think we have any formal documentation for SYM_TYPED_FUNC_START
> (it should probably be documented via kernel-doc?) but you can read the
> commit message of the change that added it for more information:
>
> e84e008e7b02 ("cfi: Add type helper macros")
>
Ok, I found what is the missing piece of the puzzle in my head:
"
In order to make this easier, the compiler emits a
__kcfi_typeid_<function> symbol for each address-taken function
declaration in C, which contains the expected type identifier that
we can refer to in assembly code.
"
So time to look into my backyard if anything more is there.
Regards,
Andreas
> I don't think we have any formal documentation for SYM_TYPED_FUNC_START
> (it should probably be documented via kernel-doc?) but you can read the
> commit message of the change that added it for more information:
>
> e84e008e7b02 ("cfi: Add type helper macros")
Thanks, I had a look at it and other similar commits like
c50d328 ("arm64: Add types to indirect called assembly functions")
I was not aware of SYM_TYPED_FUNC_START before hence the logical approach
was just to wrap the function. But now with this I'll send a v2 with the
ENTRY and ENDPROC changed to SYM_TYPED_FUNC_START and SYM_FUNC_END.
Best,
Mithil
© 2016 - 2026 Red Hat, Inc.