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/vmwgfx: Determine lock-waiting timeout from vblank state Date: Tue, 28 Apr 2026 14:31:50 +1000 Message-ID: In-Reply-To: <20260427150250.699768-2-tzimmermann@suse.de> References: <20260427150250.699768-1-tzimmermann@suse.de> <20260427150250.699768-2-tzimmermann@suse.de> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Purpose:** Switches `vmw_vkms_lock_max_wait_ns()` from reading `du->vkms.= period_ns` (the hrtimer period) to reading `vblank->framedur_ns` from the D= RM vblank core. This decouples the lock timeout from the timer implementati= on details. **Assessment: Looks good.** The change from: ```c s64 nsecs =3D ktime_to_ns(du->vkms.period_ns); return (nsecs > 0) ? nsecs : 16666666; ``` to: ```c struct drm_vblank_crtc *vblank =3D drm_crtc_vblank_crtc(crtc); if (!vblank || !vblank->framedur_ns) return NSEC_PER_SEC / 60; return vblank->framedur_ns; ``` is semantically equivalent. The fallback value `NSEC_PER_SEC / 60 =3D 16666= 666` matches the old hardcoded `16666666`. **Minor observation:** `drm_crtc_vblank_crtc()` is a simple index into `dev= ->vblank`, which is allocated by `drm_vblank_init()`. The `!vblank` check i= s defensive =E2=80=94 in practice, if `drm_vblank_init()` succeeded (which = is required for `vkms_enabled` to be true), this shouldn't be NULL. But it'= s harmless and provides safety if the function is called before vblank init= , which is reasonable. No issues. --- --- Generated by Claude Code Patch Reviewer