Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Mismatch between device tree schema and driver implementation for the `data-lanes` property. --
--- Patch [2]: [PATCH v3 2/2] dt-bindings: display: sn65dsi83: Add output data-lanes --- commit 98aea58cd5128c6a4b72efd4a5f9ec088fd30dca Author: Wojciech Dubowik <[email protected]> dt-bindings: display: sn65dsi83: Add output data-lanes This commit adds an optional output LVDS data lanes property with two allowed values. It supports the standard layout <1 2 3 4> and reversed layout <4 3 2 1> for output channels. > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > index e69b6343a8ebb..4431f113bb9cd 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > @@ -86,10 +86,52 @@ properties: > description: Video port for LVDS Channel-A output (panel or bridge). > $ref: '#/$defs/lvds-port' > > + properties: > + data-lanes: > + $ref: /schemas/types.yaml#/definitions/uint32-array [Severity: Medium] Does this schema change place data-lanes at the correct level in the device tree hierarchy? The schema defines data-lanes as a direct property of the port node, but standard OF graph rules and the driver implementation parse it from the endpoint node: drivers/gpu/drm/bridge/ti-sn65dsi83.c:sn65dsi83_parse_lvds_endpoint() { ... ret_data = of_property_read_u32_array(endpoint, "data-lanes", data_lanes, ARRAY_SIZE(data_lanes)); ... } Because the driver reads from the endpoint node rather than the port node, will it silently fail to find the configuration and fall back to the default layout on affected hardware? > + description: | > + Array of physical LVDS data lane indexes > + oneOf: [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
