From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm: detect panel type from DisplayID 2.x Date: Mon, 25 May 2026 22:19:21 +1000 Message-ID: In-Reply-To: <20260520021432.1301326-1-chen-yu.chen@amd.com> References: <20260520021432.1301326-1-chen-yu.chen@amd.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm: detect panel type from DisplayID 2.x Author: Chenyu Chen Patches: 6 Reviewed: 2026-05-25T22:19:21.187117 --- This 3-patch series adds panel type detection from the DisplayID v2.x Displ= ay Parameters Data Block (tag 0x21), resolving a longstanding TODO in amdgp= u_dm. The approach is clean: extract a helper, parse a new block type, wire= it into the driver. The code is well-structured and correctly handles the = detection priority chain (VSDB > DPCD > DisplayID > Samsung heuristic). However, there is one significant UAPI concern: **`DRM_MODE_PANEL_TYPE_LCD`= is added to the UAPI header (`drm_mode.h`) but `drm_panel_type_enum_list` = in `drm_connector.c` is not updated**, so the panel type property can never= report "LCD" to userspace. Additionally, at the end of `dm_set_panel_type(= )`, the existing code only exposes `DRM_MODE_PANEL_TYPE_OLED` via the prope= rty =E2=80=94 anything else becomes `DRM_MODE_PANEL_TYPE_UNKNOWN`. So even = after this series, an LCD panel detected via DisplayID will show as "unknow= n" to userspace. This needs to be either fixed (update the enum list and th= e property-setting logic) or acknowledged as intentional for internal-only = use =E2=80=94 in which case `DRM_MODE_PANEL_TYPE_LCD` should not be in a UA= PI header. There are also minor style issues in Patch 1. --- --- Generated by Claude Code Patch Reviewer