Claude review: drm/nouveau: handle nouveau_hw_get_clock() return value

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

Patch Review

**Correctness concern — uninitialized output parameters on early return:**

```c
if (MClk <= 0 || NVClk <= 0)
    return;
```

When this early return is taken, `nv04_update_arb()` never writes to `*burst` or `*lwm`. The only caller path through `nouveau_calc_arb()` reaching this code is in `crtc.c`:

```c
int arb_burst, arb_lwm;            /* line 848 — uninitialized */
nouveau_calc_arb(dev, crtc->mode.clock, drm_fb->format->cpp[0] * 8,
                 &arb_burst, &arb_lwm);
regp->CRTC[NV_CIO_CRE_FF_INDEX] = arb_burst;       /* used uninitialized */
regp->CRTC[NV_CIO_CRE_FFLWM__INDEX] = arb_lwm & 0xff;  /* used uninitialized */
```

This writes garbage stack data to hardware CRTC registers. The fix should set `*burst` and `*lwm` to safe defaults (e.g., 0) before returning, or the function signature should be changed to return an error that the caller checks.

The simplest fix would be:

```c
if (MClk <= 0 || NVClk <= 0) {
    *burst = 0;
    *lwm = 0;
    return;
}
```

**Minor: the `<= 0` check conflates two cases.** `nouveau_hw_get_clock()` can return:
- `0` — from `nouveau_hw_pllvals_to_clk()` when M1 or M2 is zero
- A negative errno (e.g., `-ENOENT`) — from `nouveau_hw_get_pllvals()` failure

The `<= 0` check correctly catches both, so the logic is sound, but the commit message claims to "fix all this by adding a check" when the real root cause (propagating error codes properly from `nouveau_hw_get_clock`) remains unfixed. This is acceptable for a targeted defensive fix, but worth noting.

**Commit message nit:** The Fixes tag references `6ee738610f41` ("drm/nouveau: Add DRM driver for NVIDIA GPUs"), which is the initial nouveau commit. While technically correct that the bug has existed since then, it would be more useful to reference the commit that introduced this specific code path if one exists, since the Fixes tag drives stable-kernel backport decisions.

**Summary:** The identified bug (division by zero) is real and worth fixing. The patch needs a small revision to initialize the output parameters before the early return to avoid writing uninitialized values to hardware registers.

---
Generated by Claude Code Patch Reviewer