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: Fri, 27 Feb 2026 15:11:57 +1000
Message-ID: <review-patch3-20260224-unique-ref-v16-3-c21afcb118d3@kernel.org>
In-Reply-To: <20260224-unique-ref-v16-3-c21afcb118d3@kernel.org>
References: <20260224-unique-ref-v16-0-c21afcb118d3@kernel.org> <20260224-unique-ref-v16-3-c21afcb118d3@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. The split into `RefCounted` (methods) and `AlwaysRefCounted` (marker for `&T -> ARef<T>`) is well-motivated.

**Minor concern with SAFETY comments**: Several `AlwaysRefCounted` marker impls use the justification:
```rust
// SAFETY: We do not implement `Ownable`, thus it is okay to obtain an `ARef<Device>` from a
// `&Device`.
```
While correct now, this places the safety burden on a *negative* (not implementing another trait), which could be fragile if someone later adds `Ownable` without remembering to remove `AlwaysRefCounted`. The safety comment in the trait definition does document this correctly, but it's worth noting this is an inherent challenge with marker traits.

**Copy-paste issue in DRM gem**: The safety comment says `ARef<Device>` when it should say `ARef<Object>`:
```rust
// SAFETY: We do not implement `Ownable`, thus it is okay to obtain an `ARef<Device>` from a
// `&Object`.
```
The text mentions both `Device` and `Object` inconsistently. Should be `ARef<Object<T>>` throughout.

Similarly in `i2c.rs`, the I2cAdapter and I2cClient marker impls both say `ARef<Device>` instead of `ARef<I2cAdapter>` / `ARef<I2cClient>`:
```rust
// SAFETY: We do not implement `Ownable`, thus it is okay to obtain an `ARef<Device>` from an
// `&I2cAdapter`.
```

---
Generated by Claude Code Patch Reviewer