Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put

[Stephen Boyd <sboyd@kernel.org>]

Quoting Tony Lindgren (2022-03-31 10:00:09)
> * Maxime Ripard <maxime@cerno.tech> [220331 15:29]:
> > On Thu, Mar 31, 2022 at 06:00:42PM +0300, Tony Lindgren wrote:
> > > * Maxime Ripard <maxime@cerno.tech> [220331 09:52]:
> > > > On Thu, Mar 31, 2022 at 12:42:10PM +0300, Tony Lindgren wrote:
> > > > > It seems the dts assigned-clock-parents no longer works now?
> > > > 
> > > > That would make some kind of sense, __set_clk_parents calls clk_put on
> > > > both the assigned clock and its parent.
> > > > 
> > > > Could you see what parent (and why?) it tries to enforce then?
> > > 
> > > It picks the other option available for the mux clock that only has
> > > two options. No idea why, but if you have some debug patch in mind I
> > > can give it a try.
> > > 
> > > > It looks like the gpt1_fck driver might favor another parent for that
> > > > rate, which, if it's an invalid configuration, shouldn't really happen?
> > > 
> > > Hmm there's a gate clock and a mux clock, there's not really a rate
> > > selection available here for the sources.
> > 
> > If I followed the OMAP driver properly, clk_mux_determine_rate_flags is
> > doing the heavy lifting, could you run your test with
> 
> Thanks that produces some interesting output. In the working case with
> the $subject patch reverted we have:

I don't think clk_put() dropping a range request is very important right
now. If this isn't fixed tomorrow then we should revert out this patch
so systems can boot -rc1 and try to fix it in parallel.