Re: [PATCH v2 1/2] arm64: dts: qcom: kaanapali: 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] dts: qcom: iommu-ranges property is unparsed, failing to restrict IOVA bounds
- [Low] dts: qcom: unit-address mismatch for compute-cb@12 and compute-cb@13
--

commit 1be2c80a69e840e3c302f9de578640a50eb91ac9
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

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

This commit wires up compute-cb@13 as a dedicated extended IOVA context bank
by adding the iommu-ranges property to restrict allocations. It also bumps
address and size cells to 2 to support 64-bit iommu-ranges, and updates the
compute-cb reg entries accordingly.

> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 131fd2a16c545..ed5853dd3c510 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi

[ ... ]

> @@ -6112,7 +6116,7 @@ compute-cb@8 {
>  
>  					compute-cb@12 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <12>;
> +						reg = <0x0 0xc 0x0 0x0>;

[Severity: Low]
Does the unit-address @12 need to be updated to match the new reg property?

The device tree specification requires the unit-address to exactly match the
first address in the reg property, formatted as hex without the 0x prefix. By
updating the reg address to 0xc but leaving the unit-address as @12, does
this trigger a unit_address_vs_reg dtc compilation warning?

>  						iommus = <&apps_smmu 0x196c 0x0>,
>  							 <&apps_smmu 0x0c2c 0x00>,
>  							 <&apps_smmu 0x0c0c 0x40>,
> @@ -6122,12 +6126,13 @@ compute-cb@12 {
>  
>  					compute-cb@13 {
>  						compatible = "qcom,fastrpc-compute-cb";
> -						reg = <13>;
> +						reg = <0x0 0xd 0x0 0x0>;

[Severity: Low]
Similar to the node above, does the unit-address @13 need to be updated to @d
to match the new reg address of 0xd?

>  						iommus = <&apps_smmu 0x196d 0x0>,
>  							 <&apps_smmu 0x0c0d 0x40>,
>  							 <&apps_smmu 0x0c2e 0x0>,
>  							 <&apps_smmu 0x0c2d 0x0>,
>  							 <&apps_smmu 0x19cd 0x0>;
> +						iommu-ranges = <0x4 0x0 0xfc 0x0>;

[Severity: High]
Does the kernel actually parse these lower bound restrictions?

The commit message states this restricts allocations to the [16 GiB, ~1 TiB)
window. However, the kernel's OF/IOMMU framework exclusively parses
dma-ranges to set up IOVA domain geometry. The custom iommu-ranges property
is never parsed by the core kernel.

Looking at drivers/misc/fastrpc.c, fastrpc_cb_init() only checks for the
presence of iommu-ranges:

	if (of_property_present(dev->of_node, "iommu-ranges"))
		is_extended_cb = true;

Since the driver sets a 40-bit DMA mask based on this presence but completely
ignores the specified lower bound, will the IOMMU IOVA allocator fall back to
the default domain geometry and freely allocate addresses in the [0, 16 GiB)
range instead?

Could this lead to fatal DSP faults or memory overlap if the DSP hardware
expects the allocations strictly in the restricted window?

>  						dma-coherent;
>  					};
>  				};

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