Re: [PATCH] arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] arm64: dts: qcom: unresolved remoteproc_soccp target in
  nord-embedded-el2.dtso
- [High] arm64: dts: qcom: remoteproc_adsp iommus conflicts with
  early_boot attach
- [Medium] arm64: dts: qcom: remoteproc_soccp iommus exceeds PAS binding
  maxItems
--

commit 7c3911549648c2c9a04bb237b67646f8107b1680
Author: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>

arm64: dts: qcom: nord: Add EL2 overlay for remoteproc SMMU mappings

This commit adds the nord-embedded-el2.dtso overlay to define IOMMU
streams for the ADSP, CDSP, and SoCCP remoteprocs when booting Nord
boards at EL2, and builds -el2.dtb variants for nord-ride-embedded and
nord-rrd.

> diff --git a/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
> new file mode 100644
> index 0000000000000..50c5057f6683a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/nord-embedded-el2.dtso
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&remoteproc_adsp {
> +	iommus = <&apps_smmu_0 0x09e0 0x0>;
> +};

[Severity: High]
Does adding iommus to remoteproc_adsp break ADSP bringup when booting at
EL2?

In drivers/remoteproc/qcom_q6v5_pas.c, nord_adsp_resource sets
.early_boot = true, so qcom_pas_probe() sets pas->rproc->state to
RPROC_DETACHED and rproc_boot() calls rproc_attach() instead of
rproc_fw_boot().  Because rproc->has_iommu is now true, rproc_attach() ->
rproc_enable_iommu() attaches an empty IOMMU paging domain to stream
0x09e0, while qcom_pas_attach() never calls qcom_pas_map_carveout(),
causing immediate SMMU translation faults if the bootloader started ADSP.
If ADSP was not pre-started, qcom_pas_attach() resets state to
RPROC_OFFLINE and returns -EINVAL, and rproc_boot() exits without falling
back to rproc_fw_boot().

> +
> +&remoteproc_cdsp0 {
> +	iommus = <&apps_smmu_2 0x0360 0x0>;
> +};
> +
> +&remoteproc_cdsp1 {
> +	iommus = <&apps_smmu_2 0x0760 0x0>;
> +};
> +
> +&remoteproc_cdsp2 {
> +	iommus = <&apps_smmu_2 0x0b60 0x0>;
> +};
> +
> +&remoteproc_cdsp3 {
> +	iommus = <&apps_smmu_2 0x0f60 0x0>;
> +};
> +
> +&remoteproc_soccp {
> +	iommus = <&apps_smmu_0 0x1960 0x5>,
> +		 <&apps_smmu_0 0x1966 0x0>;
> +};

[Severity: High]
Does targeting &remoteproc_soccp break the dtbs build when
CONFIG_ARCH_QCOM is enabled?

Neither nord.dtsi, nord-embedded.dtsi, nord-ride-embedded.dts, nor
nord-rrd.dts defines a remoteproc_soccp label yet.  When Makefile builds
nord-ride-embedded-el2.dtb and nord-rrd-el2.dtb, fdtoverlay fails in
overlay_fixup_phandle() with -FDT_ERR_NOTFOUND because remoteproc_soccp
is missing from /__symbols__ in the base DTBs.

[Severity: Medium]
Does specifying two iommus entries on remoteproc_soccp violate the PAS
Devicetree binding and driver expectations?

Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
restricts iommus to maxItems: 1, which causes dtbs_check to fail.  In
addition, qcom_q6v5_pas has no Nord SoCCP match entry yet, and
qcom_pas_map_carveout() maps carveouts with IOMMU_READ | IOMMU_WRITE
without the IOMMU_PRIV flag needed for the privileged SoCCP stream.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-nord_soccp_el2_dt_change-v1-1-2a7aa55d97dd@oss.qualcomm.com?part=1