Claude review: drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered

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

Patch Review

**Assessment: Good.**

This patch moves the `addr_regs` bitmap initialization loop before `host1x_client_register()` in both `gr2d_probe()` and `gr3d_probe()`.

The change is correct. The `addr_regs` bitmap is consulted by `gr2d_is_addr_reg()` / `gr3d_is_addr_reg()` during job submission to determine which registers contain buffer addresses and must be validated/relocated. Leaving this uninitialized after registration means an early job submission could bypass address validation — a correctness and potentially security-relevant issue.

**Minor nit on the commit message:** The commit says:

> The host1x_client_register() function is called just prior to register map initialization loop, making the device available to userspace. This may result in userspace attempting to submits a job before the register map is initialized.

The actual path from `host1x_client_register()` to userspace job submission is not direct — it requires the `init` callback to fire (which creates the channel and registers with DRM), then userspace must open the device and submit. So the race window described in the commit message is slightly overstated. In practice, the `init` callback firing synchronously during registration would be needed. That said, the fix is still the right thing to do — initialization should precede registration as a matter of defensive coding.

The diff is clean and mechanical — pure code motion, no behavioral change beyond ordering.

---
Generated by Claude Code Patch Reviewer