Claude review: drm: Open-code drm_simple_encoder_init() in several drivers

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

Overall Series Review

Subject: drm: Open-code drm_simple_encoder_init() in several drivers
Author: Naman Arora <namanarora029@gmail.com>
Patches: 7
Reviewed: 2026-06-04T15:05:00.305353

---

This is a straightforward, well-structured cleanup series that open-codes `drm_simple_encoder_init()` across six call sites in four drivers. The stated goal is to remove the dependency on `drm_simple_kms_helper` from drivers that only use it for this single trivial wrapper.

Each patch is mechanically identical: define a static `const struct drm_encoder_funcs` with `.destroy = drm_encoder_cleanup`, replace the `drm_simple_encoder_init()` call with `drm_encoder_init()`, and remove the `drm_simple_kms_helper.h` include.

I verified the original implementation in `drm_simple_kms_helper.c:18-29` — it is exactly a wrapper around `drm_encoder_init()` with a `{ .destroy = drm_encoder_cleanup }` funcs struct. All six patches replicate this correctly.

**Concerns:**

1. **Missing motivation for the larger goal.** The cover letter explains *what* but not *why* removing `drm_simple_kms_helper` dependency matters. Is this a precursor to removing `drm_simple_encoder_init()` entirely? Or changing the helper module? The series would benefit from stating the end goal. The `Documentation/gpu/todo.rst` file in the tree lists this cleanup, so it's a known TODO item, but the cover letter should reference that.

2. **Code duplication vs. consolidation.** This series creates six identical `{ .destroy = drm_encoder_cleanup }` structs across six files. An alternative approach would be to move `drm_simple_encoder_init()` into a more lightweight header/module, or just keep using it. However, the todo.rst likely endorses this approach, and the resulting code is trivial enough that duplication is acceptable.

3. **Incomplete series** — these are only 6 of the ~40+ callers of `drm_simple_encoder_init()` in the tree. That's fine as incremental progress, but the cover letter could mention this.

4. **Meson patches 4-6 sent as a sub-thread** — patches 4/6, 5/6, and 6/6 have a different Message-Id series (`20260531074627.8936-*`) vs the main series (`20260531073532.8609-*`). This is a minor submission issue where they were sent as a separate `git send-email` run with different In-Reply-To threading. Not a code issue but can confuse tooling.

Overall: **Low risk, correct transformation.** Series is suitable for merging with minor nits.

---
Generated by Claude Code Patch Reviewer