Claude review: drm/panel-edp: Add AUO B133HAN06.6 and BOE NV133FHM-N4F V8.0

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

Patch Review

**EDID verification:** Both product IDs are correctly extracted from the provided raw EDIDs. AUO bytes `8f cb` → 0xcb8f and BOE bytes `25 0a` → 0x0a25. Manufacturer IDs also decode correctly.

**Sort order:** Both entries are inserted in the correct ascending order by product ID:
- AUO: 0xc9a8 < **0xcb8f** < 0xcdba ✓
- BOE: 0x0a1b < **0x0a25** < 0x0a36 ✓

**Delay structures:**

```c
EDP_PANEL_ENTRY('A', 'U', 'O', 0xcb8f, &delay_200_500_e50, "B133HAN06.6"),
```
Uses `delay_200_500_e50` (hpd_absent=200, unprepare=500, enable=50) — a common default for AUO panels. Reasonable for a datasheet-only entry, consistent with neighboring AUO entries that use the same delay.

```c
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a25, &delay_200_500_e50_po2e200, "NV133FHM-N4F V8.0"),
```
Uses `delay_200_500_e50_po2e200`, which adds `powered_on_to_enable=200` on top of the base delays. Since this was hardware-tested, the choice of a delay with `powered_on_to_enable` is presumably validated. The nearby BOE entry at 0x0a1b uses the simpler `delay_200_500_e50`, so the difference is intentional and worth noting — the `powered_on_to_enable` delay likely reflects an observed requirement on this specific panel/board combination.

**Minor observation (not blocking):** The AUO panel was not tested on hardware. The commit message is transparent about this ("solely based on the provided datasheet"). If the delay turns out to be wrong, it can be adjusted later — standard practice for this table.

**No issues found.** Reviewed-by would be appropriate.

---
Generated by Claude Code Patch Reviewer