Claude review: drivers/gpu/drm/drm_print: fix drm_printer dynamic debug bypass

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

Patch Review

**Problem analysis**: Correct and well-explained. Under `CONFIG_DRM_USE_DYNAMIC_DEBUG=Y`, `__drm_debug_enabled(category)` expands to `true` (confirmed at `linux/include/drm/drm_print.h:161`). Since `__drm_printfn_dbg()` is a shared helper not behind a dyndbg static-key guard, using `__drm_debug_enabled()` means the check is always bypassed, causing all debug output to print.

**First hunk** (line 474-475):
```c
-	if (!__drm_debug_enabled(category))
+	if (!drm_debug_enabled_instrumented(category))
```
**Concern**: `drm_debug_enabled_instrumented()` includes a `pr_debug("todo: is this frequent enough to optimize ?\n")` call (confirmed at `linux/include/drm/drm_print.h:149-153`). This is a debugging/instrumentation macro that was clearly intended for development purposes — it emits a `pr_debug` on every invocation. While the commit message acknowledges this ("It also adds a pr_debug() to help track the frequency of this bit-test"), using an instrumentation/development macro in production code is questionable. This `pr_debug` could itself become a performance issue if someone enables it, and the "todo:" text in the pr_debug string suggests it's not meant for permanent use.

**Recommendation**: Use `drm_debug_enabled()` here instead. Under `CONFIG_DRM_USE_DYNAMIC_DEBUG=Y`, `drm_debug_enabled()` is already defined as `drm_debug_enabled_instrumented()` (line 162), but under the `!CONFIG_DRM_USE_DYNAMIC_DEBUG` path, it maps to `drm_debug_enabled_raw()` which is the simple bitmask check without the pr_debug overhead. However, the real fix for `__drm_printfn_dbg()` is just to use `drm_debug_enabled()` — both paths do a real bitmask check, which is exactly what's needed here.

Actually, looking more carefully: `drm_debug_enabled()` under `CONFIG_DRM_USE_DYNAMIC_DEBUG=Y` already equals `drm_debug_enabled_instrumented()`, so using `drm_debug_enabled()` would give the same result but is the canonical API. Using `drm_debug_enabled_instrumented()` directly bypasses the abstraction and couples the code to an internal implementation detail.

**Second hunk** (line 483-484):
```c
-	if (!__drm_debug_enabled(category))
+	if (!drm_debug_enabled(category))
```
This change to `__drm_dev_dbg()` is correct and harmless. As the commit message notes, `__drm_dev_dbg()` is wrapped by dyndbg so the `__drm_debug_enabled()` → `true` shortcut is actually valid there. But switching to `drm_debug_enabled()` adds a redundant (but cheap) bitmask check and is cleaner. Fine as-is.

**Overall for patch 2**: The fix is correct in principle but the first hunk should use `drm_debug_enabled()` rather than `drm_debug_enabled_instrumented()`. The `_instrumented` variant with its embedded `pr_debug("todo: ...")` is clearly a temporary diagnostic tool, not something that should be baked into production code paths.

---
Generated by Claude Code Patch Reviewer