From: sashiko-bot@kernel.org
To: "Sreeshankar K" <sreeshankar0910@gmail.com>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH RESEND v11 2/5] clk: qcom: Add Global Clock Controller (GCC) driver for SM7250
Date: Thu, 29 Oct 2026 07:25:51 +0000 [thread overview]
Message-ID: <sashiko-outbox-188863@kernel.org> (raw)
In-Reply-To: <20261029-master-v11-2-2c29e382162c@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] clk: qcom: gcc-sm7250: wrong parent source and map on gcc_cpuss_ahb_clk_src
- [High] clk: qcom: gcc-sm7250: missing CLK_OPS_PARENT_ENABLE on gcc_sdcc2_apps_clk_src
- [High] clk: qcom: gcc-sm7250: mark gcc_cpuss_gnoc_clk critical to prevent gating
--
commit df02ee88c50cbe124252b368c43513c346759f86
Author: Sreeshankar K <sreeshankar0910@gmail.com>
clk: qcom: Add Global Clock Controller (GCC) driver for SM7250
This commit adds the Global Clock Controller (GCC) driver for Qualcomm SM7250
SoC devices, registering PLLs, RCGs, branch clocks, GDSCs, and resets.
> diff --git a/drivers/clk/qcom/gcc-sm7250.c b/drivers/clk/qcom/gcc-sm7250.c
> new file mode 100644
> index 0000000000000..e4304c667dace
> --- /dev/null
> +++ b/drivers/clk/qcom/gcc-sm7250.c
> @@ -0,0 +1,2286 @@
[ ... ]
> +enum {
> + DT_BI_TCXO,
> + DT_BI_TCXO_AO,
> + DT_SLEEP_CLK,
> +};
> +
> +enum {
> + P_BI_TCXO,
> + P_GPLL0_OUT_EVEN,
> + P_GPLL0_OUT_MAIN,
> + P_GPLL6_OUT_MAIN,
> + P_GPLL9_OUT_MAIN,
> + P_SLEEP_CLK,
> +};
[ ... ]
> +static const struct parent_map gcc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> + { P_GPLL0_OUT_MAIN, 1 },
> + { P_GPLL0_OUT_EVEN, 6 },
> +};
> +
> +static const struct clk_parent_data gcc_parent_data_0[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &gpll0.clkr.hw },
> + { .hw = &gpll0_out_even.clkr.hw },
> +};
> +
> +static const struct clk_parent_data gcc_parent_data_0_ao[] = {
> + { .index = DT_BI_TCXO_AO },
> +};
[ ... ]
> +static const struct freq_tbl ftbl_gcc_cpuss_ahb_clk_src[] = {
> + F(19200000, DT_BI_TCXO_AO, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 gcc_cpuss_ahb_clk_src = {
> + .cmd_rcgr = 0x48010,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = gcc_parent_map_0,
> + .freq_tbl = ftbl_gcc_cpuss_ahb_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data){
> + .name = "gcc_cpuss_ahb_clk_src",
> + .parent_data = gcc_parent_data_0_ao,
> + .num_parents = ARRAY_SIZE(gcc_parent_data_0_ao),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_ops,
> + },
> +};
[Severity: High]
In drivers/clk/qcom/gcc-sm7250.c, ftbl_gcc_cpuss_ahb_clk_src passes
DT_BI_TCXO_AO (which is 1 in the DT clock index enum) instead of P_BI_TCXO
(which is 0 in the parent source enum) as the source argument to F().
In addition, gcc_cpuss_ahb_clk_src pairs the 3-entry gcc_parent_map_0 with
gcc_parent_data_0_ao, which only defines 1 entry.
When clk_rcg2_determine_rate() or clk_rcg2_set_rate() runs on
gcc_cpuss_ahb_clk_src, it calls qcom_find_src_index() in
drivers/clk/qcom/common.c:
int qcom_find_src_index(struct clk_hw *hw, const struct parent_map *map, u8 src)
{
int i, num_parents = clk_hw_get_num_parents(hw);
for (i = 0; i < num_parents; i++)
if (src == map[i].src)
return i;
return -ENOENT;
}
Because num_parents is 1 and map[0].src is P_BI_TCXO (0), passing
src = DT_BI_TCXO_AO (1) causes qcom_find_src_index() to return -ENOENT.
Furthermore, with only 1 entry in gcc_parent_data_0_ao,
__clk_rcg2_get_parent() cannot resolve gpll0 or gpll0_out_even if selected in
hardware, and if gcc_parent_data_0_ao is expanded to 3 entries,
DT_BI_TCXO_AO (1) collides with P_GPLL0_OUT_EVEN (1).
Should ftbl_gcc_cpuss_ahb_clk_src use P_BI_TCXO, and should
gcc_parent_data_0_ao either include the remaining parents from
gcc_parent_data_0 or use a matching single-entry parent_map?
[ ... ]
> +static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
> + F(400000, P_BI_TCXO, 12, 1, 4),
> + F(19200000, P_BI_TCXO, 1, 0, 0),
> + F(25000000, P_GPLL0_OUT_EVEN, 6, 1, 2),
> + F(50000000, P_GPLL0_OUT_EVEN, 6, 0, 0),
> + F(100000000, P_GPLL0_OUT_EVEN, 3, 0, 0),
> + F(202000000, P_GPLL9_OUT_MAIN, 4, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 gcc_sdcc2_apps_clk_src = {
> + .cmd_rcgr = 0x1400c,
> + .mnd_width = 8,
> + .hid_width = 5,
> + .parent_map = gcc_parent_map_4,
> + .freq_tbl = ftbl_gcc_sdcc2_apps_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data){
> + .name = "gcc_sdcc2_apps_clk_src",
> + .parent_data = gcc_parent_data_4,
> + .num_parents = ARRAY_SIZE(gcc_parent_data_4),
> + .ops = &clk_rcg2_floor_ops,
> + },
> +};
[Severity: High]
In drivers/clk/qcom/gcc-sm7250.c, ftbl_gcc_sdcc2_apps_clk_src uses
P_GPLL9_OUT_MAIN (gpll9) for the 202 MHz entry. Unlike gpll0, gpll9 is only
used by gcc_sdcc2_apps_clk_src and is not enabled by default.
Because gcc_sdcc2_apps_clk_src uses clk_rcg2_floor_ops without setting
CLK_OPS_PARENT_ENABLE in its flags (unlike gcc_sdcc1_apps_clk_src with gpll6),
calling clk_set_rate() on gcc_sdcc2_apps_clk to or from 202 MHz while the
clock is unprepared or disabled will invoke update_config() in
drivers/clk/qcom/clk-rcg2.c while gpll9 is off.
Wouldn't that cause the RCG update handshake to time out with a warning and
return -EBUSY unless CLK_OPS_PARENT_ENABLE is set on gcc_sdcc2_apps_clk_src?
[ ... ]
> +static struct clk_branch gcc_cpuss_gnoc_clk = {
> + .halt_reg = 0x48064,
> + .halt_check = BRANCH_HALT_VOTED,
> + .clkr = {
> + .enable_reg = 0x52000,
> + .enable_mask = BIT(29),
> + .hw.init = &(const struct clk_init_data){
> + .name = "gcc_cpuss_gnoc_clk",
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
[ ... ]
> +static struct clk_regmap *gcc_sm7250_clocks[] = {
> + [GCC_AGGRE_UFS_PHY_AXI_CLK] = &gcc_aggre_ufs_phy_axi_clk.clkr,
> + [GCC_AGGRE_USB3_PRIM_AXI_CLK] = &gcc_aggre_usb3_prim_axi_clk.clkr,
> + [GCC_BOOT_ROM_AHB_CLK] = &gcc_boot_rom_ahb_clk.clkr,
> + [GCC_CAMERA_HF_AXI_CLK] = &gcc_camera_hf_axi_clk.clkr,
> + [GCC_CAMERA_SF_AXI_CLK] = &gcc_camera_sf_axi_clk.clkr,
> + [GCC_CFG_NOC_USB3_PRIM_AXI_CLK] = &gcc_cfg_noc_usb3_prim_axi_clk.clkr,
> + [GCC_CPUSS_AHB_CLK_SRC] = &gcc_cpuss_ahb_clk_src.clkr,
> + [GCC_CPUSS_GNOC_CLK] = &gcc_cpuss_gnoc_clk.clkr,
[ ... ]
> +static void gcc_sm7250_clk_regs_configure(struct device *dev, struct regmap *regmap)
> +{
> + /*
> + * Disable the GPLL0 active input to NPU and GPU
> + * via MISC registers.
> + */
> + regmap_update_bits(regmap, 0x4d110, 0x3, 0x3);
> + regmap_update_bits(regmap, 0x71028, 0x3, 0x3);
> +
> + /*
> + * Critical clocks sharing the same register with
> + * different masks
> + */
> + regmap_update_bits(regmap, 0x52000, BIT(21), BIT(21)); /* GCC_CPUSS_AHB_CLK */
> +}
[Severity: High]
In drivers/clk/qcom/gcc-sm7250.c, gcc_cpuss_gnoc_clk is registered in
gcc_sm7250_clocks[] with clk_branch2_ops and without CLK_IS_CRITICAL.
When clk_disable_unused() runs at late_initcall_sync and no consumer has
claimed GCC_CPUSS_GNOC_CLK, clk_disable_unused_subtree() will call
clk_branch2_disable() -> clk_disable_regmap() and clear BIT(29) in vote
register 0x52000, gating the CPU subsystem to GNOC interconnect clock and
hanging the system.
Should gcc_cpuss_gnoc_clk be marked with CLK_IS_CRITICAL (or handled via
gcc_sm7250_clk_regs_configure() like GCC_CPUSS_AHB_CLK in register 0x52000) so
that it is not disabled at boot?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-master-v11-0-2c29e382162c@gmail.com?part=2
next prev parent reply other threads:[~2026-10-29 7:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 7:02 [PATCH RESEND v11 0/5] Add initial support for Qualcomm SM7250 SoC Sreeshankar K
2026-10-29 7:02 ` [PATCH RESEND v11 1/5] dt-bindings: clock: Add SM7250 global clock controller Sreeshankar K
2026-10-29 7:02 ` [PATCH RESEND v11 2/5] clk: qcom: Add Global Clock Controller (GCC) driver for SM7250 Sreeshankar K
2026-10-29 7:25 ` sashiko-bot [this message]
2026-10-29 7:03 ` [PATCH RESEND v11 3/5] dt-bindings: firmware: qcom,scm: Document SM7250 SCM Sreeshankar K
2026-10-29 7:03 ` [PATCH RESEND v11 4/5] dt-bindings: cpufreq: qcom-hw: Document SM7250 cpufreq hardware Sreeshankar K
2026-10-29 7:11 ` sashiko-bot
2026-10-29 7:03 ` [PATCH RESEND v11 5/5] arm64: dts: qcom: Add SM7250 devicetree file Sreeshankar K
2026-10-29 7:26 ` 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=sashiko-outbox-188863@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sreeshankar0910@gmail.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