Re: [PATCH v2 2/2] arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dma: iommu-ranges property fails to restrict IOVA allocations
- [Low] dt-bindings: unnecessary #address-cells and #size-cells cause DTC warnings
--

commit 62c300467cdba54ac064fbbf7a04d9a00a746896
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

arm64: dts: qcom: glymur: add CDSP FastRPC extended context bank

This commit wires up compute-cb@12 as a dedicated extended IOVA context bank
by adding an iommu-ranges property to restrict allocations to the [16 GiB,
~1 TiB) window. It also updates #address-cells, #size-cells, and the reg
properties to accommodate 64-bit values.

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index de7c395d9c353..cba22314591f2 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -8370,6 +8370,8 @@ remoteproc_cdsp: remoteproc@32300000 {
>  			qcom,qmp = <&aoss_qmp>;
>  			qcom,smem-states = <&smp2p_cdsp_out 0>;
>  			qcom,smem-state-names = "stop";
> +			#address-cells = <2>;
> +			#size-cells = <2>;

[Severity: Low]
Are these properties necessary here? Device Tree dictates that
#address-cells and #size-cells only affect a node's direct children. Since
glink-edge does not have a reg or ranges property, adding these properties
to its parent is non-functional and triggers avoid_unnecessary_addr_size DTC
warnings. It also violates strict YAML bindings.

>  
>  			status = "disabled";
>  
> @@ -8381,17 +8383,19 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
>  						IPCC_MPROC_SIGNAL_GLINK_QMP>;
>  				qcom,remote-pid = <5>;
>  				label = "cdsp";
> +				#address-cells = <2>;
> +				#size-cells = <2>;

[Severity: Low]
Similar to the remoteproc_cdsp node, could these properties be removed from
the glink-edge node? The fastrpc child node lacks a reg or ranges property,
so these will cause DTC warnings and dtbs_check failures.

[ ... ]

> @@ -8493,11 +8497,12 @@ compute-cb@11 {
>  
>  					compute-cb@12 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <12>;
> +						reg = <0x0 0xc 0x0 0x0>;
>  
>  						iommus = <&apps_smmu 0x240e 0x440>,
>  							 <&apps_smmu 0x196e 0x0>,
>  							 <&apps_smmu 0x19ce 0x0>;
> +						iommu-ranges = <0x4 0x0 0xfc 0x0>;

[Severity: High]
Does this property actually restrict IOVA allocations as intended?

The generic Linux DMA and OF subsystems only parse the standard dma-ranges
property to establish IOVA domain geometry.

The fastrpc driver only checks for the presence of iommu-ranges via
of_property_present() to raise the DMA mask to 40 bits, but it never reads
the base address or size values.

Because no lower bound is configured for the IOVA domain, the allocator can
hand out IOVAs starting from 0, potentially causing device faults or memory
corruption if the DSP hardware requires mappings above the 16 GiB boundary.

>  						dma-coherent;
>  					};
>  				};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-extended-mapping-dts-v2-0-fa9e14900313@oss.qualcomm.com?part=2