Claude review: rust: devres: return reference in `devres::register`

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

Patch Review

This patch changes `devres::register` to return `Result<&'a T>` instead of `Result`, tying the returned reference's lifetime to the `&'a Device<Bound>`.

The core change:

```rust
+pub fn register<'a, T, E>(
+    dev: &'a Device<Bound>,
+    data: impl PinInit<T, E>,
+    flags: Flags,
+) -> Result<&'a T>
...
+    let data_ptr = &raw const *data;
+
     register_foreign(dev, data)
+        // SAFETY: `dev` is valid for the lifetime of 'a. As long as there is a reference to
+        // `Device<Bound>`, it is guaranteed that the device is not unbound and data has not been
+        // dropped. Thus `data_ptr` is also valid for the lifetime of 'a.
+        .map(|()| unsafe { &*data_ptr })
```

**Concern: Safety of the returned reference.** The safety comment says "As long as there is a reference to `Device<Bound>`, it is guaranteed that the device is not unbound and data has not been dropped." This is the critical invariant. After `register_foreign` moves ownership of `data` (the `KBox`) to the devres system, dereferencing `data_ptr` is only valid if the devres entry outlives `'a`. The argument is that `'a` is tied to `&Device<Bound>`, and `Bound` state guarantees the device won't be unbound (and hence devres won't fire) during that lifetime. This seems sound given the Rust driver model's `Bound` guarantees, but this is a subtle invariant that deserves scrutiny from the Rust-for-Linux maintainers, particularly regarding whether any path could trigger devres cleanup while a `&Device<Bound>` still exists.

The callers (`cpufreq.rs`, `drm/driver.rs`) are updated to discard the new return value with `?; Ok(())`, which is straightforward and correct.

**Nit:** The raw pointer `data_ptr` is taken before `register_foreign` moves `data`. Since `register_foreign` takes `data: P` by value (a `Pin<KBox<T>>`), the pointer remains valid only because register_foreign stores it in devres. The ordering is correct, but worth calling out in the safety comment that `data_ptr` points into the `KBox`-allocated memory which `register_foreign` takes ownership of.

---
Generated by Claude Code Patch Reviewer