Hi Rob, On Thu, May 5, 2022 at 12:33 AM Rob Herring <robh@xxxxxxxxxx> wrote: > On Tue, May 03, 2022 at 02:11:59PM +0100, Mark Rutland wrote: > > 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). > > That is not yet an accepted DT property, but is currently on the list > for review[1]. If that's something people need, chime in. More than 1 > person needing something is always better. I am aware of[1]. AFAIU, that is meant for clocks that need to stay enabled for external reasons (external hardware driven by on-SoC clock). For internal reasons (e.g. arch-timer), CLK_IS_CRITICAL is fine. > [1] https://lore.kernel.org/all/20220428110107.149524-1-marex@xxxxxxx/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds