All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vikash Garodia" <vikash.garodia@oss.qualcomm.com>
Cc: media-ci@linuxtv.org, robh@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region
Date: Fri, 07 Aug 2026 08:49:12 +0000	[thread overview]
Message-ID: <20260807084913.384D81F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260807-iris_iova_600mb_fix-v1-1-3996f67e33f9@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch updates `qcom,venus-common.yaml` to permit a second `memory-region` phandle for an IOMMU IOVA reservation, but fails to remove a stale `maxItems: 1` constraint from `qcom,sc7180-venus.yaml`. This prevents SC7180 devices from successfully validating if they supply the newly permitted second region.
--

--- Patch [1]: [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region ---
commit 44e20424e211e02ef9914abe4592c185ad0d75ac
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region

Non-pixel stream IDs should not allocate IOVA space from the 0 to 600MB
restricted region, as this region is reserved exclusively for secure
non-pixel.

In addition to the firmware-loaded codec carveout, platforms need to
declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from restricted IOVA range.

Permit a second memory-region phandle for this purpose, and describe the
meaning of each entry so the ordering is unambiguous.

> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d21..0be2f9119e782 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -37,7 +37,10 @@ properties:
>      maxItems: 20
>  
>    memory-region:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: Firmware-loaded codec carveout
> +      - description: IOMMU IOVA reservation region

[Severity: Medium]
Since this patch expands the common schema to allow two memory-region items,
should the local constraints in related variant schemas also be updated?

For example, the local constraint in qcom,sc7180-venus.yaml restricts the
items to 1:

Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml:properties.memory-region {
    ...
  memory-region:
    maxItems: 1
    ...
}

Because dt-schema evaluates a logical AND between local constraints and
the included $ref schemas, won't SC7180 device trees fail dt_binding_check
validation if they declare the newly permitted IOVA reservation region?

>  
>    power-domains:
>      minItems: 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=1

  reply	other threads:[~2026-08-07  8:49 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5BXSXMNl656WiJPJAMmHvb3I2NzYMshRZuGuub3CxEXvdCUlIDKYbnv5jUq-pa6P1NibBLkO3njnKGxi7Al3jQ==@protonmail.internalid>
2026-08-07  8:24 ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Vikash Garodia
2026-08-07  8:24   ` [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region Vikash Garodia
2026-08-07  8:49     ` sashiko-bot [this message]
2026-08-07  8:51       ` Vikash Garodia
2026-08-07  8:24   ` [PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: " Vikash Garodia
2026-08-07  8:40     ` sashiko-bot
2026-08-07  9:01     ` Dmitry Baryshkov
2026-08-07  8:24   ` [PATCH 03/22] dt-bindings: media: qcom,sc7180-venus: " Vikash Garodia
2026-08-07  8:24   ` [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris Vikash Garodia
2026-08-07  8:45     ` sashiko-bot
2026-08-07  9:03     ` Dmitry Baryshkov
2026-08-07  9:26       ` Vikash Garodia
2026-08-07 10:00         ` Dmitry Baryshkov
2026-08-07 10:22           ` Vikash Garodia
2026-08-07 13:18             ` Bryan O'Donoghue
2026-08-08 15:48               ` Vikash Garodia
2026-08-10 12:10                 ` Dmitry Baryshkov
2026-08-10 16:57                   ` Vikash Garodia
2026-08-11  0:17                     ` Dmitry Baryshkov
2026-08-07 16:24       ` Rob Herring
2026-08-08  4:37         ` Vishnu Reddy
2026-08-08  9:55           ` Bryan O'Donoghue
2026-08-10 13:47             ` Rob Herring
2026-08-07  8:24   ` [PATCH 05/22] arm64: dts: qcom: lemans: " Vikash Garodia
2026-08-07  8:44     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 06/22] arm64: dts: qcom: monaco: " Vikash Garodia
2026-08-07  8:47     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 07/22] arm64: dts: qcom: sc8280xp: " Vikash Garodia
2026-08-07  8:44     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 08/22] arm64: dts: qcom: sm8350: " Vikash Garodia
2026-08-07  8:50     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 09/22] arm64: dts: qcom: sm8550: " Vikash Garodia
2026-08-07  8:46     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 10/22] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-08-07  8:42     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 11/22] arm64: dts: qcom: sm8750: " Vikash Garodia
2026-08-07  8:54     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 12/22] arm64: dts: qcom: agatti: Reserve low IOVA range for Venus Vikash Garodia
2026-08-07  8:57     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 13/22] arm64: dts: qcom: kodiak: " Vikash Garodia
2026-08-07  8:54     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 14/22] arm64: dts: qcom: msm8916: " Vikash Garodia
2026-08-07  8:58     ` sashiko-bot
2026-08-07  8:24   ` [PATCH 15/22] arm64: dts: qcom: msm8996: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 16/22] arm64: dts: qcom: msm8998: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 17/22] arm64: dts: qcom: sc7180: " Vikash Garodia
2026-08-07  8:59     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 18/22] arm64: dts: qcom: sdm630: " Vikash Garodia
2026-08-07  9:00     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 19/22] arm64: dts: qcom: sdm845: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 20/22] arm64: dts: qcom: sm6115: " Vikash Garodia
2026-08-07  9:05     ` sashiko-bot
2026-08-07  8:25   ` [PATCH 21/22] arm64: dts: qcom: sm8250: " Vikash Garodia
2026-08-07  8:25   ` [PATCH 22/22] arm64: dts: qcom: talos: " Vikash Garodia
2026-08-07  9:08     ` sashiko-bot
2026-08-07  8:51   ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Bryan O'Donoghue
2026-08-07  8:59   ` Dmitry Baryshkov
2026-08-07  9:05     ` Vikash Garodia
2026-08-07 10:01       ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260807084913.384D81F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vikash.garodia@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.