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: Sun, 12 Apr 2026 08:49:37 +1000 Message-ID: In-Reply-To: <20260411185756.1887119-4-mcanal@igalia.com> References: <20260411185756.1887119-4-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: 1 Reviewed: 2026-04-12T08:49:37.991345 --- This is a single-patch documentation-only change to the `dma_fence_init()` = and `dma_fence_init64()` kerneldoc comments in `drivers/dma-buf/dma-fence.c= `. The change is small, well-motivated, and technically accurate. The existing wording says a shared lock prevents fences "from signaling out= of order," which implies the lock somehow enforces ordering. As the author= correctly notes, a spinlock cannot enforce ordering =E2=80=94 it can only = serialize. The driver is still responsible for signaling fences in the corr= ect order. What the shared lock *does* provide is that an observer holding = the lock will never see a state where a later fence is signaled while an ea= rlier one is not (because the signaling operations are serialized under the= same lock). The new wording is a clear improvement. No functional code is changed. **Verdict: Looks good.** --- Generated by Claude Code Patch Reviewer