From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/nouveau: avoid -Wtautological-constant-out-of-range-compare warning Date: Mon, 09 Mar 2026 08:46:20 +1000 Message-ID: In-Reply-To: <20260306150650.465132-1-arnd@kernel.org> References: <20260306150650.465132-1-arnd@kernel.org> <20260306150650.465132-1-arnd@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Problem**: On 32-bit platforms, `dma_addr_t` is `u32`, so comparing it ag= ainst `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` =E2= =80=94 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 =E2=80=94 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 co= rrectly 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 convers= ion, but it is safe because the stored value always originated from `dma_ma= p_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_MA= SK(52))`), which would preserve the `dma_addr_t` semantics. However, the co= mmit message explicitly acknowledges this trade-off and prefers the less in= vasive single-line change over modifying multiple `WARN_ON()` sites across = several files. That's a fair engineering judgment. **No correctness issues found.**=20 Reviewed-by is appropriate. --- Generated by Claude Code Patch Reviewer