drivers/base/firmware_loader/Kconfig
Source file repositories/reference/linux-study-clean/drivers/base/firmware_loader/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/base/firmware_loader/Kconfig- Extension
[no extension]- Size
- 9793 bytes
- Lines
- 240
- Domain
- Driver Families
- Bucket
- drivers/base
- Inferred role
- Driver Families: build/configuration rule
- Status
- atlas-only
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0
menu "Firmware loader"
config FW_LOADER
tristate "Firmware loading facility" if EXPERT
select CRYPTO_LIB_SHA256 if FW_LOADER_DEBUG
default y
help
This enables the firmware loading facility in the kernel. The kernel
will first look for built-in firmware, if it has any. Next, it will
look for the requested firmware in a series of filesystem paths:
o firmware_class path module parameter or kernel boot param
o /lib/firmware/updates/UTS_RELEASE
o /lib/firmware/updates
o /lib/firmware/UTS_RELEASE
o /lib/firmware
Enabling this feature only increases your kernel image by about
828 bytes, enable this option unless you are certain you don't
need firmware.
You typically want this built-in (=y) but you can also enable this
as a module, in which case the firmware_class module will be built.
You also want to be sure to enable this built-in if you are going to
enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
config FW_LOADER_DEBUG
bool "Log filenames and checksums for loaded firmware"
depends on DYNAMIC_DEBUG
depends on FW_LOADER
default FW_LOADER
help
Select this option to use dynamic debug to log firmware filenames and
SHA256 checksums to the kernel log for each firmware file that is
loaded.
config RUST_FW_LOADER_ABSTRACTIONS
bool "Rust Firmware Loader abstractions"
depends on RUST
select FW_LOADER
help
This enables the Rust abstractions for the firmware loader API.
if FW_LOADER
config FW_LOADER_PAGED_BUF
bool
config FW_LOADER_SYSFS
bool
config EXTRA_FIRMWARE
string "Build named firmware blobs into the kernel binary"
help
Device drivers which require firmware can typically deal with
having the kernel load firmware from the various supported
/lib/firmware/ paths. This option enables you to build into the
kernel firmware files. Built-in firmware searches are preceded
over firmware lookups using your filesystem over the supported
/lib/firmware paths documented on CONFIG_FW_LOADER.
This may be useful for testing or if the firmware is required early on
in boot and cannot rely on the firmware being placed in an initrd or
initramfs.
This option is a string and takes the (space-separated) names of the
firmware files -- the same names that appear in MODULE_FIRMWARE()
and request_firmware() in the source. These files should exist under
the directory specified by the EXTRA_FIRMWARE_DIR option, which is
Annotation
- Atlas domain: Driver Families / drivers/base.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.