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/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Date: Mon, 25 May 2026 18:26:20 +1000 Message-ID: In-Reply-To: <20260522154356.47588-2-krzysztof.niemiec@intel.com> References: <20260522154356.47588-2-krzysztof.niemiec@intel.com> <20260522154356.47588-2-krzysztof.niemiec@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Verdict: Looks good.** The commit message accurately describes the problem and the fix. I verified= each claim: 1. **`drm_dev_register()` cleans up after itself on failure.** Confirmed in= `drm_drv.c:1115-1123` =E2=80=94 on error, `drm_dev_register()` jumps to `e= rr_minors` which calls `remove_compat_control_link()`, `drm_minor_unregiste= r()` for all three minor types, then returns the error. So calling `drm_dev= _unregister()` after a failed `drm_dev_register()` is indeed double-cleanup. 2. **`drm_client_sysrq_register()` is only called on success.** Confirmed a= t `drm_drv.c:1105` =E2=80=94 `drm_client_sysrq_register(dev)` is called jus= t before the success return, after both `err_unload` and `err_minors` label= s. If `drm_dev_register()` fails, this call never executes. 3. **`drm_client_sysrq_unregister()` triggers a WARN_ON.** Confirmed at `dr= m_client_sysrq.c:58` =E2=80=94 `drm_client_sysrq_unregister()` does `drm_WA= RN_ON(dev, list_empty(&dev->client_sysrq_list))`. Since `drm_client_sysrq_r= egister()` was never called, the list head is in its initialized (empty) st= ate, triggering the warning. 4. **The remaining error path is correct.** After removing the `drm_dev_unr= egister()` call, the error path at `i915_driver.c:639-645` still correctly = unwinds `i915_pmu_register()` and `i915_gem_driver_register()` which were c= alled earlier in the function at lines 632-633. The `intel_vgpu_register()`= at line 635 does not appear to have an unregister counterpart needed in th= is path (it's a no-op on non-VF), so the cleanup sequence is correct. 5. **Additionally, `drm_dev_unregister()` does more than just undo `drm_dev= _register()`** =E2=80=94 it also calls `drm_client_dev_unregister()`, `drm_= modeset_unregister_all()`, and `drm_debugfs_dev_fini()` (`drm_drv.c:1146-11= 66`). Calling these when their corresponding register functions were never = called (because `drm_dev_register()` failed) is wrong and could cause furth= er issues beyond the WARN_ON. No concerns with this patch.=20 Reviewed-by is warranted. --- Generated by Claude Code Patch Reviewer