Claude review: rust: drm: gem: shmem: Add vmap functions

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

Patch Review

**Generally well-structured.** The `make_vmap` → `vmap`/`owned_vmap` pattern with the generic `R: Deref<Target = Self> + From<&'a Self>` is clean and avoids code duplication.

**Lock/unlock sequencing in `make_vmap` looks correct:**
```rust
let guard = DmaResvGuard::new(self);
to_result(unsafe {
    bindings::drm_gem_shmem_vmap_locked(self.as_raw_shmem(), map.as_mut_ptr())
})?;
drop(guard);
```
The explicit `drop(guard)` before the iomem check + potential `raw_vunmap` is necessary since `raw_vunmap` re-acquires the lock. Good.

**`ENOTSUPP` for iomem:** The XXX comment acknowledges this limitation. `ENOTSUPP` vs `EOPNOTSUPP` — kernel convention typically uses `EOPNOTSUPP` for userspace-facing errors and `ENOTSUPP` for internal use. Since this is an internal Rust API, `ENOTSUPP` is acceptable but worth confirming intent.

**`IoCapable` macro — raw pointer casts from `usize`:**
```rust
unsafe fn io_read(&self, address: usize) -> $ty {
    let ptr = address as *mut $ty;
    unsafe { ptr::read(ptr) }
}
```
The `address` is a raw kernel virtual address cast from the `Io` trait's `addr()`. The safety contract is documented via `Io` trait bounds. This follows the existing kernel `Io` pattern so it's fine.

**Test coverage is good.** The `compile_time_vmap_sizes` test validates the SIZE invariant, and `vmap_io` exercises read/write paths including cross-type verification (write u32 then read individual u8 bytes).

**Byte-order assumption in test:**
```rust
vmap.write32(0xFFFFFFFF, 0x20);
assert_eq!(vmap.read8(0x20), 0xFF);
```
This works for `0xFFFFFFFF` regardless of endianness, but the pattern would be fragile for other values. Since all bytes are `0xFF` here, it's fine.

---
Generated by Claude Code Patch Reviewer