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: add edid_overridden flag to drm_connector Date: Mon, 16 Mar 2026 11:48:51 +1000 Message-ID: In-Reply-To: <20260315223307.45807-2-johanneswueller@gmail.com> References: <20260315223307.45807-1-johanneswueller@gmail.com> <20260315223307.45807-2-johanneswueller@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Approach concern:** The flag is set only inside `_drm_do_get_edid()`, which is the legacy EDID read path. While `drm_edid_read_ddc()` currently chains through `_drm_do_get_edid()`, this is an implementation detail that could change. A more robust approach would be to check at query time whether an override exists (e.g. via `drm_edid_override_get()` or checking `connector->edid_override`), rather than caching a flag that can become stale. **Staleness risk:** The flag is set during EDID read, but nothing clears it if the override is removed between reads. If userspace removes an override via debugfs without triggering a new EDID read, `edid_overridden` remains `true`. The `connector->edid_overridden = false` at line 2376 only runs when `_drm_do_get_edid()` is called again. **Missing Cc:** The patch modifies core DRM infrastructure but doesn't Cc `linux-kernel@vger.kernel.org` in the commit (though it is in the email headers from get_maintainer). More importantly, it would benefit from Cc'ing the DRM misc maintainers explicitly since this touches `drm_connector.h`. **Naming:** `edid_overridden` is reasonable, but `edid_override_active` might be clearer since it describes current state rather than a past-tense event. --- Generated by Claude Code Patch Reviewer