Overview and Implementation Mechanisms of the Linux Firmware Subsystem

Firmware is a program stored in the flash of a hardware device that runs on the device itself. In Linux kernel development, drivers (e.g., for touch, charging, motor, storage, Wi‑Fi) often need to load firmware, which resides in user space while the driver runs in kernel space. A reliable mechanism is required to transfer the firmware from user space to the kernel.

The Linux kernel provides a Firmware Subsystem to solve this problem. The subsystem is built on sysfs and the uevent mechanism. When a driver calls the firmware API, the subsystem tries several methods in order:

Load a firmware that has been compiled into the kernel image.

Load a firmware that is cached in the global fw_cache list.

Search the default firmware directories defined by the kernel.

If all above fail, send a uevent to the init process.

The init process receives the uevent , filters messages whose subsystem is "firmware", and writes the firmware data into the appropriate sysfs nodes under /sys/class/firmware . The driver then reads the data from kernel space.

Key function interfaces include:

request_firmware – synchronous request.

request_firmware_direct – searches only the kernel‑specified path, bypassing uevent .

request_firmware_nowait – asynchronous request using a workqueue.

release_firmware – frees the firmware memory.

The implementation of request_firmware proceeds through _request_firmware_prepare , which checks the CONFIG_FW_LOADER option, calls fw_get_builtin_firmware to see if the firmware is built‑in, then uses fw_lookup_and_allocate_buf to manage the cache. If the firmware is not built‑in, fw_get_filesystem_firmware attempts to read it from the default paths via kernel_read_file_from_path . When the FW_OPT_USERHELPER flag is set, the USER_HELPER mode is used.

In USER_HELPER mode, after CONFIG_FW_LOADER_USER_HELPER is enabled, the kernel sends a uevent to the init process. The init process creates a device under /sys/class/firmware with attributes:

loading – set to 1 when loading starts, 0 when finished, -1 on error.

data – receives the firmware binary.

device – symlink to the corresponding device node.

timeout – default 60 seconds, configurable.

After the user‑space helper writes the firmware data, the kernel’s request_firmware flow continues by enabling uevent reporting, calling kobject_uevent with an "add" action, and waiting for the user‑space side to complete via fw_state_wait_timeout . If the timeout expires or the operation completes, the kernel releases the allocated resources.

The ueventd daemon (part of the init process) handles the firmware uevent . Its FirmwareHandler checks that the subsystem field is "firmware", then creates worker threads to process each driver’s request. The ProcessFirmwareEvent function writes the firmware file into the loading and data attributes, signalling the kernel that the firmware is ready.

Default firmware search paths are defined in ueventd.rc via the firmware_directory entries. The article references the official kernel documentation for further details: https://www.kernel.org/doc/html/v4.13/driver-api/firmware/index.html.