Claude review: rust: drm: Add RegistrationData to drm::Driver

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

This is the most complex patch, involving higher-ranked lifetime (HRL) manipulation.

**ForLt lifetime erasure**: The key transmute:
```rust
let reg_data: Pin<KBox<<T::RegistrationData as ForLt>::Of<'bound>>> =
    KBox::pin_init(reg_data, GFP_KERNEL)?;

let reg_data: Pin<KBox<<T::RegistrationData as ForLt>::Of<'static>>> =
    unsafe { mem::transmute(reg_data) };
```
The safety argument is that `ForLt` guarantees covariance and lifetimes don't affect layout. This is correct: `ForLt::Of<'a>` is guaranteed to have the same representation for all `'a`, and `Pin<KBox<T>>` is `repr(transparent)` over a pointer.

**UnsafeCell for registration_data field**:
```rust
pub(super) registration_data: UnsafeCell<NonNull<<T::RegistrationData as ForLt>::Of<'static>>>,
```
Using `UnsafeCell` here is appropriate since the field is written before registration and read during ioctl dispatch. However, I note that the field is `pub(super)` — this makes it accessible from within the `drm` module but not outside, which is reasonable.

**Initialization with dangling pointer**:
```rust
unsafe { (*raw_drm.as_ptr()).registration_data = UnsafeCell::new(NonNull::dangling()) };
```
This is initialized to a dangling pointer before the real data pointer is stored in `Registration::new()`. The window between `UnregisteredDevice::new()` and `Registration::new()` has a dangling pointer. This is safe because the device isn't registered yet (no ioctls can arrive), but it's worth noting.

**Error handling in Registration::new()**: On failure after `drm_dev_register()`, the code resets the pointer to dangling:
```rust
if let Err(e) = to_result(ret) {
    unsafe { *drm.registration_data.get() = NonNull::dangling() };
    return Err(e);
}
```
This is correct — if registration fails, the caller will drop the `UnregisteredDevice`, and the dangling pointer is never dereferenced.

**Registration::drop ordering concern**: In the drop impl:
```rust
unsafe { bindings::drm_dev_unplug(self.drm.as_raw()) };
// reg_data is dropped here automatically.
```
The SRCU barrier from `drm_dev_unplug()` happens before `reg_data` is dropped, which is correct. The comment documents this. The field drop order in Rust is declaration order (`drm` then `reg_data`), so `drm` would be dropped first... but wait, the manual `drm_dev_unplug()` call is in the explicit `drop()` implementation, and field drops happen *after* the explicit `drop()` body completes. So the actual order is: `drm_dev_unplug()` (in drop body) → `drm` field dropped (ARef put) → `reg_data` field dropped. This is correct.

**devres::register type annotation change**:
```rust
devres::register::<_, core::convert::Infallible>(dev, reg, GFP_KERNEL)?;
```
This explicit `Infallible` type annotation suggests the `devres::register` signature changed to accept a generic error type. This looks like an adaptation to the new `Registration` struct.

**Send/Sync bounds**: The `where for<'a> <T::RegistrationData as ForLt>::Of<'a>: Send` bound is correctly applied to the `impl` block, `Send`, and `Sync` implementations. This ensures registration data is safe to access from any thread.

**The `#[allow(dead_code)]` on reg_data**: This annotation on the `reg_data` field:
```rust
#[allow(dead_code)]
reg_data: Pin<KBox<<T::RegistrationData as ForLt>::Of<'static>>>,
```
This is needed because the field is only read through the raw pointer stored in `Device`, not through the struct field directly. The field exists purely for ownership/drop semantics. Correct usage.

---
Generated by Claude Code Patch Reviewer