Claude review: drm/tyr: add firmware loading and MCU boot support

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

Patch Review

**Author:** Deborah Brouwer / Boris Brezillon

This ties everything together: loads firmware, creates MCU VM, maps firmware sections, boots the MCU.

1. The `Firmware::Drop` breaks a circular reference:

```rust
+impl Drop for Firmware {
+    fn drop(&mut self) {
+        self.vm.kill();
+    }
+}
```

This is because the VM -> VmAsData -> Seat -> SlotManager -> SlotData (Arc<VmAsData>) creates a cycle. The `kill()` method deactivates the VM (evicting from slot manager, dropping the Arc<VmAsData>) and then unmaps all regions. This is a necessary but somewhat fragile pattern — if `kill()` fails, the Arc cycle leaks. The error logging in `kill()` mitigates debuggability.

2. `init_section_mem()` writes firmware data byte-by-byte:

```rust
+        for (i, &byte) in data.iter().enumerate() {
+            vmap.try_write8(byte, i)?;
+        }
```

This is functional but slow for large firmware sections. A `memcpy_to_vmap()` or similar bulk operation would be more efficient, but this is a correctness-first approach that can be optimized later.

3. The MCU boot polling has reasonable timeouts:

```rust
+        if let Err(e) = poll::read_poll_timeout(
+            || regs::MCU_STATUS.read(dev, &self.iomem),
+            |status| *status == regs::MCU_STATUS_ENABLED,
+            time::Delta::from_millis(1),
+            time::Delta::from_millis(100),
+        ) {
```

1ms polling interval, 100ms total timeout. This matches the C panthor driver's `panthor_fw_start()` timeouts.

4. The `SectionFlag::CacheModeNone = 0 << 3` is zero, which means `SectionFlags::empty()` and `SectionFlag::CacheModeNone` are indistinguishable. This is by design (the zero cache mode is "none"), but the `impl_flags!` macro may not handle zero-valued flags correctly in `contains()` checks. However, the actual usage only checks `cache_mode != SectionFlag::CacheModeCached.into()`, which works correctly since cached mode is non-zero.

5. The firmware path construction looks correct:

```rust
+        let path = CString::try_from_fmt(fmt!(
+            "arm/mali/arch{}.{}/mali_csffw.bin",
+            gpu_id.arch_major,
+            gpu_id.arch_minor
+        ))?;
```

This matches the C panthor driver's firmware path format.

6. In the probe path, `firmware.boot()` is called before the DRM device is registered (before `try_pin_init!(TyrDrmDeviceData {...})`). This means if boot fails, cleanup is straightforward (no registered device to unregister). Good ordering.

Overall, this is a solid v2 series. The most actionable items are the `AsRegister::new()` validation gap and the slightly convoluted error handling in the firmware parser's `parse_entry()`.

---
Generated by Claude Code Patch Reviewer