Claude review: gpu: fix module_init() usage

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

Overall Series Review

Subject: gpu: fix module_init() usage
Author: Koen Koning <koen.koning@linux.intel.com>
Patches: 23
Reviewed: 2026-02-23T06:25:10.056015

---

This is a 3-patch series (v3) from Koen Koning that changes `module_init()` to `subsys_initcall()` in three places: the GPU buddy allocator, the DRM scheduler fence slab, and the DRM core driver init. The motivation is that `module_init()` compiles to `device_initcall()` for built-in code, and the initialization order within the same initcall level depends on Makefile link order. A recent refactoring that moved the buddy allocator from `drivers/gpu/drm/` to `drivers/gpu/` changed the link order, causing a NULL pointer dereference when xe was built-in.

The series itself is straightforward -- each patch is a one-line change from `module_init()` to `subsys_initcall()`. The patches are technically correct in that they will resolve the initialization ordering issue. However, the approach is controversial, as seen in the mailing list discussion. Greg KH pushed back, noting that Makefile link order is reliable and intentional, and that initcall levels are coarse -- if other subsystem infrastructure starts using `subsys_initcall()`, ordering conflicts between them would arise. Danilo Krummrich (who originally suggested the approach) later acknowledged he gave wrong advice and that Makefile ordering is sufficient within the same subsystem.

The core tension is between the v1 approach (fix Makefile ordering for buddy) and the v3 approach (promote three modules to `subsys_initcall`). The v1 approach fixes the actual regression with minimal blast radius. The v3 approach is more defensive but promotes infrastructure code to a different initcall level, which has its own ordering risks and creates an inconsistency with how other in-tree subsystem infrastructure handles this.

---
Generated by Claude Code Patch Reviewer