Claude review: drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic

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

Patch Review

The core of the series. Several observations:

**`do_div` usage:** `do_div` modifies its first argument in-place (it's a macro that assigns the quotient back). The code uses it correctly for the divisibility check (checking the remainder), but it's worth noting that `va_diff` is modified in the can_merge path:

```c
+		if (do_div(va_diff, a->gem.repeat_range))
+			return false;
```

This is fine since `va_diff` isn't used after.

**`repeat_range` as u32 but comparisons with u64:** The `gem.repeat_range` field is `u32` in `drm_gpuva` and `drm_gpuva_op_map`, but `va.range` is `u64`. The `do_div` macro on 32-bit architectures expects a u32 divisor, which is satisfied here. However, in `validate_map_request`:

```c
+		if (unlikely(!op->gem.repeat_range ||
+			     va_range < op->gem.repeat_range ||
+			     do_div(va_range, op->gem.repeat_range)))
```

`va_range` is modified by `do_div` to contain the quotient -- this is intentional since it's only used for the check. Fine.

**DRM_GPUVA_USERBITS shift:** Moving `DRM_GPUVA_USERBITS` from `(1 << 2)` to `(1 << 3)` is a kernel-internal change. As long as no userspace driver depends on this value (which it shouldn't since it's not UAPI), this is fine.

The offset handling for repeated mappings is the critical logic -- when splitting a repeated VA, the GEM offset stays the same (offset + 0) rather than advancing. This is correct for the semantics: each repetition starts at the same BO offset.

---
Generated by Claude Code Patch Reviewer