Re: [PATCH v4 1/2] dt-bindings: display: sn65dsi83: Add output data-lanes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The inline `unevaluatedProperties: false` on `endpoint` blocks valid LVDS-specific properties inherited from `#/$defs/lvds-port`.
- [Medium] The `data-lanes` schema implicitly forces exactly 4 elements, breaking valid 3-lane LVDS configurations.
- [Low] Unnecessary duplication of the `data-lanes` schema block across `port@2` and `port@3`.
- [Low] Redundant `$ref` to `uint32-array` for a standard media property.
--

--- Patch [1]: [PATCH v4 1/2] dt-bindings: display: sn65dsi83: Add output data-lanes ---
commit 15be6ea27b74f8702a5daf407df624dc92403b9d
Author: Wojciech Dubowik <Wojciech.Dubowik@mt.com>

dt-bindings: display: sn65dsi83: Add output data-lanes

Add an optional output lvds data lanes property with
two allowed values. The array <1 2 3 4> for standard
layout and <4 3 2 1> for reversed lvds output lanes.
The latter informs the driver that reverse lvds config
option has to be set in config register for the respective
output channel.

> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> index e69b6343a8ebb..2693c0273f9ad 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -86,10 +86,62 @@ properties:
>          description: Video port for LVDS Channel-A output (panel or bridge).
>          $ref: '#/$defs/lvds-port'
>  
> +        properties:
> +          endpoint:
> +            $ref: /schemas/media/video-interfaces.yaml#
> +            unevaluatedProperties: false

[Severity: High]
Will this inline unevaluatedProperties block valid LVDS-specific properties
inherited from the shared lvds-port definition?

In JSON Schema 2019-09, unevaluatedProperties only considers properties
evaluated within its immediate schema object or its direct references. This
means it might incorrectly reject properties defined in
$defs/lvds-port/properties/endpoint.

> +
> +            properties:
> +              data-lanes:

[Severity: Low]
Could this entire data-lanes property definition be defined once centrally
inside $defs/lvds-port/properties/endpoint/properties instead of duplicating
it across both port@2 and port@3?

Placing it in the shared definition might also resolve the
unevaluatedProperties conflict.

> +                $ref: /schemas/types.yaml#/definitions/uint32-array

[Severity: Low]
Is this explicit type reference necessary?

The endpoint references /schemas/media/video-interfaces.yaml#, which already
enforces the uint32-array type for data-lanes globally.

> +                description: |
> +                  Array of physical LVDS data lane indexes
> +                oneOf:
> +                  - items:
> +                      - const: 1
> +                      - const: 2
> +                      - const: 3
> +                      - const: 4

[Severity: Medium]
Does this implicitly force exactly 4 elements and reject valid 3-lane LVDS
configurations?

Providing a YAML array for items without specifying minItems implicitly sets
both minItems and maxItems to the array's length (4). Since the SN65DSI83
hardware supports 18-bpp (3-lane) configurations, device trees using
data-lanes = <1 2 3> might fail validation.

> +                    description: |
> +                      This is the default layout
> +                  - items:
> +                      - const: 4
> +                      - const: 3
> +                      - const: 2
> +                      - const: 1
> +                    description: |
> +                      This is the reversed layout
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713082622.52985-1-wojciech.dubowik@mt.com?part=1