[PATCH] clk: composite: Also consider .determine_rate for rate + mux composites
martin.blumenstingl at googlemail.com
Mon Nov 1 13:58:38 PDT 2021
On Mon, Nov 1, 2021 at 9:19 PM Guillaume Tucker
<guillaume.tucker at collabora.com> wrote:
> Hi Martin,
> Please see the bisection report below about a boot failure on
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.
> Some more details can be found here:
> Here's what appears to be the cause of the problem:
> [ 0.033465] CPU: CPUs started in inconsistent modes
> [ 0.033557] Unexpected kernel BRK exception at EL1
> [ 0.034432] Internal error: BRK handler: f2000800 [#1] PREEMPT SMP
> There doesn't appear to be any other platform in KernelCI showing
> the same issue.
That's a strange error for the changes from my patch.
At first glance I don't see any relation to clk-composite code:
- the call trace doesn't have any references to CCF or rockchip clock drivers
- clk-rk3328.c uses drivers/clk/rockchip/clk-cpu.c to register the CPU
clock which does not use clk-composite
Chen-Yu has tested this patch (plus ) on RK3399 and didn't observe
So maybe this is a RK3328 specific issue?
Anyways, I am interested in fixing this issue because reverting is
becoming more and more complex (since I think we're at eight commits
which would need to be reverted in total).
> Please let us know if you need help debugging the issue or if you
> have a fix to try.
Could you please try  which is the second patch in the series which
finally made it upstream.
This second patch is not in 5.15 because I believed that it's only
something to make the code in clk-composite.c more future-proof. It's
not a condition that I am aware of.
I don't have any Rockchip boards myself.
So I am thankful for any help I can get.
More information about the Linux-rockchip