Geert, On Tue, 03 May 2022 15:22:35 +0100, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Marc, > > On Tue, May 3, 2022 at 3:12 PM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > On 2022-05-03 12:55, Phil Edworthy wrote: > > > Some SoCs use a gated clock for the timer and the means to reset the > > > timer. > > > Hence add these as optional. > > > > The architecture is crystal clear on the subject: the counter > > is in an always-on domain. Why should this be visible to SW? > > Also, reseting the counter breaks the guaranteed monotonicity > > we rely on. > > The DT bindings do state: > > always-on: > type: boolean > description: If present, the timer is powered through an always-on power > domain, therefore it never loses context. > > and (surprisingly?) the absence of this property seems to be the > norm... *timer* is the key word. And counter != timer. What your HW has is a gate on the *counter* which is illegal if observable from NS SW. > > And: > > arm,no-tick-in-suspend: > type: boolean > description: The main counter does not tick when the system is in > low-power system suspend on some SoCs. This behavior does not match the > Architecture Reference Manual's specification that the system > counter "must > be implemented in an always-on power domain." > > So there's already precedent for clocks that can be disabled. No, this is only the case in *suspend*, as the name of the property vaguely hints at. And that's a property for a bug. In your case, the clock can be controlled arbitrarily, which is even worse. > > > Worse case, this belongs to the boot firmware, not the kernel, > > and I don't think this should be described in the DT. > > "DT describes hardware, not software policy"? I'm happy to spread "always-on" properties all over the shop, but that's not helping. The HW spec says it in bold letters: the counter is always running, and doesn't jump backward. I can't imagine how secure SW will behave when you reset its counter... :-/ M. -- Without deviation from the norm, progress is not possible.
