Linux s390 Architecture development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thierry Reding" <thierry.reding@kernel.org>
Cc: conor+dt@kernel.org, robh@kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	media-ci@linuxtv.org, dri-devel@lists.freedesktop.org,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	devicetree@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH v4 01/10] dt-bindings: reserved-memory: Document Tegra VPR
Date: Fri, 07 Aug 2026 16:08:03 +0000	[thread overview]
Message-ID: <20260807160805.01FC51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807-tegra-vpr-v4-1-5510d16af89e@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The dt-schema examples for the VPR omit the parent `reserved-memory` node context, causing 64-bit multi-cell values to be incorrectly parsed against 1-cell defaults.
--

--- Patch [1]: [PATCH v4 01/10] dt-bindings: reserved-memory: Document Tegra VPR ---
commit 8113c8e6ae5fc4a5f07530aed37855cc00e7b6cc
Author: Thierry Reding <treding@nvidia.com>

dt-bindings: reserved-memory: Document Tegra VPR

This commit adds device tree binding documentation for the Video
Protection Region (VPR) on NVIDIA Tegra chips. It supports both fixed
and resizable memory regions for DRM protected content playback.

> diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.yaml
> new file mode 100644
> index 0000000000000..862bfd3913786
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.yaml

[ ... ]

> +examples:
> +  - |
> +    /* resizable VPR */
> +    protected {
> +      compatible = "nvidia,tegra-video-protection-region";
> +
> +      size = <0x0 0x70000000>;
> +      alignment = <0x0 0x100000>;

[Severity: Low]
Will this example fail semantic validation during make dt_binding_check?

Because #size-cells and #address-cells default to <1> at the root level,
omitting the parent reserved-memory node wrapper causes these 64-bit
multi-cell values to be parsed against 1-cell defaults. The size and
alignment properties here provide 2 cells and will be evaluated as arrays
of two 32-bit values rather than single 64-bit values.

> +      reusable;
> +    };

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-tegra-vpr-v4-0-5510d16af89e@nvidia.com?part=1

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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 15:54 [PATCH v4 00/10] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-08-07 15:54 ` [PATCH v4 01/10] dt-bindings: reserved-memory: Document " Thierry Reding
2026-08-07 16:08   ` sashiko-bot [this message]
2026-08-07 15:54 ` [PATCH v4 02/10] dt-bindings: display: tegra: Document memory regions Thierry Reding
2026-08-07 16:05   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 03/10] dt-bindings: gpu: host1x: Document memory-regions for NVDEC Thierry Reding
2026-08-07 16:05   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 04/10] bitmap: Add bitmap_allocate() function Thierry Reding
2026-08-07 16:11   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 05/10] mm/cma: Allow dynamically creating CMA areas Thierry Reding
2026-08-07 16:15   ` sashiko-bot
2026-08-07 16:16   ` David Hildenbrand (Arm)
2026-08-07 15:54 ` [PATCH v4 06/10] dma-buf: heaps: Add debugfs support Thierry Reding
2026-08-07 16:19   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 07/10] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-08-07 16:12   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 08/10] arm64: tegra: Add VPR placeholder node on Tegra234 Thierry Reding
2026-08-07 16:06   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 09/10] arm64: tegra: Hook up VPR to host1x Thierry Reding
2026-08-07 16:16   ` sashiko-bot
2026-08-07 15:54 ` [PATCH v4 10/10] arm64: tegra: Add VPR placeholder node on Tegra264 Thierry Reding
2026-08-07 16:09   ` sashiko-bot

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=20260807160805.01FC51F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=thierry.reding@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox