Re: [PATCH v2 3/5] arm64: dts: qcom: eliza: Add iris video codec node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: qcom: eliza: iommus hidden in subnodes causing SMMU bypass
--

commit b77780d6cb2ef27e94100c8e74b32f91454ac5cd
Author: Wangao Wang <wangao.wang@oss.qualcomm.com>

arm64: dts: qcom: eliza: Add iris video codec node

This commit adds the Iris video codec hardware node for the Eliza SoC.
It defines the hardware at 0xaa00000, including interconnects, clocks,
power domains, and operating points.

> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
[ ... ]
> +		iris: video-codec@aa00000 {
> +			compatible = "qcom,eliza-iris";
> +			reg = <0 0xaa00000 0 0xf0000>;
[ ... ]
> +			status = "disabled";
> +
> +			non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				iommu-ranges = <0x25800000 0xba800000>;
> +			};
> +
> +			pixel {
> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};

[Severity: High]
Does this break the IOMMU configuration for the upstream iris driver?

The mainline devicetree binding and Linux driver core expect the iommus
property directly on the main iris device node (video-codec@aa00000) to
correctly attach it to an IOMMU domain.

Placing the iommus configuration inside non-pixel and pixel subnodes appears
to rely on downstream parsing behavior. Because the upstream iris driver does
not parse these subnodes, the main device will lack an IOMMU attachment.
Will this cause subsequent DMA allocations to bypass the SMMU or fail entirely,
leading to SMMU context faults when dealing with IOVAs?

Additionally, does this node structure fail dtbs_check validation since
the subnodes and the iommu-ranges property are forbidden by the upstream
bindings?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-add_iris_for_eliza-v2-0-5fe7be8c0230@oss.qualcomm.com?part=3