Claude review: drm/bridge: it66121: Add bridge-private atomic state

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

Patch Review

**Status: One issue to address.**

The state subclassing is correctly implemented — `kzalloc_obj(*state)` properly allocates a `struct it66121_bridge_state`, and both `it66121_bridge_atomic_duplicate_state` and `it66121_bridge_atomic_reset` correctly call the `__drm_atomic_helper_bridge_*` helpers on `&state->base`.

**Issue: `atomic_destroy_state` still uses `drm_atomic_helper_bridge_destroy_state`.**

```c
 static const struct drm_bridge_funcs it66121_bridge_funcs = {
 	.atomic_duplicate_state = it66121_bridge_atomic_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset = it66121_bridge_atomic_reset,
```

The documentation on `drm_atomic_helper_bridge_destroy_state()` explicitly says: *"This helper is meant to be used as a bridge atomic_destroy_state hook for bridges that don't subclass the bridge state."*

In practice this works because `base` is the first member of `it66121_bridge_state`, so `kfree(&state->base)` is equivalent to `kfree(state)`. And there is precedent (e.g. `dw-dp.c` does the same). However, it's fragile — if someone later adds a member that requires cleanup (e.g., a sub-allocation), the generic destroy won't handle it. I'd recommend adding a trivial custom destroy for correctness:

```c
static void it66121_bridge_atomic_destroy_state(struct drm_bridge *bridge,
                                                struct drm_bridge_state *state)
{
	struct it66121_bridge_state *it66121_state =
		to_it66121_bridge_state(state);

	kfree(it66121_state);
}
```

This is minor but would be the correct pattern given the subclassing.

---
Generated by Claude Code Patch Reviewer