Hi Phil, This is the only patch from this series that I've received, and judging by the CC list this hasn't gone to either LKML or LAKML, so I'm missing the surrounding context for this. Looking on lore, this is part of: https://lore.kernel.org/linux-devicetree/20220503115557.53370-1-phil.edworthy@xxxxxxxxxxx/T/#t ... which is adding support for an arm64 SoC. On Tue, May 03, 2022 at 12:55:49PM +0100, 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 clock feeding the architected timer is supposed to be in an always-on clock domain, and is supopsed to be enabled before running any Normal World software. The arm64 kernel *requires* that this is enabled prior to entry. If the kernel ever has to touch either the clock or reset, then there are phases where the counter will not function correctly, which is simply broken. Given that, I do not think this should be in the DT, and instead the clock should be marked as critical in the provider node (and the reset should never be touched). Thanks, Mark. > Signed-off-by: Phil Edworthy <phil.edworthy@xxxxxxxxxxx> > --- > .../devicetree/bindings/timer/arm,arch_timer.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > index df8ce87fd54b..20cd90fc7015 100644 > --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml > @@ -64,6 +64,13 @@ properties: > CNTFRQ on all CPUs to a uniform correct value. Use of this property is > strongly discouraged; fix your firmware unless absolutely impossible. > > + clocks: > + description: Optional clock for the timer. > + maxItems: 1 > + > + resets: > + maxItems: 1 > + > always-on: > type: boolean > description: If present, the timer is powered through an always-on power > -- > 2.32.0 >
