From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Re: [PATCH] gpu: Fix uninitialized buddy for built-in drivers Date: Mon, 23 Feb 2026 06:25:10 +1000 Message-ID: In-Reply-To: <9ed1ed4f-5942-4e59-ad68-c038cb83c755@intel.com> References: <20260219213858.370675-1-koen.koning@linux.intel.com> <9ed1ed4f-5942-4e59-ad68-c038cb83c755@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review > -module_init(drm_core_init); > +subsys_initcall(drm_core_init); This changes the DRM core initialization from `module_init()` (= `device_initcall()` when built-in) to `subsys_initcall()`. The DRM core init has existed with `module_init()` since before the git history, and has never caused an issue because `drm_drv.c` is linked early within `drivers/gpu/drm/`. No `Fixes:` tag or `Cc: stable` is included, which is appropriate given the discussion and that this has never caused an issue. However, `drm_core_init()` does quite a bit of work -- it registers device classes, creates debugfs entries, registers sysctl tables, initializes the panic handler, and more. Promoting this to `subsys_initcall()` means all of this runs earlier in boot. While unlikely to cause problems, it changes the ordering relative to other `subsys_initcall()` users that may have their own ordering assumptions. This is exactly the concern Greg KH raised about initcall levels being coarse. There is also an ordering question between this patch and patch 1: if both buddy and drm_core use `subsys_initcall()`, their relative ordering within that level falls back to... Makefile link order. So for these two patches to work correctly relative to each other, the Makefile ordering still matters. This somewhat undermines the stated goal of not relying on Makefile ordering. --- Generated by Claude Code Patch Reviewer