Quoting Maxime Ripard (2022-11-07 07:26:03)
On Mon, Nov 07, 2022 at 12:06:07PM +0000, Mark Brown wrote:
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote:
On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote:
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
I'm sorry, I'm not sure what you mean here. The only issue to fix at the moment is that determine_rate and set_parent aren't coupled, and it led to issues due to oversight.
I initially added a warning but Stephen wanted to fix all users in that case and make that an error instead.
My suggestion is that instead of doing either of these things it'd be quicker and less error prone to just fix the core to provide the default implementation if nothing more specific is provided. Any issues that causes would already be present with your current series.
If I filled __clk_mux_determine_rate into clocks that weren't using it before, I would change their behavior. With that flag set, on all users I add __clk_mux_determine_rate to, the behavior is the same than what we previously had, so the risk of regressions is minimal, and everything should keep going like it was?
The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag.
The behavior assumed by default was equivalent to __clk_mux_determine_rate + CLK_SET_RATE_NO_REPARENT. We could indeed set both if determine_rate is missing in the core, but that's unprecedented in the clock framework so I think we'll want Stephen to comment here :)
The clk_ops pointer is const (no writeable jump tables) so we'd have to copy the clk_ops struct on registration to set the __clk_mux_determine_rate() op. We could set the flag though and then check for the absence of a determine_rate op. Things like clk_core_can_round() would need to check for the flag. I'd actually forgotten about this flag. In hindsight I think we should delete it. I'd expect it to be used when walking the clk tree during rate rounding, but it's only used in the determine rate clk op.
It's also replacing one implicit behavior by another. The point of this series was to raise awareness on that particular point, so I'm not sure it actually fixes things. We'll see what Stephen thinks about it.
Right. A decade ago (!) when determine_rate() was introduced we introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see commit 819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This way driver behavior wouldn't change and the status quo would be maintained, i.e. that clk_set_rate() on a mux wouldn't change parents. We didn't enforce that determine_rate exists if the set_parent() op existed at the same time though. Probably an oversight.
Most of the replies to this series have been "DT is setting the parent", which makes me believe that there are 'assigned-clock-parents' being used. The clk_set_parent() path is valid for those cases. Probably nobody cares about determine_rate because they don't set rates on these clks. Some drivers even explicitly left out determine_rate()/round_rate() because they didn't want to have some other clk round up to the mux and change the parent.
Eventually we want drivers to migrate to determine_rate op so we can get rid of the round_rate op and save a pointer (we're so greedy). It's been 10 years though, and that hasn't been done. Sigh! I can see value in this series from the angle of migrating, but adding a determine_rate op when there isn't a round_rate op makes it hard to reason about. What if something copies the clk_ops or sets a different flag? Now we've just added parent changing support to clk_set_rate(). What if the clk has CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to change rate. Fun bugs.
TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't then the clk is a mux that doesn't want to support clk_set_rate(). Make a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT branch in clk_mux_determine_rate_flags() and call that directly from the clk_ops so it is clear what's happening, clk_hw_mux_same_parent_determine_rate() or something with a better name. Otherwise migrate the explicit determine_rate op to this new function and don't set the flag.
It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag with this design, if the determine_rate clk_op can call the inner wrapper function instead of __clk_mux_determine_rate*() (those underscores are awful, we should just prefix them with clk_hw_mux_*() and live happier). That should be another patch series.