From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A903429CF0; Thu, 23 Jul 2026 09:58:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784800720; cv=none; b=IpiQ4czIK4K+ea6eXRulhGCYBwrUOH7wz/2fvNLYkyeB3tJDk3xyB/dYyKasqGlqUqYqpp5g32dp/j8pvTaehDydza4lGjZ1qb6K1sWWU7Wg4Br2LB+/fD/IzymWPDGgq8b8Mh0+OCPcfNqcGG64R9+JtMiebvUU7BddIylNlp8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784800720; c=relaxed/simple; bh=g1V9RZVa2hKzMSGcL3fhJkFBowARABfk+dtwtLUVXpU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=CjioJck2WTarGa+qEUi3QmOCsQYx5xJf5Uoz1M7F8eEi6AZNnLFC5qy9Lm3njSYuAi6bt+UOO5R9Os+ziD6mHn9fNShPNQBBQOnLp6Ygojuh/aXxfTRoLgTDf9liZfbmLebrmQ/OlGEok1A8RPaS32pw+9BQkvWo5hzKe3W5JDk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09DB91F00A3A; Thu, 23 Jul 2026 09:58:39 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wmqCL-00000007ytG-06Nc; Thu, 23 Jul 2026 09:58:37 +0000 Date: Thu, 23 Jul 2026 10:58:36 +0100 Message-ID: <865x26do37.wl-maz@kernel.org> From: Marc Zyngier To: Jon Hunter Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, John , Daniel Drake , Marek Szyprowski , Florian Fainelli , Daniel Lezcano , Thomas Gleixner , Mark Rutland , "linux-tegra@vger.kernel.org" Subject: Re: [PATCH] clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual timer In-Reply-To: <325be874-bab9-464f-84ee-99e160259923@nvidia.com> References: <20260710080958.491620-1-maz@kernel.org> <325e86ea-d4d3-4c84-ae9b-f4a08c9b071b@nvidia.com> <878q72rcz6.wl-maz@kernel.org> <325be874-bab9-464f-84ee-99e160259923@nvidia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-tegra@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jonathanh@nvidia.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, therealgraysky@proton.me, dan@reactivated.net, m.szyprowski@samsung.com, florian.fainelli@broadcom.com, daniel.lezcano@linaro.org, tglx@linutronix.de, mark.rutland@arm.com, linux-tegra@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 23 Jul 2026 10:24:00 +0100, Jon Hunter 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.