Claude review: Revert "drm/imagination: Warn or error on unsupported hardware"

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

Overall Series Review

Subject: Revert "drm/imagination: Warn or error on unsupported hardware"
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Patches: 4
Reviewed: 2026-05-16T15:12:53.518717

---

This is a single patch that reverts commit `1c21f240fbc1e47b` ("drm/imagination: Warn or error on unsupported hardware"). That commit introduced a GPU support allowlist that blocks driver probing on GPU cores not explicitly listed as `PVR_GPU_SUPPORTED` or `PVR_GPU_EXPERIMENTAL`, unless the user sets the `exp_hw_support` module parameter.

The revert is motivated by the fact that Renesas R-Car SoCs (which have PowerVR Rogue GPUs like GX6250 and GE7800) are blocked by this allowlist — their BVNC values are not in the switch statement, so they fall into `PVR_GPU_UNKNOWN` and the driver refuses to probe with `-ENODEV`.

**Assessment:** The patch is technically correct as a revert — it cleanly removes the support-level checking infrastructure and replaces the call with `return 0`. The commit message is well-documented with extensive references to DT bindings, DTS additions, firmware availability, and the power domain fix that unblocked board enablement.

However, the better fix is arguably **not** a full revert but rather adding the Renesas GPU BVNC values to the allowlist. The support-level mechanism was intentionally introduced as a safety gate for the early-stage driver. Reverting it entirely removes protection for truly unknown/untested hardware configurations. That said, the commit message makes a valid argument that the allowlist approach creates ongoing friction for new platform enablement — every new SoC with a PowerVR GPU must also have its BVNC added to the driver's allowlist, which is maintenance burden that doesn't exist in other DRM drivers.

**Recommendation:** This is a policy/design decision for the drm/imagination maintainers. The patch is correct in what it does, but the maintainers should weigh whether to accept the full revert vs. expanding the allowlist. The author has clearly thought about this and chosen the revert deliberately.

---
Generated by Claude Code Patch Reviewer