Re: [PATCH RESEND v7 05/10] arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes

Thank you for your contribution! Sashiko AI review found 3 potential issue(=
s) to consider:
- [Medium] Both `remoteproc_mpss` and `remoteproc_cdsp` incorrectly use `MA=
STER_AMPSS_M0` (the Application Processor) as the source master for their i=
nterconnect paths.
- [Low] The `remoteproc_lpaicp` node configures its `smp2p_in` interrupts w=
ith `IRQ_TYPE_NONE` instead of `IRQ_TYPE_EDGE_RISING`.
- [Low] The `power-domains` property for `remoteproc_mpss` and `remoteproc_=
cdsp` uses the undefined macro `RPMHPD_CX`.
--

--- Patch [5]: [PATCH RESEND v7 05/10] arm64: dts: qcom: shikra: Add CDSP, =
LPAICP, MPSS remoteproc PAS nodes ---
commit d887c029e52194e73c0d6673eaad6485dc1a7361
Author: Bibek Kumar Patro <[email protected]>

arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes
   =20
Add nodes for remoteproc PAS loader for CDSP, LPAICP, MPSS subsystem.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/q=
com/shikra.dtsi
> index 42a17ffc040f8..570505c927bb3 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -1813,6 +1813,170 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
>  			};
>  		};
> =20
> +		remoteproc_mpss: remoteproc@6080000 {
[ ... ]
> +			clocks =3D <&rpmcc RPM_SMD_XO_CLK_SRC>;
> +			clock-names =3D "xo";
> +
> +			interconnects =3D <&mem_noc MASTER_AMPSS_M0 RPM_ALWAYS_TAG
> +					 &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;

[Severity: Medium]
Does this interconnect path incorrectly use the CPU's master endpoint for t=
he
modem DSP?=20

Voting for bandwidth using MASTER_AMPSS_M0 inflates the CPU's memory bandwi=
dth
requirements and fails to configure the actual hardware path the DSP uses to
access memory.

> +
> +			power-domains =3D <&rpmpd RPMHPD_CX>;

[Severity: Low]
Is this the correct macro for the older SMD RPM power controller?=20

It looks like RPMHPD_CX belongs to the RPMh header, which causes a dtc
compilation syntax error when left unresolved by the preprocessor.

> +
> +			memory-region =3D <&mpss_wlan_mem>;
[ ... ]
> +		remoteproc_cdsp: remoteproc@b300000 {
[ ... ]
> +			clocks =3D <&rpmcc RPM_SMD_XO_CLK_SRC>;
> +			clock-names =3D "xo";
> +
> +			interconnects =3D <&mem_noc MASTER_AMPSS_M0 RPM_ALWAYS_TAG
> +					 &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;

[Severity: Medium]
Should this interconnect path use the compute DSP hardware path instead of =
the
application processor master (MASTER_AMPSS_M0)?

> +
> +			power-domains =3D <&rpmpd RPMHPD_CX>;

[Severity: Low]
Is it intentional to use the unresolved RPMHPD_CX macro here?=20

This produces a build error because it belongs to the unincluded RPMh header
rather than the older SMD RPM bindings.

> +
> +			memory-region =3D <&cdsp_mem>;
[ ... ]
> +		remoteproc_lpaicp: remoteproc@b800000 {
> +			compatible =3D "qcom,shikra-lpaicp-pas";
> +			reg =3D <0x0 0x0b800000 0x0 0x200000>;
> +
> +			interrupts-extended =3D <&intc GIC_SPI 257 IRQ_TYPE_EDGE_RISING 0>,
> +					      <&lmcu_smp2p_in 0 IRQ_TYPE_NONE>,
> +					      <&lmcu_smp2p_in 1 IRQ_TYPE_NONE>,
> +					      <&lmcu_smp2p_in 2 IRQ_TYPE_NONE>,
> +					      <&lmcu_smp2p_in 3 IRQ_TYPE_NONE>;

[Severity: Low]
Does this configuration incorrectly define the trigger type for the SMP2P
interrupts?=20

The smp2p inbound interrupts represent software-triggered edges, so using
IRQ_TYPE_NONE instead of an edge trigger violates the binding expectations.
Even though the driver happens to mask the failure by explicitly passing
IRQF_TRIGGER_RISING, the Device Tree configuration appears factually
incorrect.

> +
> +			interrupt-names =3D "wdog",
[ ... ]

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803-shikra-dt-=
[email protected]?part=3D5