Re: [PATCH v5 3/3] arm64: dts: qcom: add SoCCP DT node for Glymur

[Ananthu C V <ananthu.cv@oss.qualcomm.com>]

On Tue, Jul 07, 2026 at 10:25:35AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The 'qcom,glymur-soccp-pas' compatible string incorrectly falls back to 'qcom,kaanapali-soccp-pas', which lacks required TrustZone memory configuration.
> - [Medium] The `remoteproc_soccp` node is missing `status = "disabled";` in the base SoC `.dtsi` file.
> --
> 
> --- Patch [3]: [PATCH v5 3/3] arm64: dts: qcom: add SoCCP DT node for Glymur ---
> commit ba22e521690a1cf89042171dd1def802f653ee49
> Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> 
> arm64: dts: qcom: add SoCCP DT node for Glymur
> 
> This commit adds the device tree nodes required to enable the SoC Control
> Processor (SoCCP) on Qualcomm Glymur/Mahua SoCs.
> 
> > diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> 
> [ ... ]
> 
> > +		remoteproc_soccp: remoteproc@d00000 {
> 
> [Severity: Medium]
> Should this remoteproc node include status = "disabled"?

status = "disabled" was dropped as per suggestion from Konrad in v3.

> Any board including glymur.dtsi that does not actively use the SoCCP or
> provide firmware for it will default to status = "okay". The driver will
> attempt to load firmware and boot the remoteproc, potentially causing
> spurious driver probe errors and kernel log pollution.
> 
> > +			compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
> 
> [Severity: High]
> Is it safe to use "qcom,kaanapali-soccp-pas" as a fallback here?
>
> If an older kernel lacking the Glymur-specific match binds to this node via
> the fallback, it will use the kaanapali_soccp_resource which does not set
> .needs_tzmem = true.
> 
> Since Glymur requires TrustZone memory configuration to prevent faults, the
> Kaanapali driver cannot safely run Glymur hardware and may cause a fatal
> SMMU or TrustZone panic during remote processor boot.
> 
> > +			reg = <0x0 0x00d00000 0x0 0x200000>;

If the binding falls back to qcom,kaanapali-soccp-pas, SoCCP SSR will be broken,
but the other concerns are not applicable. And as per the current bindings, not
adding this fallback will break dtbs_check. We will address this problem in the
next re-spin.

> 
> [ ... ]
> 
> --g 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260707-glymur-soccp-v5-0-053993f0c6fe@oss.qualcomm.com?part=3