Launch a kernel module on early stages of kernel boot

For Developers
1

I've been working in creating a package for a driver I need to make Wi-Fi work on a target device. I created the package by the following way:

File structure:

├── b43-sprom-driver
│   ├── Makefile
│   └── src
│       ├── b43-sprom-fallback.c
│       └── Makefile

The .c file is just a small driver to create a dummy SPROM for those Broadcom's Wifi chipsets which does not have an SPROM or it can't be read for whatever reason. Can be found here: openwrt/b43-sprom.c at master · openwrt/openwrt (github.com)

This is the Makefile:

#
# Copyright (C) 2020 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#

include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk

PKG_NAME:=b43-sprom-fallback
PKG_RELEASE:=1
PKG_LICENSE:=GPL-2.0

include $(INCLUDE_DIR)/package.mk

define KernelPackage/b43-sprom-fallback
  SECTION:=kernel
  SUBMENU:=B43 SPROM Fallback Driver
  TITLE:=B43 SPROM Fallback Driver
  DEPENDS:= @PCI_SUPPORT +kmod-ssb +kmod-bcma
  FILES:=$(PKG_BUILD_DIR)/b43-sprom-fallback.ko
  KCONFIG:= \
	CONFIG_BCMA=y \
	CONFIG_BCMA_BLOCKIO=y \
	CONFIG_BCMA_DRIVER_PCI=y \
	CONFIG_BCMA_HOST_PCI=y \
	CONFIG_BCMA_HOST_PCI_POSSIBLE=y \
	CONFIG_SSB=y\
	CONFIG_SSB_B43_PCI_BRIDGE=y \
	CONFIG_SSB_BLOCKIO=y \
	CONFIG_SSB_DRIVER_PCICORE=y\
	CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y\
	CONFIG_SSB_PCIHOST=y\
	CONFIG_SSB_PCIHOST_POSSIBLE=y \
	CONFIG_SSB_SPROM=y
  AUTOLOAD:=AUTOLOAD:=$(call AutoLoad,1,b43-sprom-fallback,1)
endef

define KernelPackage/b43-sprom-fallback/description
  Enable B43 Fallback SPROM Driver
endef

define Build/Compile
	$(MAKE) -C "$(LINUX_DIR)" \
		$(KERNEL_MAKE_FLAGS) \
		M="$(PKG_BUILD_DIR)" \
		EXTRA_CFLAGS="$(BUILDFLAGS)" \
		modules
endef

$(eval $(call KernelPackage,b43-sprom-fallback))

And the makefile inside the src:

obj-m += b43-sprom-fallback.o

The module works. But the problem is that I need this module to be initialized in the very begining stage of the kernel boot (after another module). I had another approach which basically was compiling that .c directly into the kernel, and that worked. I just had to use the core_initcall() function and passing by argument the initialization function of the driver, so it will be launched soon. But that won't happen here:

[   12.250182] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[   12.262271] Fallback driver started

The module will be launched by the kmodloader very late. Is there a way I can make this module be launched sooner?

Thanks in advice

2

but why is the better question? You should find why it can't be launched late... Can't you make the dependent driver also a module?

3

The dependant driver is SSB (Silicon Sonics Backplane) which enables support for targets which use this kind of buses.

This was extracted from the ssb source:

/* ssb must be initialized after PCI but before the ssb drivers.
 * That means we must use some initcall between subsys_initcall
 * and device_initcall.
 */

Since this driver is dependant for so many targets, I don't think it would be a good idea to modify it.

4

ok so

  1. pci
  2. ssb
  3. b43 driver

Where the sprom driver should be placed? Between pci and ssb?

5

Correct. When ssb is launching, it will try to phisical access the SPROM. In case it's not possible, the fallback mechanism will be launched. The commented code on ssb explains it better why it should be called before SSB:

/**
 * ssb_arch_register_fallback_sprom - Registers a method providing a
 * fallback SPROM if no SPROM is found.
 *
 * @sprom_callback: The callback function.
 *
 * With this function the architecture implementation may register a
 * callback handler which fills the SPROM data structure. The fallback is
 * only used for PCI based SSB devices, where no valid SPROM can be found
 * in the shadow registers.
 *
 * This function is useful for weird architectures that have a half-assed
 * SSB device hardwired to their PCI bus.
 *
 * Note that it does only work with PCI attached SSB devices. PCMCIA
 * devices currently don't use this fallback.
 * Architectures must provide the SPROM for native SSB devices anyway, so
 * the fallback also isn't used for native devices.
 *
 * This function is available for architecture code, only. So it is not
 * exported.
 */
int ssb_arch_register_fallback_sprom(int (*sprom_callback)(struct ssb_bus *bus,
				     struct ssb_sprom *out))
{
	if (get_fallback_sprom)
		return -EEXIST;
	get_fallback_sprom = sprom_callback;

	return 0;
}