From: sashiko-bot@kernel.org
To: "Yu-Chun Lin" <eleanor.lin@realtek.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v11 05/11] clk: realtek: Add support for phase locked loops (PLLs)
Date: Tue, 28 Jul 2026 14:41:19 +0000 [thread overview]
Message-ID: <20260728144120.402091F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728142806.1954638-6-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] `rtk_clk_regmap_pll_enable()` skips the hardware readiness check (`wait_freq_ready`) if the PLL is already powered on, breaking error recovery and trusting potentially unready hardware.
- [Medium] `spinlock_t lock` in `struct rtk_clk_regmap_pll` is defined but lacks an initialization API, leading to potential kernel panics.
--
--- Patch [5]: [PATCH v11 05/11] clk: realtek: Add support for phase locked loops (PLLs) ---
commit 6b0f9bf0f933b92885502feb8287d2125013ada0
Author: Cheng-Yu Lee <cylee12@realtek.com>
clk: realtek: Add support for phase locked loops (PLLs)
Provide a full set of PLL operations for programmable PLLs and a read-only
variant for fixed or hardware-managed PLLs.
> diff --git a/drivers/clk/realtek/clk-pll.c b/drivers/clk/realtek/clk-pll.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/clk/realtek/clk-pll.c
[ ... ]
> +static int rtk_clk_regmap_pll_enable(struct clk_hw *hw)
> +{
> + struct rtk_clk_regmap_pll *clkp = to_rtk_clk_regmap_pll(hw);
> + unsigned long flags;
> + int ret = 0;
> +
> + if (!clkp->seq_power_on)
> + return ret;
> +
> + spin_lock_irqsave(&clkp->lock, flags);
> +
> + if (is_power_on(clkp))
> + goto unlock;
[Severity: High]
If the PLL is already powered on (or if power_reg is 0 and is_power_on()
defaults to true), does this skip verifying if the clock is actually locked?
If a previous enable attempt timed out in wait_freq_ready(), a subsequent
retry would see it powered on and return success here without ensuring the
hardware is ready. Could this lead to consumer peripherals operating with
an unstable or missing clock?
> +
> + ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_power_on,
> + clkp->num_seq_power_on);
> + if (ret)
> + goto unlock;
> +
> + ret = wait_freq_ready(clkp);
> + if (ret)
> + goto unlock;
> +
> +unlock:
> + spin_unlock_irqrestore(&clkp->lock, flags);
> +
> + return ret;
> +}
[ ... ]
> diff --git a/drivers/clk/realtek/clk-pll.h b/drivers/clk/realtek/clk-pll.h
> new file mode 100644
> --- /dev/null
> +++ b/drivers/clk/realtek/clk-pll.h
[ ... ]
> +struct rtk_clk_regmap_pll {
> + struct rtk_clk_regmap clkr;
> + const struct reg_sequence *seq_power_on;
> + u32 num_seq_power_on;
[ ... ]
> + u32 power_reg;
> + u32 power_mask;
> + u32 power_val_on;
> +
> + /* This lock prevents race conditions when multiple CPUs or contexts
> + * simultaneously access this PLL's registers during multi-step operations
> + */
> + spinlock_t lock;
[Severity: Medium]
Is there a missing helper macro or function to initialize this lock?
Since consumer drivers instantiate struct rtk_clk_regmap_pll, if they do not
manually initialize this lock using spin_lock_init(), could calls to
spin_lock_irqsave() in functions like rtk_clk_regmap_pll_recalc_rate()
trigger a kernel panic when CONFIG_DEBUG_SPINLOCK is enabled?
> +};
> +
> +#define __rtk_clk_regmap_pll_hw(_ptr) __rtk_clk_regmap_hw(&(_ptr)->clkr)
> +
> +extern const struct clk_ops rtk_clk_pll_ops;
> +extern const struct clk_ops rtk_clk_pll_ro_ops;
> +
> +#endif /* __CLK_REALTEK_CLK_PLL_H */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260728142806.1954638-1-eleanor.lin@realtek.com?part=5
next prev parent reply other threads:[~2026-07-28 14:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 14:27 [PATCH v11 00/11] clk / reset: realtek: Add RTD1625 clock and reset support Yu-Chun Lin
2026-07-28 14:27 ` [PATCH v11 01/11] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller Yu-Chun Lin
2026-07-28 14:27 ` [PATCH v11 02/11] reset: Add Realtek basic reset support Yu-Chun Lin
2026-07-28 14:27 ` [PATCH v11 03/11] reset: realtek: Add RTD1625 reset controller driver Yu-Chun Lin
2026-07-28 14:51 ` sashiko-bot
2026-07-28 14:27 ` [PATCH v11 04/11] clk: realtek: Introduce a common probe() Yu-Chun Lin
2026-07-28 14:41 ` sashiko-bot
2026-07-28 14:28 ` [PATCH v11 05/11] clk: realtek: Add support for phase locked loops (PLLs) Yu-Chun Lin
2026-07-28 14:41 ` sashiko-bot [this message]
2026-07-28 14:28 ` [PATCH v11 06/11] clk: realtek: Add support for gate clock Yu-Chun Lin
2026-07-28 14:28 ` [PATCH v11 07/11] clk: realtek: Add support for mux clock Yu-Chun Lin
2026-07-28 14:28 ` [PATCH v11 08/11] clk: realtek: Add support for MMC-tuned PLL clocks Yu-Chun Lin
2026-07-28 14:40 ` sashiko-bot
2026-07-28 14:28 ` [PATCH v11 09/11] clk: realtek: Add RTD1625-CRT clock controller driver Yu-Chun Lin
2026-07-28 14:28 ` [PATCH v11 10/11] clk: realtek: Add RTD1625-ISO " Yu-Chun Lin
2026-07-28 14:28 ` [PATCH v11 11/11] arm64: dts: realtek: Add clock support for RTD1625 Yu-Chun Lin
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=20260728144120.402091F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=eleanor.lin@realtek.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.