Claude review: gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloading

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

Patch Review

This is the core behavioral change. Key observations:

**GSP shutdown implementation** in `boot.rs`:
```rust
+    fn shutdown_gsp(
+        cmdq: &Cmdq,
+        bar: &Bar0,
+        gsp_falcon: &Falcon<Gsp>,
+        mode: commands::PowerStateLevel,
+    ) -> Result<()> {
+        cmdq.send_command(bar, commands::UnloadingGuestDriver::new(mode))?;
+        const LIBOS_INTERRUPT_PROCESSOR_SUSPENDED: u32 = bits::bit_u32(31);
+        read_poll_timeout(
+            || Ok(gsp_falcon.read_mailbox0(bar)),
+            |&mb0| mb0 & LIBOS_INTERRUPT_PROCESSOR_SUSPENDED != 0,
+            Delta::from_millis(10),
+            Delta::from_secs(5),
+        )
+        .map(|_| ())
+    }
```

The 5-second timeout for GSP suspension seems reasonable. The poll checks bit 31 of mailbox0, which aligns with OpenRM's `LIBOS_INTERRUPT_PROCESSOR_SUSPENDED`.

**Error handling in `unload()`** — uses `.inspect_err()` then `?`, meaning a GSP shutdown failure prevents sysmem flush unregistration. But in `gpu.rs`:
```rust
+        let _ = self
+            .gsp
+            .unload(dev, bar, &self.gsp_falcon)
+            .inspect_err(|e| dev_err!(dev, "failed to unload GSP: {:?}\n", e));
+        self.sysmem_flush.unregister(bar);
```
The `let _ =` ensures sysmem flush unregistration always happens regardless of unload failure. This is correct and the comment in the diff confirms this intent.

**PowerStateLevel enum** — uses `#[expect(unused)]` on the enum but only `Level0` is used. The `Level3` and `Level7` variants are for future suspend/hibernate support. This is fine.

**UnloadingGuestDriver command** — the `fw::commands::UnloadingGuestDriver` wrapper uses `#[repr(transparent)]` over the binding struct, which is correct. The `is_power_transition()` method returning `self != Level0` is clear.

**Minor note:** The `UnloadingGuestDriverReply` in `commands.rs` has `type Message = ()` — this means the reply carries no payload. This matches OpenRM behavior where the reply is just an acknowledgment.

No blocking issues. Well implemented.

---

---
Generated by Claude Code Patch Reviewer