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

[Alexander Stein <alexander.stein@ew.tq-group.com>]

Hello Maxime,

Am Montag, 4. April 2022, 09:27:12 CEST schrieb Maxime Ripard:
> On Mon, Apr 04, 2022 at 09:06:42AM +0200, Alexander Stein wrote:
> > Here is the requested output:
> > ---
> > $ ./scripts/faddr2line build_arm64/vmlinux
> > 'clk_mux_determine_rate_flags+0x33c/0x380'
> > clk_mux_determine_rate_flags+0x33c/0x380:
> > clk_mux_determine_rate_flags at drivers/clk/clk.c:627
> > ---
> > From a first look it seems that 'best_parent' is just a NULL-pointer here.
> > With this small fix
> > --->8---
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 071857ef381a..45e081330fac 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -626,7 +626,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> > 
> >         pr_crit("%s: Best parent %s (%lu)\n",
> >         
> >                 __func__,
> > 
> > -               best_parent->name,
> > +               best_parent? best_parent->name : "unknown",
> > 
> >                 best);
> >         
> >         return 0;
> > 
> > --->8---
> > 
> > The boot eventually get stuck, but at a later point.Which is probably why
> > your analysis found nothing strange. Due to the size of the output I put
> > it on a gist on github [1]. Please note that this is still based on a
> > next-20220331 based tree without the revert.
> 
> I've looked into it over the weekend, and ran qemu on an imx6 to try to
> see if it was any similar
> 
> I believe the issue comes from the fact that the core will forward rate
> requests structure to the parent clock as is, and if the parent clock
> changes the parent it wants, we end up trying to use that parent in the
> initial clock which doesn't work really well.
> 
> I've fixed it in my branch here:
> https://github.com/mripard/linux/commits/rpi/clk-improvements-more-fixes

Thanks for providing another patchset. Unfortunately, my board hangs still at 
the same location. For reference I put a branch based on next-20220401 on [1].
Reverting still does the jobs, a branch is shown on [2]

next-20220404 has the offending patch already reverted, so this should work 
again, I did not test it on that base on purpose.

Best regards,
Alexander

[1] https://github.com/tq-steina/linux/tree/clk-fix
[2] https://github.com/tq-steina/linux/tree/clk-revert