From: sashiko-bot@kernel.org
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: lee@kernel.org, robh@kernel.org, mfd@lists.linux.dev,
vkoul@kernel.org, olteanv@gmail.com, neil.armstrong@linaro.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure
Date: Mon, 27 Jul 2026 19:15:13 +0000 [thread overview]
Message-ID: <20260727191513.EC7EE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727-zx29clk-v8-7-7a107b00f1dd@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] zx29_pll_determine_rate ignores the req->min_rate and req->max_rate constraints provided by the clock framework, potentially violating bounds.
--
--- Patch [7]: [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure ---
commit b2281439469368ad41cdfc2e3b1cb9178840d858
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add zx PLL support infrastructure
This commit introduces the ZX PLL support infrastructure for ZTE platforms,
adding rate calculation, prepare/enable operations, and registration logic.
> diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
> index f8ddb4c7dff66..6e3a20cb5839a 100644
> --- a/drivers/clk/zte/pll-zx.c
> +++ b/drivers/clk/zte/pll-zx.c
[ ... ]
> +static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
> + unsigned long rate)
> +{
[ ... ]
> + setting = fbdiv << ZX29_PLL_FBDIV_SHIFT;
> + setting |= refdiv << ZX29_PLL_REFDIV_SHIFT;
> + setting |= i << ZX29_PLL_POSTDIV1_SHIFT;
> + setting |= j << ZX29_PLL_POSTDIV2_SHIFT;
> + out = zx29_pll_get_rate(pll, parent_rate, setting);
> +
> + if (abs_diff(out, rate) > best)
> + continue;
> +
> + if (abs_diff(out, rate) < best) {
> + postdiv1 = i;
> + postdiv2 = j;
> + best_fbdiv = fbdiv;
[Severity: Medium]
Since this loop unconditionally picks the closest hardware frequency to the
requested rate, is it possible that it selects a frequency outside of the CCF
boundaries?
If a driver sets strict constraints via clk_set_rate_range(), and the nearest
PLL approximation falls outside that range while a valid alternative exists
inside it, clk_calc_new_rates() might reject the out-of-bounds rate.
[ ... ]
> +static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + unsigned long new_rate;
> + u32 setting;
> +
> + /* TODO: DPLL can switch between two parents, one of which is another PLL. Take this into
> + * account when searching the config space and set req->best_parent_rate.
> + *
> + * In practice it shouldn't matter though. Dpll is always configured to a fixed frequency
> + * and is the only clock with a switchable parent.
> + */
> + if (!req->best_parent_rate) {
> + dev_err(pll->dev, "Did not expect best_parent_rate=0\n");
> + return -EINVAL;
> + }
> +
> + setting = zx29_pll_calc_values(pll, req->best_parent_rate, req->rate);
[Severity: Medium]
Does this code need to consider req->min_rate and req->max_rate before
calculating the new rate? The minimum and maximum boundaries passed by the
clock framework to restrict the search appear to be ignored here.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260727-zx29clk-v8-0-7a107b00f1dd@gmail.com?part=7
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Stefan Dösinger" <stefandoesinger@gmail.com>
Cc: lee@kernel.org, robh@kernel.org, mfd@lists.linux.dev,
vkoul@kernel.org, olteanv@gmail.com, neil.armstrong@linaro.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure
Date: Mon, 27 Jul 2026 19:15:13 +0000 [thread overview]
Message-ID: <20260727191513.EC7EE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727-zx29clk-v8-7-7a107b00f1dd@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] zx29_pll_determine_rate ignores the req->min_rate and req->max_rate constraints provided by the clock framework, potentially violating bounds.
--
--- Patch [7]: [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure ---
commit b2281439469368ad41cdfc2e3b1cb9178840d858
Author: Stefan Dösinger <stefandoesinger@gmail.com>
clk: zte: Add zx PLL support infrastructure
This commit introduces the ZX PLL support infrastructure for ZTE platforms,
adding rate calculation, prepare/enable operations, and registration logic.
> diff --git a/drivers/clk/zte/pll-zx.c b/drivers/clk/zte/pll-zx.c
> index f8ddb4c7dff66..6e3a20cb5839a 100644
> --- a/drivers/clk/zte/pll-zx.c
> +++ b/drivers/clk/zte/pll-zx.c
[ ... ]
> +static u32 zx29_pll_calc_values(const struct zx29_clk_pll *pll, unsigned long parent_rate,
> + unsigned long rate)
> +{
[ ... ]
> + setting = fbdiv << ZX29_PLL_FBDIV_SHIFT;
> + setting |= refdiv << ZX29_PLL_REFDIV_SHIFT;
> + setting |= i << ZX29_PLL_POSTDIV1_SHIFT;
> + setting |= j << ZX29_PLL_POSTDIV2_SHIFT;
> + out = zx29_pll_get_rate(pll, parent_rate, setting);
> +
> + if (abs_diff(out, rate) > best)
> + continue;
> +
> + if (abs_diff(out, rate) < best) {
> + postdiv1 = i;
> + postdiv2 = j;
> + best_fbdiv = fbdiv;
[Severity: Medium]
Since this loop unconditionally picks the closest hardware frequency to the
requested rate, is it possible that it selects a frequency outside of the CCF
boundaries?
If a driver sets strict constraints via clk_set_rate_range(), and the nearest
PLL approximation falls outside that range while a valid alternative exists
inside it, clk_calc_new_rates() might reject the out-of-bounds rate.
[ ... ]
> +static int zx29_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> +{
> + struct zx29_clk_pll *pll = to_zx29_clk_pll(hw);
> + unsigned long new_rate;
> + u32 setting;
> +
> + /* TODO: DPLL can switch between two parents, one of which is another PLL. Take this into
> + * account when searching the config space and set req->best_parent_rate.
> + *
> + * In practice it shouldn't matter though. Dpll is always configured to a fixed frequency
> + * and is the only clock with a switchable parent.
> + */
> + if (!req->best_parent_rate) {
> + dev_err(pll->dev, "Did not expect best_parent_rate=0\n");
> + return -EINVAL;
> + }
> +
> + setting = zx29_pll_calc_values(pll, req->best_parent_rate, req->rate);
[Severity: Medium]
Does this code need to consider req->min_rate and req->max_rate before
calculating the new rate? The minimum and maximum boundaries passed by the
clock framework to restrict the search appear to be ignored here.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260727-zx29clk-v8-0-7a107b00f1dd@gmail.com?part=7
next prev parent reply other threads:[~2026-07-27 19:15 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 18:24 [PATCH v8 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:24 ` [PATCH v8 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:32 ` sashiko-bot
2026-07-27 18:32 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:34 ` sashiko-bot
2026-07-27 18:34 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:36 ` sashiko-bot
2026-07-27 18:36 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 04/12] mfd: zx297520v3: Add a clock and reset MFD driver Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:41 ` sashiko-bot
2026-07-27 18:41 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 05/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 18:52 ` sashiko-bot
2026-07-27 18:52 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 06/12] clk: zte: Add regmap-based clocks Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:03 ` sashiko-bot
2026-07-27 19:03 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 07/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:15 ` sashiko-bot [this message]
2026-07-27 19:15 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 08/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:29 ` sashiko-bot
2026-07-27 19:29 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 09/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:41 ` sashiko-bot
2026-07-27 19:41 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 10/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:46 ` sashiko-bot
2026-07-27 19:46 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 11/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 19:59 ` sashiko-bot
2026-07-27 19:59 ` sashiko-bot
2026-07-27 18:24 ` [PATCH v8 12/12] ARM: dts: zte: Declare zx297520v3 CRM device nodes Stefan Dösinger
2026-07-27 18:24 ` Stefan Dösinger
2026-07-27 20:13 ` sashiko-bot
2026-07-27 20:13 ` sashiko-bot
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=20260727191513.EC7EE1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=mfd@lists.linux.dev \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=stefandoesinger@gmail.com \
--cc=vkoul@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.