From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Fix DRM_USE_DYNAMIC_DEBUG=y Date: Sat, 14 Mar 2026 07:00:19 +1000 Message-ID: In-Reply-To: <20260313132103.2529746-1-jim.cromie@gmail.com> References: <20260313132103.2529746-1-jim.cromie@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: Fix DRM_USE_DYNAMIC_DEBUG=y Author: Jim Cromie Patches: 66 Reviewed: 2026-03-14T07:00:19.881421 --- This is a v11, 65-patch series by Jim Cromie to fix `CONFIG_DRM_USE_DYNAMIC_DEBUG=y`, which has been marked `BROKEN` since Feb 2023 (commit `bb2ff6c27bc9`). The root cause was that the original `DECLARE_DYNDBG_CLASSMAP` was invoked redundantly in both drm-core and each driver, violating define-once semantics. The fix introduces a `DEFINE`/`USE` split: `DYNAMIC_DEBUG_CLASSMAP_DEFINE` (once in drm.ko) and `DYNAMIC_DEBUG_CLASSMAP_USE` (in each driver/helper). **Architecture:** The overall design is sound. The DEFINE/USE separation correctly addresses the regression where `drm.debug=0xFF` at boot enabled debug in drm-core but not drivers. The new linker section `__dyndbg_class_users` allows dyndbg to propagate the kernel parameter's initial value to driver modules at load time. **Concerns:** - **Series size and ordering:** 65 patches is very large and arrives out of numbered order in the mbox (patches appear in a different sequence than their numbering). This makes review difficult and risks bisectability issues. - **Patch 23 uses a macro name (`DYNDBG_CLASSMAP_DEFINE`) that doesn't exist until patch 24**, creating a build breakage window in the bisect chain. - **Maintenance burden:** Each DRM driver needs a `DRM_CLASSMAP_USE()` line. New drivers will silently miss it. A mechanism tied to `drm_dev_register()` or a common C file would be preferable long-term. - **Several patches mix cleanup with functional changes**, making review harder (e.g., patch 11 claims "no functional change" but alters observable verbose output). - **Multiple typos in commit messages** and a few actual bugs noted below. The dyndbg core refactoring (patches 1-18) is generally clean. The API changes (19-33) are the architectural heart and are well-designed. The DRM integration (34-65) is mostly mechanical but includes important bug fixes (drm_buddy, drm_print bypass) that arguably should be separate patches. --- Generated by Claude Code Patch Reviewer