From: sashiko-bot@kernel.org
To: "Troy Mitchell" <troy.mitchell@linux.spacemit.com>
Cc: linux-clk@vger.kernel.org
Subject: Re: [PATCH 3/5] clk: spacemit: describe CPU clock dividers and shared PLL muxes
Date: Wed, 09 Sep 2026 14:21:51 +0000 [thread overview]
Message-ID: <20260909142152.612951F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260909-spacemit-pll-init-v1-3-b3065ad5a4ac@linux.spacemit.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `.set_rate_and_parent` implementation causes non-atomic updates of clock mux and divider, risking severe CPU over-clocking and crashes during frequency scaling.
--
commit caf894b03e44c8fc393822573e3c7ad1a85fe9f1
Author: Troy Mitchell <troy.mitchell@linux.spacemit.com>
clk: spacemit: describe CPU clock dividers and shared PLL muxes
This commit models the K1 and K3 CPU clock dividers and bypass conditions.
It registers sharing muxes as internal clocks and excludes K3 selector 4
from the modeled parents to match BSP policy.
> diff --git a/drivers/clk/spacemit/ccu-k1.c b/drivers/clk/spacemit/ccu-k1.c
> index dee14d25f75d4..40cc96c4ee876 100644
> --- a/drivers/clk/spacemit/ccu-k1.c
> +++ b/drivers/clk/spacemit/ccu-k1.c
> @@ -391,8 +391,8 @@ static const struct clk_parent_data cpu_c0_clk_parents[] = {
> CCU_PARENT_HW(pll2_d3),
> CCU_PARENT_HW(cpu_c0_hi_clk),
> };
> -CCU_MUX_FC_DEFINE(cpu_c0_core_clk, cpu_c0_clk_parents, APMU_CPU_C0_CLK_CTRL, BIT(12), 0, 3,
> - CLK_IS_CRITICAL);
> +CCU_MUX_DIV_FC_DEFINE(cpu_c0_core_clk, cpu_c0_clk_parents, APMU_CPU_C0_CLK_CTRL,
> + 3, 3, BIT(12), 0, 3, CLK_IS_CRITICAL);
[Severity: High]
Does introducing the divider model to K1's CPU clock here risk severe CPU
over-clocking and crashes during frequency scaling?
The operations struct spacemit_ccu_mux_div_ops in
drivers/clk/spacemit/ccu_mix.c appears to lack .set_rate_and_parent,
which is required by the Common Clock Framework (CCF) to atomically update
both mux and divider.
When cpufreq scales down frequency (e.g., from 614.4 MHz to 409.6 MHz), it
decreases the frequency before lowering the voltage. In K1,
ccu_mix_calc_best_rate() iterates parents and stops at the first exact match,
for example index 1 (pll1_d3_819p2, 819.2 MHz) with div=2.
Because spacemit_ccu_mux_div_ops lacks .set_rate_and_parent, CCF's
clk_change_rate() executes updates sequentially, calling .set_parent
before .set_rate. .set_parent changes the hardware mux to 819.2 MHz
while the divider remains at its previous value (div=1). The CPU temporarily
runs at 819.2 MHz at a voltage only sufficient for 614.4 MHz, causing an
immediate undervoltage crash.
Could spacemit_ccu_mux_div_ops be updated to include a
.set_rate_and_parent implementation to ensure the mux and divider are
updated atomically?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-spacemit-pll-init-v1-0-b3065ad5a4ac@linux.spacemit.com?part=3
next prev parent reply other threads:[~2026-09-09 14:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 14:07 [PATCH 0/5] clk: spacemit: preserve and safely synchronize firmware PLLs Troy Mitchell
2026-09-09 14:07 ` [PATCH 1/5] clk: spacemit: derive PLL rates from hardware Troy Mitchell
2026-09-09 14:07 ` [PATCH 2/5] clk: spacemit: make MIX rate selection consistent Troy Mitchell
2026-09-10 13:01 ` Yao Zi
2026-09-10 14:19 ` Troy Mitchell
2026-09-09 14:07 ` [PATCH 3/5] clk: spacemit: describe CPU clock dividers and shared PLL muxes Troy Mitchell
2026-09-09 14:21 ` sashiko-bot [this message]
2026-09-10 3:23 ` Troy Mitchell
2026-09-09 14:07 ` [PATCH 4/5] clk: spacemit: reject rate changes to running firmware PLLs Troy Mitchell
2026-09-09 14:22 ` sashiko-bot
2026-09-10 13:31 ` Yao Zi
2026-09-11 2:02 ` Troy Mitchell
2026-09-11 6:08 ` Yao Zi
2026-09-09 14:07 ` [PATCH 5/5] clk: spacemit: safely synchronize PLL parameters during init Troy Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260909142152.612951F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=troy.mitchell@linux.spacemit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox