vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   65ba8f34ec886ec72b2c07ddc8cf3d815c32869d
commit: 7a097aba725501c399b5e93d0199aa3a2f6e9c88 clocksource/drivers/timer-mediatek: Convert to OF probing
date:   2 weeks ago
config: x86_64-buildonly-randconfig-1001-20261028 (https://download.01.org/0day-ci/archive/20261029/202610290223.iOEGeDs2-lkp@intel.com/config)
compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261029/202610290223.iOEGeDs2-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Fixes: 7a097aba7255 ("clocksource/drivers/timer-mediatek: Convert to OF probing")
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202610290223.iOEGeDs2-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS_OF
   Depends on [n]: PM_GENERIC_DOMAINS [=y] && OF [=n]
   Selected by [m]:
   - COMMON_CLK_MT8173_MFGTOP [=m] && COMMON_CLK [=y] && (ARCH_MEDIATEK || COMPILE_TEST [=y]) && COMMON_CLK_MT8173 [=m] && PM [=y]

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

[Nathan Chancellor]

On Thu, Oct 29, 2026 at 03:10:30AM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   65ba8f34ec886ec72b2c07ddc8cf3d815c32869d
> commit: 7a097aba725501c399b5e93d0199aa3a2f6e9c88 clocksource/drivers/timer-mediatek: Convert to OF probing
> date:   2 weeks ago
> config: x86_64-buildonly-randconfig-1001-20261028 (https://download.01.org/0day-ci/archive/20261029/202610290223.iOEGeDs2-lkp@intel.com/config)
> compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20261029/202610290223.iOEGeDs2-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: 7a097aba7255 ("clocksource/drivers/timer-mediatek: Convert to OF probing")
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202610290223.iOEGeDs2-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
> >> vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

This warning occurs as a result of the above change because
of_device_get_match_data() returns NULL when CONFIG_OF is disabled,
which results in LLVM dropping the kCFI setup since it knows that there
is no valid target for this call. Adding a check for a NULL timer_init
avoids the warning, which would probably be more robust anyways since
of_device_get_match_data() could return NULL even with CONFIG_OF=y?

diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 842d6ee4259e..33bf4c97bb77 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -353,6 +353,8 @@ static int mtk_timer_probe(struct platform_device *pdev)
 	int (*timer_init)(struct platform_device *pdev);
 
 	timer_init = of_device_get_match_data(&pdev->dev);
+	if (!timer_init)
+		return -ENODEV;
 	return timer_init(pdev);
 }
 
-- 
Cheers,
Nathan

Re: vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

[Luca Leonardo Scorcia]

Thank you Nathan for the analysis and suggested fix. I agree your
patch would be useful even if the warning wasn't there, to make the
device probe more robust.

Being a new contributor I'm not quite sure what the process is now -
should I send out a patch with the correction, just as I did for the
initial contribution? Or is it going to be fixed by the maintainers
autonomously? (Obviously adding a Suggested-by tag with the rest of
the bots' tags).

Thank you for your help
-- 
Luca

Re: vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

[Daniel Lezcano]

Hi Luca,

On 10/29/26 19:54, Luca Leonardo Scorcia wrote:
> Thank you Nathan for the analysis and suggested fix. I agree your
> patch would be useful even if the warning wasn't there, to make the
> device probe more robust.
> 
> Being a new contributor I'm not quite sure what the process is now -
> should I send out a patch with the correction, just as I did for the
> initial contribution? 

If you can send a fix that would be nice

> Or is it going to be fixed by the maintainers
> autonomously? (Obviously adding a Suggested-by tag with the rest of
> the bots' tags).
> 
> Thank you for your help

Re: vmlinux.o: warning: objtool: mtk_timer_probe+0x23: no-cfi indirect call!

[Nathan Chancellor]

On Thu, Oct 29, 2026 at 07:54:10PM +0100, Luca Leonardo Scorcia wrote:
> Being a new contributor I'm not quite sure what the process is now -
> should I send out a patch with the correction, just as I did for the
> initial contribution? Or is it going to be fixed by the maintainers
> autonomously? (Obviously adding a Suggested-by tag with the rest of
> the bots' tags).

Since the patch is already in Linus's tree, you'll need to send a follow
up fix. Not only is it good practice for learning how to follow up on
issues/feedback on your patches, it will help build trust with
maintainers in case you submit other patches in the future because you
have already shown you are willing to take ownership of them. It is
generally better to send a patch if you are able than relying on a
maintainer to handle it, not only because they don't typically have the
bandwidth but because you will get full credit for the fix.

Thanks for taking care of this!

-- 
Cheers,
Nathan