[PATCH] drm/nouveau: avoid -Wtautological-constant-out-of-range-compare warning

[PATCH] drm/nouveau: avoid -Wtautological-constant-out-of-range-compare warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Checking a large 64-bit constant against a 32-bit dma_addr_t produces a harmless
compiler output when extra warnings are enabled, but leads to a build failure
with -Werror:

drivers/gpu/drm/nouveau/nvkm/subdev/fb/gb202.c:17:37: error: result of comparison of constant 4503599627370495 with expression of type 'dma_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
   17 |         WARN_ON(fb->sysmem.flush_page_addr > DMA_BIT_MASK(52));

As the calculations of sysmem.flush_page_addr are mostly done on u64 types anyway,
change the struct member to the same type. This feels less invasive than changing
each WARN_ON() to add an extra cast or extended condition to shut up the warning.

Fixes: 31d3354f42c0 ("drm/nouveau: verify that hardware supports the flush page address")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
index e0d777a933e1..7b932449606b 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
@@ -38,7 +38,7 @@ struct nvkm_fb {
 
 	struct {
 		struct page *flush_page;
-		dma_addr_t flush_page_addr;
+		u64 flush_page_addr;
 	} sysmem;
 
 	struct nvkm_ram *ram;
-- 
2.39.5

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

[Claude Code Review Bot]

Overall Series Review

Subject: drm/nouveau: avoid -Wtautological-constant-out-of-range-compare warning
Author: Arnd Bergmann <arnd@kernel.org>
Patches: 1
Reviewed: 2026-03-09T08:46:20.335892

---

This is a single-patch fix from Arnd Bergmann addressing a `-Wtautological-constant-out-of-range-compare` warning (turned into an error with `-Werror`) on 32-bit builds. The approach changes `flush_page_addr` from `dma_addr_t` to `u64` to eliminate comparisons of a 32-bit type against 64-bit `DMA_BIT_MASK(52)` constants. The fix is reasonable and the commit message is well-written with a proper Fixes tag.

**Verdict: Acceptable with minor concern noted below.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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