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: Define a conditional guard for drm_dev_{enter,exit}() Date: Sat, 16 May 2026 11:40:45 +1000 Message-ID: In-Reply-To: <20260513-panthor-guard-refactor-v1-3-f2d8c15a97ce@collabora.com> References: <20260513-panthor-guard-refactor-v1-0-f2d8c15a97ce@collabora.com> <20260513-panthor-guard-refactor-v1-3-f2d8c15a97ce@collabora.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 ```c DEFINE_LOCK_GUARD_1(drm_dev, struct drm_device, { WARN_ON("Use cond guards"); _T->idx =3D -1; }, drm_dev_exit(_T->idx), int idx); DEFINE_LOCK_GUARD_1_COND(drm_dev, _access, drm_dev_enter(_T->lock, &_T->idx= )); ``` The base `drm_dev` guard intentionally WARNs if used directly (since `drm_d= ev_enter` can fail, it only makes sense as a conditional guard). The string= `"Use cond guards"` in `WARN_ON()` is a non-zero pointer which will always= evaluate to true =E2=80=94 this means any unconditional `guard(drm_dev)` w= ill always WARN. This is the intended design. However, it would be slightly= cleaner to use `WARN_ON(true)` or `WARN_ON_ONCE(1)` with a comment, since = passing a string to `WARN_ON` is unusual and might confuse readers. Minor s= tyle nit. This also touches shared DRM infrastructure (drm_drv.h) and needs broader a= cks. --- Generated by Claude Code Patch Reviewer