Re: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The newly defined context bank subnodes are entirely inaccessible to the targeted `sm8550-iris` platform.
- [Medium] Missing required properties in the common schema's subnode validation block.
- [Medium] Schema validation conflict for migrated child schemas due to unconditionally required `iommus` property.
--

--- Patch [1]: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema ---
commit f7ccdc698c2e9a5f1a41568fd6c456d9da607bec
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

dt-bindings: media: qcom,venus: Add context bank subnodes to common schema

This commit describes each VPU SMMU stream as its own context bank subnode
to associate it with its reachable IOVA range. It adds non-pixel, pixel,
and video-firmware to the common schema, replacing the single iommus
property approach.

> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index b21bed3148484..bfd8b1ad47312 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
[ ... ]
> @@ -91,21 +91,6 @@ properties:
>      deprecated: true
>      additionalProperties: false
>  
> -  video-firmware:
> -    type: object
> -    additionalProperties: false
> -
> -    description: |
> -      Firmware subnode is needed when the platform does not
> -      have TrustZone.
> -
> -    properties:
> -      iommus:
> -        maxItems: 1
> -
> -    required:
> -      - iommus
> -
>  required:
>    - compatible
>    - power-domain-names

[Severity: Medium]
Does the unconditionally required iommus property in this file break migrations?

Since the common schema makes iommus optional when the new subnodes are
present via a oneOf block, if a platform like sc7180 is migrated to use the
new subnode layout (dropping the parent iommus), it will fail
make dt_binding_check because qcom,sc7180-venus.yaml still unconditionally
mandates iommus in its local required list.

> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d21..ccae41bed757b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -47,6 +47,50 @@ properties:
>      minItems: 1
>      maxItems: 4
>  
> +  dma-ranges: true
> +
> +  #address-cells:
> +    const: 2
> +
> +  #size-cells:
> +    const: 2
> +
> +  non-pixel:

[Severity: High]
Are these newly defined context bank subnodes accessible to the targeted
sm8550-iris platform?

The commit message notes this limitation applies to every VPU generation and
specifically mentions fixing an issue on sm8550. However,
qcom,sm8550-iris.yaml does not appear to include a $ref to
qcom,venus-common.yaml and sets unevaluatedProperties: false.

Would adding non-pixel or pixel subnodes to the sm8550 device tree result in
an immediate validation failure because the properties are undeclared in the
iris schema?

[ ... ]
> @@ -55,4 +99,11 @@ required:
>    - memory-region
>    - power-domains
>  
> +oneOf:
> +  - required:
> +      - iommus
> +  - required:
> +      - non-pixel
> +      - pixel

[Severity: Medium]
Should #address-cells, #size-cells, and dma-ranges be enforced here when the
subnodes are used?

The commit message explains that adding the subnodes requires these supporting
properties on the parent video-codec node. Without enforcing them in this
oneOf block alongside non-pixel and pixel, device trees can omit these
properties and still pass validation.

Could this cause of_translate_dma_region() to fail or return incorrect IOVAs
at runtime if the properties are omitted?

> +
>  additionalProperties: true

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731-vpu_iommu_iova_handling-v2-0-da52b5228dbd@oss.qualcomm.com?part=1