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/atomic: Call complete_signaling only if prepare_signaling is done Date: Tue, 24 Feb 2026 10:26:59 +1000 Message-ID: In-Reply-To: <20260223-atomic-v10-3-f59c8def2e70@intel.com> References: <20260223-atomic-v10-0-f59c8def2e70@intel.com> <20260223-atomic-v10-3-f59c8def2e70@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review > - unsigned int i, j, num_fences; > + unsigned int i, j, num_fences = 0; > - complete_signaling(dev, state, fence_state, num_fences, !ret); > + if (num_fences) > + complete_signaling(dev, state, fence_state, num_fences, !ret); This change is correct in isolation. Before this series, `complete_signaling` was always called after `prepare_signaling`. With the state allocation moved earlier (patch 4), early `goto out` paths can reach the cleanup before `prepare_signaling` runs. Initializing `num_fences = 0` and guarding the call is the right approach. I verified that `complete_signaling` cleans up both fence state and crtc events. When `prepare_signaling` was never called, there are no events or fences to clean up, so skipping the call when `num_fences == 0` is safe. The events and fences are only created together in `prepare_signaling`, and `num_fences` is incremented for each one. No issues found in this patch. --- Generated by Claude Code Patch Reviewer