Claude review: dt-bindings: display: panel: Add LG LP156WF1

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

Patch Review

**Overall:** Good patch. The binding is a near-exact structural copy of `advantech,idk-2121wr.yaml`, which is the correct template to follow for dual-link LVDS panels.

**Positive observations:**

- The `allOf` references to both `lvds-dual-ports.yaml#` and `panel-common.yaml#` are correct.
- The `compatible` uses the `{}` placeholder pattern to avoid false `select` matching in `panel-lvds.yaml`, matching the established convention.
- Port requirements correctly specify `dual-lvds-odd-pixels` on `port@0` and `dual-lvds-even-pixels` on `port@1`.
- The exclusion added to `panel-lvds.yaml` is placed in alphabetical order — correct.
- Panel dimensions (345mm x 194mm) are consistent with a 15.6" 16:9 display.

**Minor observations:**

1. **`unevaluatedProperties: false` vs `additionalProperties: false`** — The new binding uses `unevaluatedProperties: false` (line 62 of the new file) while the existing `advantech,idk-2121wr.yaml` uses `additionalProperties: false`. This is actually an *improvement*: since the binding uses `allOf` with `$ref` to compose schemas, `unevaluatedProperties` is the correct JSON Schema keyword — it accounts for properties defined in referenced schemas, whereas `additionalProperties` does not. No change needed, just noting the divergence from the template is correct.

2. **Description could mention port-to-pixel mapping** — The `advantech,idk-2121wr.yaml` description explicitly states:
   ```
   The panel expects odd pixels on the first port, and even pixels on the
   second port, therefore the ports must be marked accordingly
   ```
   The new binding's description omits this detail. It would be a nice-to-have for consistency and clarity, since the port ordering matters for correct display output. Not blocking.

3. **Example uses `- |` vs `- |+`** — The idk-2121wr example uses `- |+` (keep trailing newlines) while this uses `- |`. Functionally irrelevant for dt-schema validation, but noting the difference for consistency. Not blocking.

4. **Timing values** — The example specifies `clock-frequency = <138500000>` (138.5 MHz), which is a reasonable pixel clock for 1920x1080 at ~60 Hz with the given blanking intervals. Quick sanity check: (1920+40+24+16) * (1080+23+3+5) * 60 = 2000 * 1111 * 60 ≈ 133.3 MHz — close enough given rounding and the panel's spec. Fine.

---
Generated by Claude Code Patch Reviewer