From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: dma-fence: Clarify external lock use case in dma_fence_init() docs Date: Thu, 04 Jun 2026 14:48:33 +1000 Message-ID: In-Reply-To: <20260531125115.1136036-1-mcanal@igalia.com> References: <20260531125115.1136036-1-mcanal@igalia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: dma-fence: Clarify external lock use case in dma_fence_init() docs Author: =3D?UTF-8?q?Ma=3DC3=3DADra=3D20Canal?=3D Patches: 2 Reviewed: 2026-06-04T14:48:33.627035 --- This is a single documentation-only patch (v3) that improves the kerneldoc = comments for `dma_fence_init()` and `dma_fence_init64()` in `drivers/dma-bu= f/dma-fence.c`. The motivation is clear and correct: the existing wording (= "prevent multiple fences from signaling out of order") is misleading becaus= e a shared spinlock cannot actually enforce signaling order =E2=80=94 that'= s the driver's responsibility. The patch rewrites the comment to explain th= e *actual* legacy rationale (serializing signaling when no out-of-order sig= naling was possible via `dma_fence_ops.signaled`) and adds a strong "MUST N= OT" prohibition for new users. The patch is well-scoped, addresses only the misleading documentation, and = the de-duplication approach for `dma_fence_init64()` (pointing to `dma_fenc= e_init()` docs rather than repeating the explanation) is sensible. **Verdict: Looks good.** No functional changes, documentation improvement i= s accurate and clearly worded. Minor observations below. --- Generated by Claude Code Patch Reviewer