Quoting Maxime Ripard (2022-11-09 03:00:45) > On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote: > > > > Maxime Ripard <maxime@xxxxxxxxxx> writes: > > > > > Hi, > > > > > > On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote: > > > > Assigning the parent clock in the DT works once, at boot, but going off > > what you wrote in the commit message, if the clock driver has a > > .determine_rate() implementation that *can* reparent clocks then it > > probably *will* reparent them, and the DT assignment will be lost. > > Yes, indeed, but assigned-clock-parents never provided any sort of > guarantee on whether or not the clock was allowed to reparent or not. > It's just a one-off thing, right before probe, and a clk_set_parent() > call at probe will override that just fine. > > Just like assigned-clock-rates isn't permanent. > > > What I'm suggesting is a runtime constraint that the clock subsystem > > would enforce, and actively prevent drivers from changing the parent. > > Either explicitly with clk_set_parent() or due to .determine_rate(). > > > > That way you could write a .determine_rate() implementation that *can* > > select a better parent, but if the DT applies a constraint to fix the > > clock to a particular parent, the clock subsystem will force that parent > > to be used so you can be sure the clock is never reparented by accident. > > Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't > too far off from this, it's just ignored by clk_set_parent() for now. I > guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make > clk_set_parent handle it, and set that flag whenever > assigned-clock-parents is set on a clock. > > It's out of scope for this series though, and I certainly don't want to > deal with all the regressions it might create :) > This sounds like a new dt binding that says the assigned parent should never change. It sounds sort of like gpio hogs. A clock-hogs binding?
