From: sashiko-bot@kernel.org
To: "Jie Gan" <jie.gan@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 4/5] arm64: dts: qcom: sm8750: fix traceNoC probe issue
Date: Tue, 30 Jun 2026 11:19:01 +0000 [thread overview]
Message-ID: <20260630111901.B1D5C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630-fix-tracenoc-probe-issue-v3-4-7201e1841e94@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Leaked coresight trace ID on driver unbind for platform devices.
- [Medium] Unconditional free of trace ID in AMBA remove triggers WARN on unallocated IDs.
--
commit 95ddd2ab120783ca669e4302a341bf092ecf6485
Author: Jie Gan <jie.gan@oss.qualcomm.com>
arm64: dts: qcom: sm8750: fix traceNoC probe issue
The traceNoC node used the "qcom,coresight-tnoc", "arm,primecell"
compatible, which places the device on the AMBA bus. The AMBA peripheral
ID probing fails on this platform, so the device never probes.
Switch the node to the standalone "qcom,coresight-agtnoc" compatible.
Dropping "arm,primecell" makes the device probe through the platform
driver instead of the AMBA bus, which resolves the probe failure while
keeping it an Aggregator TNOC that retains ATID functionality.
> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> --- 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-agtnoc";
[Severity: High]
Does switching to the platform driver probe path introduce a trace ID leak on
device unbind?
When the device probes via the platform driver due to this compatible string
change, _tnoc_probe() calls trace_noc_init_default_data() which successfully
allocates a trace ID via coresight_trace_id_get_system_id().
However, looking at the driver's platform remove callback:
drivers/hwtracing/coresight/coresight-tnoc.c:tnoc_platform_remove() {
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
coresight_unregister(drvdata->csdev);
pm_runtime_disable(&pdev->dev);
}
The allocated system trace ID is never released via
coresight_trace_id_put_system_id(). Will this eventually exhaust the globally
limited pool of hardware trace IDs if the driver is unbound?
[Severity: Medium]
For configurations that still probe via the AMBA bus (retaining the
"arm,primecell" compatible), does the AMBA remove callback unconditionally free
unallocated trace IDs?
If a device node uses a compatible that results in atid being assigned
-EOPNOTSUPP, the _tnoc_probe() error path safely checks if (drvdata->atid > 0)
before freeing it. However, trace_noc_remove() does not:
drivers/hwtracing/coresight/coresight-tnoc.c:trace_noc_remove() {
struct trace_noc_drvdata *drvdata = dev_get_drvdata(&adev->dev);
coresight_unregister(drvdata->csdev);
coresight_trace_id_put_system_id(drvdata->atid);
}
Because coresight_trace_id_free() validates the ID and fires a kernel WARN if
it is invalid, will this trigger a warning during AMBA device unbind?
> reg = <0x0 0x109ab000 0x0 0x4200>;
>
> clocks = <&aoss_qmp>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com?part=4
next prev parent reply other threads:[~2026-06-30 11:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 10:36 [PATCH v3 0/5] Fix traceNoC probe issue on multiple QCOM platforms Jie Gan
2026-06-30 10:36 ` [PATCH v3 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible Jie Gan
2026-06-30 10:36 ` [PATCH v3 2/5] coresight: tnoc: Add AG tnoc standalone compatible to the platform driver Jie Gan
2026-06-30 10:57 ` sashiko-bot
2026-06-30 10:59 ` Jie Gan
2026-06-30 10:36 ` [PATCH v3 3/5] arm64: dts: qcom: kaanapali: fix traceNoC probe issue Jie Gan
2026-06-30 11:08 ` sashiko-bot
2026-06-30 12:53 ` Konrad Dybcio
2026-06-30 13:44 ` Jie Gan
2026-06-30 10:36 ` [PATCH v3 4/5] arm64: dts: qcom: sm8750: " Jie Gan
2026-06-30 11:19 ` sashiko-bot [this message]
2026-06-30 10:36 ` [PATCH v3 5/5] arm64: dts: qcom: glymur: use Aggregator TNOC compatible Jie Gan
2026-06-30 11:31 ` 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=20260630111901.B1D5C1F000E9@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.