From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: rust: rename `AlwaysRefCounted` to `RefCounted`.
Date: Mon, 23 Feb 2026 06:08:50 +1000
Message-ID: <review-patch2-20260220-unique-ref-v15-2-893ed86b06cc@kernel.org>
In-Reply-To: <20260220-unique-ref-v15-2-893ed86b06cc@kernel.org>
References: <20260220-unique-ref-v15-0-893ed86b06cc@kernel.org> <20260220-unique-ref-v15-2-893ed86b06cc@kernel.org>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

This is a large mechanical rename across 20 files, splitting the old `AlwaysRefCounted` into `RefCounted` (the trait with `inc_ref`/`dec_ref`) and a new marker `AlwaysRefCounted: RefCounted` that permits `&T -> ARef<T>`.

> +/// Implementers must ensure that no safety invariants are violated by upgrading an `&T` to an
> +/// [`ARef<T>`]. In particular that implies [`AlwaysRefCounted`] and [`crate::types::Ownable`]
> +/// cannot be implemented for the same type, as this would allow violating the uniqueness guarantee
> +/// of [`crate::types::Owned<T>`] by dereferencing it into an `&T` and obtaining an [`ARef`] from
> +/// that.
> +pub unsafe trait AlwaysRefCounted: RefCounted {}

The safety documentation here is clear and the rationale for the split is well explained. The mechanical changes across all the driver files look correct -- each existing `AlwaysRefCounted` impl is split into `RefCounted` (with the actual `inc_ref`/`dec_ref`) plus an empty `AlwaysRefCounted` marker.

> +// SAFETY: We currently do not implement `Ownable`, thus it is okay to obtain an `ARef<Request>`
> +// from a `&Request` (but this will change in the future).
> +unsafe impl<T: Operations> AlwaysRefCounted for Request<T> {}

The "but this will change in the future" note is a good heads-up for downstream work.

No issues found in this patch.

---
Generated by Claude Code Patch Reviewer