Re: [PATCH 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 2 potential issue(s) to consider:
- [Low] Incorrect IRQ type `IRQ_TYPE_NONE` specified for SMP2P interrupts in `remoteproc_lpaicp` node.
- [Low] Semantic API Violation: Usage of RPMh macro `RPMHPD_CX` with an RPM SMD power controller (`rpmpd`).
--

--- Patch [5]: [PATCH v7 05/10] arm64: dts: qcom: shikra: Add CDSP, LPAICP, MPSS remoteproc PAS nodes ---
commit 65c0930ecad74d3ed9ab1c696c97ce9cf5c374b0
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
> --- 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 {
> +			compatible = "qcom,shikra-mpss-pas";
> +			reg = <0x0 0x06080000 0x0 0x100>;
[ ... ]
> +			power-domains = <&rpmpd RPMHPD_CX>;

[Severity: Low]
Is this using the correct power domain macro? The Shikra SoC uses an RPM SMD 
power controller (rpmpd), not RPMh, so shouldn't this be RPMPD_VDDCX instead of
RPMHPD_CX?

> +
> +			memory-region = <&mpss_wlan_mem>;
[ ... ]
> +		remoteproc_cdsp: remoteproc@b300000 {
> +			compatible = "qcom,shikra-cdsp-pas";
> +			reg = <0x0 0x0b300000 0x0 0x100000>;
[ ... ]
> +			power-domains = <&rpmpd RPMHPD_CX>;

[Severity: Low]
Similar to the remoteproc_mpss node, shouldn't this use RPMPD_VDDCX instead of
the RPMh macro RPMHPD_CX?

> +
> +			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]
Are these lmcu_smp2p_in interrupts correctly defined as IRQ_TYPE_NONE? The 
hardware SMP2P interrupts are edge-triggered, so should these be specified as 
IRQ_TYPE_EDGE_RISING instead?

> +
> +			interrupt-names = "wdog",
> +					  "fatal",
> +					  "ready",
> +					  "handover",
> +					  "stop-ack";
[ ... ]

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