Claude review: dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Positive aspects:**

- The `port-base` + `unevaluatedProperties: false` refactoring is correct and follows the established pattern used by other bridge bindings.
- The `data-lanes` property definition with `const: 1..4` items is properly constraining lanes to sequential 1-based indexes, matching the hardware.
- The example update adding `data-lanes = <1 2 3 4>` is good and consistent with similar bindings.
- The commit message correctly notes the driver dependency at `drivers/gpu/drm/bridge/lontium-lt9211.c:688`:
  ```c
  dsi_lanes = drm_of_get_data_lanes_count(endpoint, 1, 4);
  ```
  which returns an error if missing (checked at line 697-698).

**Concern — `required: data-lanes` on multi-protocol ports:**

The port descriptions state that these ports serve multiple input protocols:

```yaml
      port@0:
        description:
          Primary MIPI DSI port-1 for MIPI input or
          LVDS port-1 for LVDS input or DPI input.
```

Yet the patch unconditionally requires `data-lanes`:

```yaml
            required:
              - data-lanes
```

`data-lanes` is a DSI-specific concept. If a DT describes the LT9211 with LVDS or DPI input, the binding would now force inclusion of `data-lanes`, which is semantically wrong for those protocols. DT bindings should describe the hardware, not just the current driver implementation.

The `ti,sn65dsi83.yaml` binding (lines 44-83) was clearly used as a template for this change, but it notably does **not** include `required: - data-lanes` on its DSI input ports. The patch is stricter than its reference.

**Recommendation:** Drop the two `required: - data-lanes` blocks from both port@0 and port@1. The property definition alone (without `required`) is sufficient to document and validate the property when present. If the intent is truly to make this mandatory for DSI configurations only, a conditional schema (e.g., `if/then` keyed on the presence of a DSI remote-endpoint) would be more correct, though likely overkill for this binding.

If the argument is "the driver requires it," the correct fix is documenting the property (which this patch does) and optionally fixing the driver to provide a reasonable default or a better error message, rather than encoding a driver requirement as a hardware constraint.

---
Generated by Claude Code Patch Reviewer