Quoting Marek Vasut (2022-05-17 16:59:18)
> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> index f2ea53832ac63..d7f7afe2cbd0c 100644
> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -169,6 +169,22 @@ a shared clock is forbidden.
> Configuration of common clocks, which affect multiple consumer devices can
> be similarly specified in the clock provider node.
>
> +==Critical clocks==
> +
> +Some platforms require some clocks to be always running, e.g. because those
> +clock supply devices which are not otherwise attached to the system. One
> +example is a system where the SoC serves as a crystal oscillator replacement
> +for a programmable logic device. The critical-clocks property of a clock
> +controller allows listing clock which must never be turned off.
> +
> + clock-controller@a000f000 {
> + compatible = "vendor,clk95;
> + reg = <0xa000f000 0x1000>
> + #clocks-cells = <1>;
> + ...
> + critical-clocks = <UART3_CLK>, <SPI5_CLK>;
Historically "critical" is overloaded in the clk framework. We should
avoid using that name. What does "critical" even mean?
Instead I'd prefer "always-on-clocks" here, so we can indicate that
these clks should always be on. It would also parallel the property in
the regulator framework.
