Quoting Marek Vasut (2022-06-15 16:42:25) > On 6/16/22 00:22, Stephen Boyd wrote: > > Quoting Marek Vasut (2022-06-15 14:55:17) > >> > >> It means those clock must not be turned off, but there is no consumer > >> described in DT. > > > > So it means "always on". > > > >> > >>> 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. > >> > >> This property name is derived from protected-clock which you introduced. > >> I think it would be better to stay consistent within the clock framework > >> property names ? > > > > protected-clocks is based on assigned-clocks. There isn't a > > CLK_IS_PROTECTED flag. I'm not following your argument at all here, > > sorry. > > critical-clock property name is based on protected-clock property name. Got that. > > There is also no CLK_IS_ALWAYS_ON flag , but there is CLK_IS_CRITICAL > flag . Sure, there is no CLK_IS_PROTECTED flag because the protected > clock is implemented only by a single driver (qualcomm). Alright, thanks for clarifying the argument. > > I think it makes sense to align the DT property name and the flag name, > and the critical-clock is aligned with both other DT property names in > the clock framework and the flag name. No, it does not make sense to align the CLK_IS_CRITICAL flag with the DT property name. The property should be named what it is, i.e. always on. The internal clk framework details could be changed at any time whereas the DT binding is essentially forever. I agree using a similar name may help connect the code and the DT, but that is nowhere near as important as choosing a name that expresses what is happening in a binding that we need to maintain for the foreseeable future.
