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 <[email protected]> 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/[email protected]?part=1
