From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/atomic: Drop private obj state allocation Date: Sun, 22 Mar 2026 03:32:28 +1000 Message-ID: In-Reply-To: <20260320-drm-mode-config-init-v2-16-c63f1134e76c@kernel.org> References: <20260320-drm-mode-config-init-v2-0-c63f1134e76c@kernel.org> <20260320-drm-mode-config-init-v2-16-c63f1134e76c@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Removes the `atomic_create_state` call from `drm_atomic_private_obj_init()` since `drm_mode_config_create_state()` (called from `drm_dev_register()`) now handles it. **Potential ordering concern**: `drm_atomic_private_obj_init()` may be called before `drm_dev_register()`. Between these calls, `obj->state` will be NULL. If any code accesses `obj->state` during driver setup (between init and register), this would crash. The patch relies on `drm_mode_config_create_state()` checking `if (privobj->state) continue;` which is fine for the new flow, but could break drivers that currently depend on the state being available immediately after `drm_atomic_private_obj_init()`. The current tree already has the `atomic_create_state` call inside `drm_atomic_private_obj_init` -- removing it changes the contract for all callers. This is a semantic change that should be called out more explicitly and might need a wider audit of callers. Also note: `drm_atomic_private_obj_fini()` unconditionally calls `obj->funcs->atomic_destroy_state(obj, obj->state)` -- if `obj->state` is NULL at teardown time (e.g., if `drm_dev_register` is never called after init), this will crash. --- Generated by Claude Code Patch Reviewer