Re: [PATCH v5 1/2] dt-bindings: media: add ITE IT6625/IT6626 HDMI bridge binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Endpoint constraints are defined under `properties: { endpoint: ... }` instead of a regex matcher, allowing nodes with unit addresses (e.g., `endpoint@0`) to silently bypass all validation.
--

--- Patch [1]: [PATCH v5 1/2] dt-bindings: media: add ITE IT6625/IT6626 HDMI bridge binding ---
commit a192dc5aebea5ae00e69101d6df13fb9633bf4ce
Author: Hermes Wu <Hermes.wu@ite.com.tw>

dt-bindings: media: add ITE IT6625/IT6626 HDMI bridge binding

Document the devicetree binding for the ITE IT6625/IT6626 HDMI to
MIPI CSI-2 bridge. The device exposes two graph ports: port@0
(MIPI0) and port@1 (MIPI1), the two selectable CSI-2 D-PHY/C-PHY
outputs. Only port@0 is required, since a board only needs to wire up
as many of the bridge's outputs as it actually uses.

> diff --git a/Documentation/devicetree/bindings/media/i2c/ite,it6625.yaml b/Documentation/devicetree/bindings/media/i2c/ite,it6625.yaml
> new file mode 100644
> index 0000000000000..fed732e4428ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ite,it6625.yaml
> @@ -0,0 +1,169 @@
[ ... ]
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: CSI-2 output port MIPI0
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/media/video-interfaces.yaml#

[Severity: Medium]
Will this schema allow nodes with unit addresses like endpoint@0 to bypass
these validation constraints?

While the commit message notes that this is a convention already used by other
single-endpoint-per-port bindings, defining constraints under a literal
endpoint node instead of using a patternProperties matcher like
"^endpoint(@[0-9a-fA-F]+)?$" structurally bypasses schema validation.

An endpoint@0 node would silently avoid these data-lanes boundaries and the
bus-type requirements, which could allow misconfigured hardware setups to pass
schema checks and result in silent driver misconfiguration at runtime.

> +            unevaluatedProperties: false
> +
> +            properties:
> +              data-lanes:
> +                minItems: 1
> +                maxItems: 4
[ ... ]
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ite,it6626
> +    then:
> +      properties:
> +        ports:
> +          properties:
> +            port@0:
> +              properties:
> +                endpoint:
> +                  required:
> +                    - bus-type

[Severity: Medium]
Does this bus-type constraint also suffer from the same bypass loophole?

Since it is strictly bound to the literal endpoint node name, an endpoint@0
node would also bypass this bus-type requirement introduced for the IT6626.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722-upstream-it6625-it6626-v5-0-387e7584f2c9@ite.com.tw?part=1