On Thu Feb 19, 2026 at 7:28 PM CET, Koen Koning wrote: > 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).
It is always possible to Cc: stable without a Fixes: tag and a brief comment. However, as you say, there was never a report about this actually causing any issues. Obviously, it also can't be an issue for OOT modules. So, a "normal" patch with a brief note that this dates back to the historic tree seems to be sufficient.
