Re: [PATCH] clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual timer
Marc Zyngier <[email protected]> Thu, 23 Jul 2026 10:58:36 +0100
| Newsgroups | org.kernel.vger.linux-tegra,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 23 Jul 2026 10:24:00 +0100, Jon Hunter <[email protected]> wrote: > > >> > >> I have posted something similar for Tegra [0], but because this is not > >> expected to work, I wanted to avoid the warnings here. We test for > > > > "not expected to work"? In which parallel universe is that a thing? > > FWIU, at least for Tegra194, we have a CPU and GIC pairing where the > CPU supports this but the GIC does not. Oh please, you know better than this. It isn't the GIC that defines the number of supported PPIs, it is the *integrator*. I.e. you. The GIC (GIC400 in this example) has full support for 16 PPIs per CPU. I have a collection of VHE-capable machines with GIC400 that correctly implement the EL2 virtual timer PPI (if even Amlogic and AllWinner can get this right, really *anybody* can). My conclusion is that someone couldn't be bothered to drag a wire from one end to the other. In any case, the result is the same: a non-working timer, and a machine that is out of specification. > > >> kernel warnings and ideally we would not warn if is known not to > >> work. We could always display an info level print if it is needed. > > > > No. These warnings are required because the HW is broken, and violates > > the basics of the architecture, which the kernel relies on. That's > > important information that needs to be captured, and that's why the > > kernel also gets tainted. > > > > This applies to any implementation that hasn't been bothered to follow > > the spec. Don't worry, you're in good company. > > Well Tegra194 does not appear to have, but Tegra234 does (but we have > a firmware issue which should be easy to fix but the current released > firmware as this issue). I have also checked Tegra264 and that should > be following the spec too. Then provide a way to unambiguously identify the updated firmware, and the warning will magically disappear once people update their firmware to a non-broken version. Thanks, M. -- Without deviation from the norm, progress is not possible.