On Thu, 2026-02-19 at 13:56 +0100, Danilo Krummrich wrote: > On Thu Feb 19, 2026 at 1:44 PM CET, Matthew Auld wrote: > > On 19/02/2026 11:14, Danilo Krummrich wrote: > > > However, I think it was never meant to rely on a build system > > > implementation > > > detail, nor would this be correct. So, I think this should add > > > both Fixes: tags. > > > > Yeah, I'm really not sure tbh. From a quick grep there do seem to > > be > > other users relying on this: > > > > drm/drm_drv.c:1274:module_init(drm_core_init); > > drm/scheduler/sched_fence.c:238:module_init(drm_sched_fence_slab_in > > it); > > > > The sched one looks identical with the slab thing. Do these need to > > be > > fixed also? > > Yes, those should be fixed as well. > > Also note that module_init() compiles down to device_initcall() when > built-in, > i.e. the initcall stage that is mainly for drivers, not for subsystem > code. > > Do you want to send a fix for thise as well?
Thanks for your input! The usage in drm_drv.c goes all the way back to before the git history, so I'm not sure there's a Fixes: tag that would make sense there. Do you have a recommendation for how to handle that patch? Overall, I don't think it makes sense to backport these fixes anyway - there's no actual issue unless there's some large refactoring (like what happened with drm/buddy).
