Re: [PATCH] arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer

[Marc Zyngier <maz@kernel.org>]

Hi Daniel,

Thanks for posting this.

On Fri, 19 Jun 2026 21:48:32 +0100,
Daniel Drake <dan@reactivated.net> wrote:
> 
> Commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer: Default to
> EL2 virtual timer when running VHE") causes boot to hang on
> Raspberry Pi 5. The newly-selected EL2 virtual timer does not generate
> any interrupts, even though the GIC_DIST_ENABLE_SET flag has been
> confirmed set via readback.
> 
> The reasons for this failure are unknown, however it is likely that
> this timer was never tested. Raspberry Pi's original devicetree did

The timer is part of the CPU, and there are enough A76 implementations
around to prove that it actually works. The same can be said for the
GIC400 this is (supposedly) attached to.

> not include this timer interrupt; it was only introduced via a
> suggestion[1] made in code review as part of the upstreaming process.
> (Current RPi firmware versions do include this timer, but only because
> they rebased on top of the upstreamed devicetree starting with
> Linux 6.12)
> 
> Until more is known about this non-firing timer interrupt, remove
> the devicetree entry to enable RPi5 devices to boot.

I'd like to understand the reason why the timer interrupt isn't being
delivered *before* we paper over it, and not the other way
around. Each of the CPUs definitely have an EL2 virtual timer, the GIC
has a per-CPU interrupt, but somehow the two don't seem to be linked.

Since DT is supposed to describe the HW, I'd expect someone from
Broadcom or RPi to shine a light on this issue. Integration mistakes
happen, and we work around them (see the handful of Samsung SoCs where
the timer interrupt was simply not wired). But we absolutely need to
know what we are dealing with beforehand.

Finally, just hacking the DT is not enough. Assuming that the timer is
indeed unusable, we need to cope with the fact that there are DTs
describing it in the wild, as nobody should be forced to upgrade their
DT in lockstep with the kernel. For that, you'd also need something
like the patch below (untested, and in need of a proper commit
message, which I expect the SoC vendor to provide).

Thanks,

	M.

From 9de354b472e28112d73fdb63be986f68fb3c91a9 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz@kernel.org>
Date: Sat, 20 Jun 2026 09:32:09 +0100
Subject: [PATCH] clocksource/drivers/arm_arch_timer: Workaround RPi5 broken
 EL2 virtual timer

Insert $REASON here.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 drivers/clocksource/arm_arch_timer.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 4adf756423de9..de9007a30a923 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1090,6 +1090,16 @@ static int __init arch_timer_common_init(void)
 	return arch_timer_arch_init();
 }
 
+static bool __init has_broken_el2_vtimer(void)
+{
+	static const char * const broken_el2_vtimer[] __initconst = {
+		"brcm,bcm2712",
+		NULL
+	};
+
+	return of_machine_compatible_match(broken_el2_vtimer);
+}
+
 /**
  * arch_timer_select_ppi() - Select suitable PPI for the current system.
  *
@@ -1115,7 +1125,8 @@ static int __init arch_timer_common_init(void)
 static enum arch_timer_ppi_nr __init arch_timer_select_ppi(void)
 {
 	if (is_kernel_in_hyp_mode()) {
-		if (arch_timer_ppi[ARCH_TIMER_HYP_VIRT_PPI])
+		if (arch_timer_ppi[ARCH_TIMER_HYP_VIRT_PPI] &&
+		    !has_broken_el2_vtimer())
 			return ARCH_TIMER_HYP_VIRT_PPI;
 
 		pr_warn_once(FW_BUG "VHE-capable CPU without EL2 virtual timer interrupt\n");
-- 
2.47.3


-- 
Jazz isn't dead. It just smells funny.