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-buf: Change st-dma-resv.c to use kunit Date: Tue, 03 Mar 2026 13:50:31 +1000 Message-ID: In-Reply-To: <1-v1-0a349a394eff+14110-dmabuf_kunit_jgg@nvidia.com> References: <0-v1-0a349a394eff+14110-dmabuf_kunit_jgg@nvidia.com> <1-v1-0a349a394eff+14110-dmabuf_kunit_jgg@nvidia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Good conversion. The change from `static struct spinlock fence_lock;` with a runtime `spin_lock_init()` call (formerly in the deleted `dma_resv()` function) to `static DEFINE_SPINLOCK(fence_lock);` is a correct improvement since the old code relied on `dma_resv()` being called before any test used the lock. The `KUNIT_ARRAY_PARAM_DESC` usage for iterating over `DMA_RESV_USAGE_KERNEL` through `DMA_RESV_USAGE_BOOKKEEP` is clean and idiomatic kunit. **Stray trailing `\n`:** In `test_sanitycheck`, there's an inconsistent trailing newline: ```c KUNIT_FAIL(test, "Resv locking failed\n"); ``` All other `KUNIT_FAIL` calls in this patch (and the entire series) omit the `\n`. Kunit adds its own newline when printing, so this should be removed for consistency. **Dead `r = -EINVAL` assignments:** In `test_for_each` and `test_for_each_unlocked`, some error paths still assign `r = -EINVAL` after `KUNIT_FAIL`: ```c if (f != fence) { KUNIT_FAIL(test, "Unexpected fence"); r = -EINVAL; goto err_unlock; } ``` While the "More than one fence found" path had its `r = -EINVAL` removed. Since the functions are now void and `r` is no longer returned, these surviving assignments are dead code. They're harmless, but the inconsistency is a bit untidy. Consider removing them all, or leaving them all -- pick one. --- Generated by Claude Code Patch Reviewer