Claude review: drm/nouveau: avoid -Wtautological-constant-out-of-range-compare warning

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

Patch Review

**Problem**: On 32-bit platforms, `dma_addr_t` is `u32`, so comparing it against `DMA_BIT_MASK(52)` (a 52-bit constant) is always false and triggers a clang warning/error.

**Fix analysis**: The field is changed from `dma_addr_t` to `u64`:

```c
-		dma_addr_t flush_page_addr;
+		u64 flush_page_addr;
```

I checked all usage sites and the change is functionally safe:

- **Assignment** (`base.c:286`): `dma_map_page()` returns `dma_addr_t` — widening to `u64` is fine.
- **Comparisons** (`nv50.c:218`, `gf100.c:84`, `gh100.c:17`, `gb202.c:17`, `gb100.c:19`): These `DMA_BIT_MASK()` checks now operate on a `u64`, which is the desired behavior — the checks become meaningful rather than tautological.
- **Bit operations** (`nv50.c:220`, `gf100.c:86`, `gh100.c:13`, `gb100.c:13-14`, `gb202.c:14`): Shifts and `upper_32_bits`/`lower_32_bits` all work correctly on `u64`.
- **dma_unmap_page** (`base.c:251`): This expects a `dma_addr_t` argument. Passing a `u64` when `dma_addr_t` is `u32` is an implicit narrowing conversion, but it is safe because the stored value always originated from `dma_map_page()` and fits in `dma_addr_t`.

**Minor concern**: The type change loses the semantic annotation that this field holds a DMA address. An alternative would be to cast in the `WARN_ON()` expressions (e.g., `WARN_ON((u64)fb->sysmem.flush_page_addr > DMA_BIT_MASK(52))`), which would preserve the `dma_addr_t` semantics. However, the commit message explicitly acknowledges this trade-off and prefers the less invasive single-line change over modifying multiple `WARN_ON()` sites across several files. That's a fair engineering judgment.

**No correctness issues found.** 

Reviewed-by is appropriate.

---
Generated by Claude Code Patch Reviewer