Claude review: arm64: dts: rockchip: orangepi-5-pro: Add LT8711UXD DP-to-HDMI bridge

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

Patch Review

This wires up the full display pipeline: VOP2 vp1 → dp0 → LT8711UXD bridge → HDMI1 connector. A few observations:

**1. `regulator-always-on` (minor/acceptable):**

```dts
+	vcc3v3_dp: regulator-vcc3v3-dp {
+		...
+		regulator-always-on;
+	};
```

The cover letter documents the HPD chicken-and-egg problem well: simple-bridge only calls `pre_enable` on modeset, but modeset won't start until HPD asserts, and HPD won't assert until the bridge is powered. Holding the supply on from boot is the standard workaround for autonomous bridges. Worth noting this means the enable GPIO stays asserted during suspend — on a desktop-class SBC this is unlikely to matter, but it's a trade-off to be aware of.

**2. Missing `status = "okay"` on `&usbdp_phy0` (probably fine):**

The `&usbdp_phy0` override only updates the comment and keeps the existing `rockchip,dp-lane-mux = <0 1>;`. The base DTS (from the earlier Orange Pi 5 Pro series) presumably already enables the PHY for the USB3 Type-A port. Just confirming that the prior series does set `status = "okay"` there — if it doesn't, DP won't work.

**3. VOP2/DP pipeline matches existing patterns:**

The `&vp1` endpoint and `&dp0_in`/`&dp0_out` wiring matches the established pattern from boards like indiedroid-nova and coolpi-4b:

```dts
+&vp1 {
+	vp1_out_dp0: endpoint@a {
+		reg = <ROCKCHIP_VOP2_EP_DP0>;
+		remote-endpoint = <&dp0_in_vp1>;
+	};
+};
```

This is correct — `ROCKCHIP_VOP2_EP_DP0` = 10 = 0xa, matching the `endpoint@a` unit address.

**4. Bridge node naming (nit):**

```dts
+	hdmi-bridge {
+		compatible = "lontium,lt8711uxd";
```

Some Rockchip DTS maintainers might prefer a more descriptive node name (e.g., `dp-to-hdmi-bridge`) but `hdmi-bridge` is fine and used by other boards.

**5. `dp-lane-mux = <0 1>` (correct):**

Using lanes 0/1 for DP and implicitly leaving lanes 2/3 for USB3 SuperSpeed matches the board's schematic description where the Type-A host connector uses the other pair. This is the same pattern as coolpi-4b.

**Overall for patch 3:** Looks correct and well-structured. No blocking issues.

---
Generated by Claude Code Patch Reviewer