From: sashiko-bot@kernel.org
To: "Sascha Hauer" <s.hauer@pengutronix.de>
Cc: media-ci@linuxtv.org, robh@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/9] dt-bindings: media: snps,dw-hdmi-rx: add a port for a bridge in front
Date: Thu, 24 Sep 2026 12:16:14 +0000 [thread overview]
Message-ID: <20260924121615.3B3751F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924-hdmirx-media-v2-3-c12f641d8b0f@pengutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: snps,dw-hdmi-rx: oneOf prevents valid port+gpio topologies
--
commit 5a7ff8edccb5f40d2e32f33eaa88727a0083785a
Author: Sascha Hauer <s.hauer@pengutronix.de>
dt-bindings: media: snps,dw-hdmi-rx: add a port for a bridge in front
This commit describes the OF graph port for connecting an HDMI bridge in
front of the receiver. It enforces a mutually exclusive constraint where a
board must provide exactly one of hpd-gpios or port.
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> index b7f6c87d0e06a..896f8ffbb5bf9 100644
> --- a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
[ ... ]
> @@ -88,7 +100,12 @@ required:
> - power-domains
> - resets
> - pinctrl-0
> - - hpd-gpios
> +
> +oneOf:
> + - required:
> + - hpd-gpios
> + - required:
> + - port
[Severity: Medium]
Does this strict XOR constraint break validation for boards that need to define
both properties?
A board might route high-speed video through an upstream bridge (which requires
the port) while still wiring the HDMI +5V detect line directly to an SoC GPIO
(which requires hpd-gpios). Similarly, standard DT architecture for direct HDMI
connections encourages explicit hdmi-connector nodes linked via the port, which
would also necessitate retaining hpd-gpios on the controller for 5V sensing.
Although the driver implementation might gracefully handle both properties being
present simultaneously, this schema constraint forbids valid hardware topologies
from passing dt_binding_check. Would it be more appropriate to use anyOf here
to allow one or both properties?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-hdmirx-media-v2-0-c12f641d8b0f@pengutronix.de?part=3
next prev parent reply other threads:[~2026-09-24 12:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 12:05 [PATCH v2 0/9] media: synopsys: hdmirx: support an HDMI bridge in front of the receiver Sascha Hauer
2026-09-24 12:05 ` [PATCH v2 1/9] media: synopsys: hdmirx: add media device infrastructure Sascha Hauer
2026-09-24 12:17 ` sashiko-bot
2026-09-24 12:05 ` [PATCH v2 2/9] media: synopsys: hdmirx: add media entity for video capture device Sascha Hauer
2026-09-24 12:05 ` [PATCH v2 3/9] dt-bindings: media: snps,dw-hdmi-rx: add a port for a bridge in front Sascha Hauer
2026-09-24 12:16 ` sashiko-bot [this message]
2026-09-24 16:55 ` Conor Dooley
2026-09-24 12:05 ` [PATCH v2 4/9] media: synopsys: hdmirx: add async subdevice support Sascha Hauer
2026-09-24 12:05 ` [PATCH v2 5/9] media: synopsys: hdmirx: give the signal lock wait a real timeout Sascha Hauer
2026-09-24 12:06 ` [PATCH v2 6/9] media: synopsys: hdmirx: skip the 5V detect interrupt without a GPIO Sascha Hauer
2026-09-24 12:06 ` [PATCH v2 7/9] media: v4l2-device: wait for notifications when unregistering a subdev Sascha Hauer
2026-09-24 12:14 ` sashiko-bot
2026-09-24 12:06 ` [PATCH v2 8/9] media: v4l2-subdev: notify the bridge when the source power changes Sascha Hauer
2026-09-24 12:06 ` [PATCH v2 9/9] media: synopsys: hdmirx: get the 5V state from the upstream subdev Sascha Hauer
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=20260924121615.3B3751F000FF@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=s.hauer@pengutronix.de \
--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