Claude review: drm/edid: parse panel type from DisplayID 2.x Display Parameters

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

Patch Review

**Purpose:** Adds parsing of the Display Device Technology field from the Display Parameters Data Block (tag 0x21).

**Struct layout:** `displayid_block` base is 3 bytes (tag + rev + num_bytes). The struct `displayid_display_params_block` places `payload[27]` then `device_tech_byte` at offset 30 from the block start (3 + 27 = 30 = 0x1E), which matches the spec reference. The `DISPLAYID_DISPLAY_PARAMS_MIN_LEN` calculation (29 bytes of payload) and the `num_bytes` check are correct.

**Parsing logic:** Using `FIELD_GET(DISPLAYID_DISPLAY_PARAMS_DEVICE_TECH, ...)` to extract bits [6:4] is correct and clean.

**UAPI concern (significant):**

```c
+#define DRM_MODE_PANEL_TYPE_LCD		2
```

This adds a new UAPI constant, but `drm_panel_type_enum_list` in `drivers/gpu/drm/drm_connector.c` currently only contains:

```c
static const struct drm_prop_enum_list drm_panel_type_enum_list[] = {
	{ DRM_MODE_PANEL_TYPE_UNKNOWN, "unknown" },
	{ DRM_MODE_PANEL_TYPE_OLED, "OLED" },
};
```

Without adding `{ DRM_MODE_PANEL_TYPE_LCD, "LCD" }` to this list, the panel type property will never report LCD to userspace. If LCD is meant to be internal-only, it shouldn't be in `include/uapi/drm/drm_mode.h`. If it's meant to be exposed, the enum list needs updating.

**`did_panel_type` field:** Adding a `u8` to `drm_display_info` is fine. The reset in `drm_reset_display_info()` is correct.

**Version gate:** The check `displayid_version(&iter) == DISPLAY_ID_STRUCTURE_VER_20` before parsing the block is correct — tag 0x21 is only valid in DisplayID v2.x.

---

---
Generated by Claude Code Patch Reviewer