From: sashiko-bot@kernel.org
To: "Imran Shaik" <imran.shaik@oss.qualcomm.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 1/4] clk: qcom: common: Register reset controller only when resets are present
Date: Thu, 23 Jul 2026 15:55:14 +0000 [thread overview]
Message-ID: <20260723155515.68A0E1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260723-shikra-audiocorecc-v3-1-90b878ae0d4e@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The local pointer `reset` is used uninitialized when registering GDSCs if the clock controller defines GDSCs but no resets.
--
--- Patch [1]: [PATCH v3 1/4] clk: qcom: common: Register reset controller only when resets are present ---
commit 4dacf2df1c1e317705833daaa92c7514eab60f24
Author: Imran Shaik <imran.shaik@oss.qualcomm.com>
clk: qcom: common: Register reset controller only when resets are present
This commit avoids registering a reset controller if the clock controller
descriptor does not define any resets. It does this by checking if
desc->num_resets is non-zero before initializing and registering the
controller.
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
[ ... ]
> @@ -359,17 +359,19 @@ int qcom_cc_really_probe(struct device *dev,
> qcom_cc_clk_regs_configure(dev, desc->driver_data, regmap);
> }
>
> - reset = &cc->reset;
> - reset->rcdev.of_node = dev->of_node;
> - reset->rcdev.ops = &qcom_reset_ops;
> - reset->rcdev.owner = dev->driver->owner;
> - reset->rcdev.nr_resets = desc->num_resets;
> - reset->regmap = regmap;
> - reset->reset_map = desc->resets;
> -
> - ret = devm_reset_controller_register(dev, &reset->rcdev);
> - if (ret)
> - goto put_rpm;
> + if (desc->num_resets) {
> + reset = &cc->reset;
> + reset->rcdev.of_node = dev->of_node;
> + reset->rcdev.ops = &qcom_reset_ops;
> + reset->rcdev.owner = dev->driver->owner;
> + reset->rcdev.nr_resets = desc->num_resets;
> + reset->regmap = regmap;
> + reset->reset_map = desc->resets;
> +
> + ret = devm_reset_controller_register(dev, &reset->rcdev);
> + if (ret)
> + goto put_rpm;
> + }
>
> if (desc->gdscs && desc->num_gdscs) {
> scd = devm_kzalloc(dev, sizeof(*scd), GFP_KERNEL);
> if (!scd) {
> ret = -ENOMEM;
> goto put_rpm;
> }
> scd->dev = dev;
> scd->scs = desc->gdscs;
> scd->num = desc->num_gdscs;
> scd->pd_list = cc->pd_list;
> ret = gdsc_register(scd, &reset->rcdev, regmap);
[Severity: High]
If a clock controller defines GDSCs but no resets, does this leave the reset
pointer uninitialized when evaluated here?
During qcom_cc_really_probe(), the new if (desc->num_resets) block skips the
initialization of the reset pointer when the clock controller has no resets
defined.
However, the pointer arithmetic &reset->rcdev is still evaluated when
calling gdsc_register(). Passing this uninitialized garbage address could invoke
undefined behavior and cause a panic during boot when compiler hardening tools
are enabled.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-shikra-audiocorecc-v3-0-90b878ae0d4e@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-07-23 15:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 15:45 [PATCH v3 0/4] clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC Imran Shaik
2026-07-23 15:45 ` [PATCH v3 1/4] clk: qcom: common: Register reset controller only when resets are present Imran Shaik
2026-07-23 15:55 ` sashiko-bot [this message]
2026-07-24 7:42 ` Imran Shaik
2026-07-24 10:49 ` Philipp Zabel
2026-07-24 11:00 ` Imran Shaik
2026-07-23 15:45 ` [PATCH v3 2/4] dt-bindings: clock: qcom: Add Qualcomm Shikra AudioCoreCC and AudioCoreCSR Imran Shaik
2026-07-24 6:35 ` Krzysztof Kozlowski
2026-07-23 15:45 ` [PATCH v3 3/4] clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC Imran Shaik
2026-07-23 16:14 ` sashiko-bot
2026-07-24 7:45 ` Imran Shaik
2026-07-24 10:34 ` Uwe Kleine-König
2026-07-24 11:02 ` Imran Shaik
2026-07-23 15:45 ` [PATCH v3 4/4] arm64: dts: qcom: shikra: Add support for AudioCoreCC and AudioCoreCSR nodes Imran Shaik
2026-07-23 16:25 ` sashiko-bot
2026-07-24 8:03 ` 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=20260723155515.68A0E1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imran.shaik@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.