This series fixes several uses of module_init() for subsystem-level code
that can be used by other drivers, and thus must be initialized first.

While this is not a problem for modules, for built-in drivers
module_init() compiles down to a device_initcall(). Between these, the
initialization order depends on the linking order in the Makefiles, but
this behavior should not be depended on.

This series is the result of recent regressions, where moving buddy from
drm to gpu accidentally changed the Makefile linking order, causing NULL
pointer dereferences in drm drivers.

Replacing module_init() with subsys_initcall() resolves these potential
issues for built-ins, while keeping the behavior the same for modules.

While the fixes can be backported, there have never been reports of
issues besides regressions due to refactoring of code. In particular,
the drm_drv module_init() usage predates the git history.

v2->v3: 
https://lore.kernel.org/dri-devel/[email protected]/
 - add patches for other uses of module_init() (drm_dev and drm/sched)
 - reword gpu/buddy commit message

v1->v2:
 - use subsys_initcall instead of relying on (fragile) Makefile ordering

Koen Koning (3):
  gpu/buddy: fix module_init() usage
  drm/sched: fix module_init() usage
  drm/drv: fix module_init() usage

 drivers/gpu/buddy.c                     | 2 +-
 drivers/gpu/drm/drm_drv.c               | 2 +-
 drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--
2.48.1

Reply via email to