All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Qiang Yu" <qiang.yu@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
Date: Mon, 22 Jun 2026 05:21:13 +0000	[thread overview]
Message-ID: <20260622052114.395061F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260621-tcsr_qref_0622-v6-5-c939c22ded0c@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing regulator specifications for non-PCIe clocks (EDP, USB) in Mahua TCSR descriptors
--

commit 6c7380c66661cd5b69976b7e56fdb61f281c6291
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>

clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support

This commit adds Mahua-specific regulator arrays and clock descriptor tables
for PCIe clock references. It uses match_data to select the correct descriptor
table based on the compatible string during probe.

> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> index 2db039342f300..9af520b71f315 100644
> --- a/drivers/clk/qcom/tcsrcc-glymur.c
> +++ b/drivers/clk/qcom/tcsrcc-glymur.c
[ ... ]
> +static const struct qcom_clk_ref_desc tcsr_cc_mahua_clk_descs[] = {
> +	[TCSR_EDP_CLKREF_EN] = {
> +		.name = "tcsr_edp_clkref_en",
> +		.offset = 0x60,
> +	},
> +	[TCSR_PCIE_2_CLKREF_EN] = {
> +		.name = "tcsr_pcie_2_clkref_en",
> +		.offset = 0x4c,
> +		.regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> +		.num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
> +	},
[ ... ]
> +	[TCSR_USB4_1_CLKREF_EN] = {
> +		.name = "tcsr_usb4_1_clkref_en",
> +		.offset = 0x44,
> +	},
> +	[TCSR_USB4_2_CLKREF_EN] = {
> +		.name = "tcsr_usb4_2_clkref_en",
> +		.offset = 0x5c,
> +	},
> +};

[Severity: High]
Do we need regulator specifications for the non-PCIe clocks (EDP, USB2, USB3,
USB4) in this descriptor table?

Since this array only populates regulator_names for the PCIe clocks, the
non-PCIe entries are left with 0 regulators.

When the USB or eDP PHY drivers call clk_prepare_enable() on their clkrefs,
will qcom_clk_ref_prepare() just set the hardware register bit and silently
skip voting for the required LDOs?

If so, does this leave the QREF block unpowered for these peripherals and
prevent the PHYs from initializing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com?part=5

  reply	other threads:[~2026-06-22  5:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22  5:11 [PATCH v6 0/8] clk: qcom: Add common clkref support and migrate Glymur and Mahua Qiang Yu
2026-06-22  5:11 ` [PATCH v6 1/8] dt-bindings: clock: qcom: Move glymur TCSR to own binding Qiang Yu
2026-06-22  5:18   ` sashiko-bot
2026-06-22  7:30     ` Krzysztof Kozlowski
2026-06-22  7:29   ` Krzysztof Kozlowski
2026-06-22  5:11 ` [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support Qiang Yu
2026-06-22  5:16   ` sashiko-bot
2026-06-22  7:32   ` Krzysztof Kozlowski
2026-06-22  9:51     ` Qiang Yu
2026-06-22  5:11 ` [PATCH v6 3/8] clk: qcom: Add generic clkref_en support Qiang Yu
2026-06-22  5:24   ` sashiko-bot
2026-06-22 12:13   ` Konrad Dybcio
2026-06-22 12:36     ` Qiang Yu
2026-06-22  5:11 ` [PATCH v6 4/8] clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper Qiang Yu
2026-06-22  5:11 ` [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support Qiang Yu
2026-06-22  5:21   ` sashiko-bot [this message]
2026-06-22 11:35   ` Konrad Dybcio
2026-06-22  5:11 ` [PATCH v6 6/8] arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR Qiang Yu
2026-06-22  5:21   ` sashiko-bot
2026-06-22 12:16   ` Konrad Dybcio
2026-06-22  5:11 ` [PATCH v6 7/8] arm64: dts: qcom: mahua: " Qiang Yu
2026-06-22  5:22   ` sashiko-bot
2026-06-22 12:18   ` Konrad Dybcio
2026-06-22  5:11 ` [PATCH v6 8/8] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK Qiang Yu
2026-06-22 11:37   ` Konrad Dybcio

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=20260622052114.395061F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=qiang.yu@oss.qualcomm.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.