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

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

Patch Review

**Status: Looks good with minor notes.**

The struct definition for `displayid_display_params_block` properly lays out all fields per DisplayID 2.1a spec Table 4-7. The payload size calculates correctly:

```
sizeof(displayid_display_params_block) - sizeof(displayid_block) =
(3 + 2+2+2+2+1+9+3+2+2+2+1+1) - 3 = 29 bytes
```

This matches the expected payload for the Display Parameters block.

The length validation is correct:
```c
if (block->num_bytes < sizeof(*params) - sizeof(params->base))
```

The field extraction `FIELD_GET(DISPLAYID_DISPLAY_PARAMS_DEVICE_TECH, params->color_depth_and_tech)` with `GENMASK(6, 4)` correctly extracts bits [6:4] for the device technology field.

The version guard in `update_displayid_info()`:
```c
if (displayid_version(&iter) == DISPLAY_ID_STRUCTURE_VER_20 &&
    block->tag == DATA_BLOCK_2_DISPLAY_PARAMETERS)
```
correctly restricts parsing to DisplayID 2.x only, since the tag value 0x21 has different semantics in DisplayID 1.x.

**Minor notes:**
- The `panel_type` field added to `drm_display_info` stores `DRM_MODE_PANEL_TYPE_*` UAPI values directly. This is consistent with how other UAPI-facing properties are handled in this struct, but it creates a coupling worth noting — if the UAPI enum ever changes numbering, this field must be updated too. In practice this won't happen since UAPI is stable.

- If a DisplayID contains multiple Display Parameters Data Blocks (theoretically possible per spec, though unusual), the last one wins. This seems acceptable.

- The UAPI addition of `DRM_MODE_PANEL_TYPE_LCD = 2` is backwards-compatible. Existing userspace seeing an unknown enum value would already need to handle it gracefully, and the immutable property documentation is updated accordingly.

---
Generated by Claude Code Patch Reviewer