From: sashiko-bot@kernel.org
To: "Max Pedraza" <maximpedraza@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 5/7] dt-bindings: display: allow the boot logo in a reserved memory region
Date: Wed, 23 Sep 2026 20:17:07 +0000 [thread overview]
Message-ID: <20260923201707.E6A6A1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260923201035.51007-6-maximpedraza@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: oneOf allows partial image properties with memory-region
--
commit 9a7a18d6778dd2101e7f626e61f0b37dcf103451
Author: Max Pedraza <maximpedraza@gmail.com>
Subject: dt-bindings: display: allow the boot logo in a reserved memory region
This commit allows the boot logo to be specified via a reserved memory
region instead of inline properties, enabling the image to be shared across
multiple device trees. It introduces a oneOf constraint intended to make
the two methods mutually exclusive.
> diff --git a/Documentation/devicetree/bindings/display/boot-logo-clut224.yaml b/Documentation/devicetree/bindings/display/boot-logo-clut224.yaml
> index 9dc34717639e9..a71fc09a7c071 100644
> --- a/Documentation/devicetree/bindings/display/boot-logo-clut224.yaml
> +++ b/Documentation/devicetree/bindings/display/boot-logo-clut224.yaml
[ ... ]
> @@ -103,10 +122,17 @@ properties:
>
> required:
> - compatible
> - - width
> - - height
> - - clut
> - - data
> +
> +# The image either lives in the device tree or in a reserved memory region,
> +# never both.
> +oneOf:
> + - required:
> + - width
> + - height
> + - clut
> + - data
> + - required:
> + - memory-region
[Severity: Low]
Does this schema validation fully enforce the intended mutual exclusivity if
partial image properties are provided?
If a device tree includes memory-region alongside just a few of the image
properties (for example, accidentally including width and height but not clut),
the first branch of the oneOf evaluates to false. The second branch evaluates
to true.
Since exactly one branch is true, the overall oneOf constraint succeeds. This
allows invalid device trees with overlapping configurations to silently pass
dt_binding_check.
Should the schema explicitly disallow the other properties when memory-region
is present to prevent this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923201035.51007-1-maximpedraza@gmail.com?part=5
next prev parent reply other threads:[~2026-09-23 20:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 20:10 [PATCH v3 0/7] Boot logo supplied by the device tree Max Pedraza
2026-09-23 20:10 ` [PATCH v3 1/7] fbdev: describe where the boot logo goes in one place Max Pedraza
2026-09-24 12:05 ` Thomas Zimmermann
2026-09-23 20:10 ` [PATCH v3 2/7] dt-bindings: display: add a device tree supplied boot logo Max Pedraza
2026-09-23 20:17 ` sashiko-bot
2026-09-24 11:49 ` Rob Herring (Arm)
2026-09-25 8:58 ` Màxim Pedraza Padilla
2026-09-23 20:10 ` [PATCH v3 3/7] video: logo: allow the boot logo to come from the device tree Max Pedraza
2026-09-23 20:10 ` [PATCH v3 4/7] fbdev: honour the device tree boot logo placement properties Max Pedraza
2026-09-23 20:10 ` [PATCH v3 5/7] dt-bindings: display: allow the boot logo in a reserved memory region Max Pedraza
2026-09-23 20:17 ` sashiko-bot [this message]
2026-09-23 20:10 ` [PATCH v3 6/7] video: logo: allow the boot logo to come from " Max Pedraza
2026-09-23 20:10 ` [PATCH v3 7/7] video: logo: add ppmtodtlogo host tool Max Pedraza
2026-09-23 20:24 ` sashiko-bot
2026-09-24 12:21 ` [PATCH v3 0/7] Boot logo supplied by the device tree Thomas Zimmermann
2026-09-25 8:48 ` Màxim Pedraza Padilla
2026-09-25 19:31 ` Francesco Valla
2026-09-29 11:46 ` Màxim Pedraza Padilla
2026-09-30 6:32 ` Francesco Valla
2026-10-01 20:17 ` Màxim Pedraza Padilla
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=20260923201707.E6A6A1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=maximpedraza@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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