Re: [PATCH v3 2/2] clk: Introduce 'critical-clocks' property

[Stephen Boyd <sboyd@kernel.org>]

Quoting Marek Vasut (2022-05-17 16:59:19)
> Some platforms require select clock to be always running, e.g. because
> those clock supply vital devices which are not otherwise attached to
> the system and thus do not have a matching DT node and clock consumer.
> 
> An 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 listed in the "critical-clocks" property may have other consumers
> in DT, listing the clock in "critical-clocks" only assures those clock
> are never turned off, and none of these optional additional consumers
> can turn the clock off either. This is achieved by adding CLK_IS_CRITICAL
> flag to these critical clock.
> 
> This flag has thus far been added to select clock by hard-coding it in
> various clock drivers, this patch provides generic DT interface to add
> the flag to arbitrary clock that may be critical.
> 
> The implementation is modeled after "protected-clocks", except the protected
> clock property is currently driver specific. This patch attempts to provide
> a generic implementation of "critical-clocks" instead.
> 
> Unlike "assigned-clocks", the "critical-clocks" must be parsed much earlier
> in __clk_register() to assign CLK_IS_CRITICAL flag to clk_init_data .flags
> field.

Why? Instead of using the CLK_IS_CRITICAL flag to enable at registration
time for this, why can't we parse the property when a clk provider is
registered and enable those clks manually and then set the
CLK_IS_CRITICAL flag? Ideally we don't implement another clk_op for
this.

> 
> The new match_clkspec() callback is used to determine whether struct clk_hw
> that is currently being registered matches the clock specifier in the DT
> "critical-clocks" property, and if so, then the CLK_IS_CRITICAL is added to
> these newly registered clock. This callback can only be driver specific.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>