Linux Firmware Loading: Trace Requested Names, Search Paths and Fallback Behavior

Trace the exact requested firmware name through the selected loader API and the storage available at that moment. Finding a similarly named blob after boot does not prove that the driver could load it during initialization. A direct-load warning may also be an intermediate event before another permitted mechanism succeeds.

This procedure uses upstream Linux v6.12 firmware-loader documentation and implementation. It covers host-side discovery and delivery, not the correctness of firmware executing inside a device. No firmware was replaced, driver was reloaded or hardware reset was performed.

Capture the request, not just the product name

Record the device identity, driver revision, requested string, request API, return value and boot or resume phase. Preserve case, subdirectory components and version suffixes. A product’s firmware package name can differ from the literal string passed by the driver.

Read the request site in matching driver source. Some drivers try several names, treat one image as optional or request separate board data. Distinguish each attempt and its final result. Renaming an unrelated file until an error disappears does not establish that the device received compatible firmware.

The request API guide distinguishes synchronous and asynchronous requests. An asynchronous callback is a later completion boundary, not proof of immediate availability. Record when the device becomes operational after the bytes are delivered; loader success alone is not application readiness.

Check built-in and retained data before filesystem paths

The v6.12 implementation checks for a matching built-in image during request preparation and can reuse an existing firmware object. Consequently, installing a new file under /lib/firmware does not automatically prove that a later request used those new bytes.

The built-in firmware guide describes CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR. Embedding an image can solve an early-boot dependency, but changes require rebuilding the kernel artifact. Distribution permissions, device-specific calibration and image size remain separate constraints.

For a controlled comparison, record whether the image is built in, obtained from filesystem storage or supplied through another supported mechanism. Use a clean, reproducible lifecycle to establish the selected source. A warm device that retains its internal firmware can conceal a missing host-side loading step.

Apply the actual filesystem search order

The v6.12 search-path reference gives this order for filesystem lookup:

1. The optional firmware_class.path override, when configured
2. /lib/firmware/updates followed by the exact kernel release directory
3. /lib/firmware/updates
4. /lib/firmware followed by the exact kernel release directory
5. /lib/firmware

The requested name is appended within that search structure. Compare the actual running kernel release with release-specific directories; a leftover directory for another build is not a match. Inspect a configured override as data, including unintended whitespace, rather than casually replacing it during diagnosis.

The filesystem loader uses the init mount namespace through kernel_read_file_from_path_initns; visibility only inside the requesting process’s container or mount namespace does not establish loader visibility.

Compression adds another implementation boundary. For eligible full requests, v6.12 first tries the uncompressed filesystem search. On ENOENT it can try configured Zstandard support and then XZ support. These are successive searches across the path list, not an assumption that every suffix is tried inside one directory before moving to the next.

Other errors and partial requests do not necessarily follow the same sequence. Verify the exact API and error path before attributing a failure to a missing compressed file. Preserve the file digest and expected firmware identity, not only its location.

Do not assume a userspace fallback exists

The fallback guide distinguishes sysfs-based userspace loading from platform firmware fallback. The available route depends on configuration and request flags. A minimal image may have neither the intended fallback handler nor the storage it needs.

request_firmware_direct deliberately avoids the sysfs userspace fallback. Its name should not be read as a promise to bypass built-in or already available firmware. firmware_request_platform adds the platform-specific fallback path; ordinary requests should not be assumed to search a platform ROM automatically.

For request_firmware_nowait, the uevent argument has specific fallback and cache implications. Do not treat it as a harmless logging preference. Read both the API call and the selected configuration before relying on a userspace helper to rescue a failed lookup.

A warning that direct loading failed is not always the final result. Follow the request through any permitted fallback and the driver’s return handling. Conversely, silence from an optional or warning-suppressed request does not establish successful loading.

Draw an availability timeline

Stage	Evidence to establish
Driver requests image	Exact name, API and initialization phase
Storage becomes accessible	Required filesystem or initramfs content exists at that time
Loader completes	Final result, selected bytes and size
Driver transfers and starts device	Device-specific acceptance and readiness
Resume or reset requests again	Required data remains available through the supported lifecycle

For a hypothetical built-in driver that needs firmware before the final root filesystem is usable, copying a file into that later filesystem cannot solve the timing dependency. Provide it through an appropriate early source or redesign initialization according to the subsystem’s supported model. An arbitrary sleep merely changes the race.

Keep host loading and device retention separate during suspend, warm reboot and cold power-up. The firmware cache has API-specific limits; a successful resume does not prove that a genuinely cold device can initialize from the shipped image.

Use a controlled source-and-timing matrix

1. Verify the intended image and request name in a clean final filesystem or kernel artifact.
2. Test normal cold initialization with complete logs and a recovery connection.
3. In a disposable image, omit only the selected required or optional firmware and verify the documented failure behavior.
4. Compare the supported built-in, initramfs or filesystem arrangements without changing the device firmware version at the same time.
5. Exercise required reset and resume paths and verify a real device operation afterward.

Do not remove firmware from the sole remote-management path on a deployed unit. Keep a recovery image and isolate connected equipment before lifecycle tests. The matrix above is proposed; it supplies no measured startup or timeout values.

Close with the selected bytes and final outcome

Deliver the request-name ledger, path and configuration evidence, availability timeline, firmware digest and device-readiness result. If loading succeeds but the device rejects the image, move to its compatibility and transport diagnostics rather than continuing to edit search paths.

The successful conclusion explains which bytes were obtained, why they were available when needed and what happened afterward. Merely making a firmware warning disappear leaves all three questions unresolved.