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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Both `remoteproc_mpss` and `remoteproc_cdsp` incorrectly use `MASTER_AMPSS_M0` (the Application Processor) as the source master for their interconnect paths.
- [Low] The `remoteproc_lpaicp` node configures its `smp2p_in` interrupts with `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 <bibek.patro@oss.qualcomm.com>

arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes
    
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/qcom/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>,
>  			};
>  		};
>  
> +		remoteproc_mpss: remoteproc@6080000 {
[ ... ]
> +			clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
> +			clock-names = "xo";
> +
> +			interconnects = <&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 the
modem DSP? 

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

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

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

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 = <&mpss_wlan_mem>;
[ ... ]
> +		remoteproc_cdsp: remoteproc@b300000 {
[ ... ]
> +			clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
> +			clock-names = "xo";
> +
> +			interconnects = <&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 = <&rpmpd RPMHPD_CX>;

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

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

> +
> +			memory-region = <&cdsp_mem>;
[ ... ]
> +		remoteproc_lpaicp: remoteproc@b800000 {
> +			compatible = "qcom,shikra-lpaicp-pas";
> +			reg = <0x0 0x0b800000 0x0 0x200000>;
> +
> +			interrupts-extended = <&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? 

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 = "wdog",
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-shikra-dt-m1-v7-0-7fec8e777076@oss.qualcomm.com?part=5