Claude review: dt-bindings: display: renesas, rzg2l-du: Add RZ/T2H and RZ/N2H support

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

Patch Review

**The compatible strings and fallback pattern look fine.** The RZ/N2H→RZ/T2H fallback follows the established pattern used by RZ/V2L→RZ/G2L and RZ/V2N→RZ/V2H.

**Issue 1 — Removing `resets` and `ports` from global required list:**

```yaml
 required:
   - compatible
   - reg
   - interrupts
   - clocks
   - clock-names
-  - resets
   - power-domains
-  - ports
   - renesas,vsps
```

Removing `resets` and `ports` from the global `required` and conditionally adding them back in the `else` clause is workable, but the `else` clause will match _any_ compatible that does NOT contain `renesas,r9a09g077-du`. This is fine today but could be fragile if another SoC is added that also lacks a reset or uses `port` instead of `ports`. A more robust pattern would be to add an explicit `if` for the existing SoCs that require `resets`/`ports` rather than relying on an `else` that implicitly covers all non-T2H variants.

Actually, looking more carefully, the `else` is tied to the `r9a09g077-du` conditional:

```yaml
  - if:
      properties:
        compatible:
          contains:
            const: renesas,r9a09g077-du
    then:
      properties:
        resets: false
      required:
        - port
    else:
      required:
        - resets
        - ports
```

This is technically correct — the `else` covers all non-RZ/T2H variants, re-requiring `resets` and `ports`. But note that `resets: false` in the `then` clause actively forbids the property, which is a strong statement. The cover letter says "the DU does not have a reset line" — if that's definitive, this is fine, but it means DT authors can't even include an empty/stub reset on T2H. Confirm this is the hardware intent.

**Issue 2 — `port` vs `ports` with single port:**

The patch adds a new `port` property alongside the existing `ports`:

```yaml
  port:
    $ref: /schemas/graph.yaml#/properties/port
    description: Single output port for single-output DU variants.
```

The existing DU variants already handle single-output configurations using `ports` with a single `port@0` child (see the r9a07g043u and r9a09g057 cases). Using a bare `port` instead of `ports` for T2H creates an inconsistency in the binding. Consider whether `ports` with a single `port@0` child would be more consistent with the existing binding structure. This is a DT binding convention question that the DT maintainers (Rob/Krzysztof) should weigh in on.

**Issue 3 — No RZ/T2H-specific port description in allOf:**

The existing `allOf` blocks describe what each port represents (e.g., "DPI", "DSI"). The T2H `then` clause only requires `port` but doesn't add a description for what the port represents (presumably DPI). Minor but worth adding for consistency.

---
Generated by Claude Code Patch Reviewer