All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jie Gan" <jie.gan@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v5 4/5] arm64: dts: qcom: sm8750: fix traceNoC probe issue
Date: Tue, 07 Jul 2026 09:30:45 +0000	[thread overview]
Message-ID: <20260707093046.3D7C01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707-fix-tracenoc-probe-issue-v5-4-bf733ed9ebd0@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Switching the traceNoC device from the AMBA bus to the platform bus actively exposes a PM runtime / devres clock unbalance bug that triggers kernel WARNINGs on device unbind.
--

--- Patch [4]: [PATCH v5 4/5] arm64: dts: qcom: sm8750: fix traceNoC probe issue ---
commit 614093568676102a83b2efb2ba08c1718071ad73
Author: Jie Gan <jie.gan@oss.qualcomm.com>

arm64: dts: qcom: sm8750: fix traceNoC probe issue

This patch drops the "arm,primecell" compatible string from the traceNoC
node to prevent indefinite probe deferral. By using only the standalone
"qcom,coresight-tnoc" compatible, the device binds via the platform
bus instead of the AMBA bus, bypassing the primecell ID check.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> index fafed417c66fc..1e25be41aef5c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> @@ -4687,7 +4687,7 @@ tpdm_rdpm_cmb2_out: endpoint {
>  		};
>  
>  		tn@109ab000 {
> -			compatible = "qcom,coresight-tnoc", "arm,primecell";
> +			compatible = "qcom,coresight-tnoc";

[Severity: High]
This isn't a bug introduced by this patch, but does changing this to a
platform device expose a clock management unbalance during driver unbind?

When bound as a platform device, tnoc_platform_probe() acquires the clock
via devm_clk_get_optional_enabled() in coresight_get_enable_clocks(). This
queues a devres action to automatically disable the clock upon unbind.

If the device enters runtime suspend, tnoc_runtime_suspend() manually
disables this same clock:

drivers/hwtracing/coresight/coresight-tnoc.c:tnoc_runtime_suspend() {
    ...
    clk_disable_unprepare(drvdata->pclk);
    ...
}

Unlike the AMBA bus framework which automatically wakes devices during
removal, tnoc_platform_remove() does not call pm_runtime_get_sync() before
disabling runtime PM.

If the driver is unbound while suspended, the device stays suspended and the
clock remains disabled. Once tnoc_platform_remove() returns, the devres
unwind process executes the cleanup action, calling clk_disable_unprepare()
a second time.

Will this sequence trigger kernel warnings in clk_core_disable() and
clk_core_unprepare() due to the counts already being zero?

>  			reg = <0x0 0x109ab000 0x0 0x4200>;
>  
>  			clocks = <&aoss_qmp>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-fix-tracenoc-probe-issue-v5-0-bf733ed9ebd0@oss.qualcomm.com?part=4

  reply	other threads:[~2026-07-07  9:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  9:08 [PATCH v5 0/5] Fix traceNoC probe issue on multiple QCOM platforms Jie Gan
2026-07-07  9:08 ` [PATCH v5 1/5] dt-bindings: arm: coresight-tnoc: Drop arm,primecell to bind on platform bus Jie Gan
2026-07-07  9:22   ` sashiko-bot
2026-07-09  7:59   ` Krzysztof Kozlowski
2026-07-09  8:34     ` Jie Gan
2026-07-09  8:46       ` Krzysztof Kozlowski
2026-07-09  9:02         ` Jie Gan
2026-07-09  9:17           ` Krzysztof Kozlowski
2026-07-07  9:08 ` [PATCH v5 2/5] coresight: tnoc: Bind Aggregator TNOC on the " Jie Gan
2026-07-07  9:22   ` sashiko-bot
2026-07-07  9:08 ` [PATCH v5 3/5] arm64: dts: qcom: kaanapali: fix traceNoC probe issue Jie Gan
2026-07-07  9:21   ` sashiko-bot
2026-07-07  9:08 ` [PATCH v5 4/5] arm64: dts: qcom: sm8750: " Jie Gan
2026-07-07  9:30   ` sashiko-bot [this message]
2026-07-07  9:08 ` [PATCH v5 5/5] arm64: dts: qcom: glymur: use Aggregator TNOC compatible Jie Gan

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=20260707093046.3D7C01F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jie.gan@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.