Re: [RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `iommu-addresses` without a `reg` property inside the `reserved-memory` node creates an `IOMMU_RESV_RESERVED` region. This explicitly excludes the 0-600MB IOVA range from being allocated, which completely contradicts the patch's stated intention to limit allocations to this range.
--

--- Patch [11]: [RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes ---
commit c2708742df23b3eb0cc33ed47303581c81143971
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

This patch separates the Iris VPU streams into pixel and non-pixel child
nodes to enforce different IOVA constraints. It attempts to limit the 
non-pixel stream to the 0-600 MB IOVA range by adding a reserved IOVA 
range node.

> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 447b788fcbb96..f9c03de1317f1 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -1849,6 +1849,10 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
>  			reg = <0 0xff800000 0 0x600000>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};

[Severity: High]
Does using iommu-addresses without a reg property in this reserved-memory 
node actually block the 0-600MB range instead of allowing allocations 
within it?

When the non-pixel device is initialized, iommu_dma_init_domain() calls
of_iommu_get_resv_regions(). Because iris_resv lacks a reg property,
this function returns an IOMMU_RESV_RESERVED region for 0-600MB. The 
generic IOMMU layer then calls reserve_iova(), inserting this range into
the rbtree as occupied.

If the 0-600MB range is reserved as blocked, will dma_alloc_attrs() for
the non-pixel stream skip this region entirely and return IOVAs strictly
above 600MB?

This appears to contradict the stated intention of limiting allocations 
to the 0-600MB range, which could guarantee the very device crash the 
patch aims to fix.

[ ... ]

> @@ -5231,6 +5235,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			 */
>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				memory-region = <&iris_resv>;
> +			};
> +
> +			iris_pixel: pixel {
> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};
> +
>  			iris_opp_table: opp-table {
>  				compatible = "operating-points-v2";

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=11