123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221 |
- # SPDX-License-Identifier: GPL-2.0
- menu "Firmware loader"
- config FW_LOADER
- tristate "Firmware loading facility" if EXPERT
- 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).
- 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
- /lib/firmware by default.
- For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy
- the usb8388.bin file into /lib/firmware, and build the kernel. Then
- any request_firmware("usb8388.bin") will be satisfied internally
- inside the kernel without ever looking at your filesystem at runtime.
- WARNING: If you include additional firmware files into your binary
- kernel image that are not available under the terms of the GPL,
- then it may be a violation of the GPL to distribute the resulting
- image since it combines both GPL and non-GPL work. You should
- consult a lawyer of your own before distributing such an image.
- NOTE: Compressed files are not supported in EXTRA_FIRMWARE.
- config EXTRA_FIRMWARE_DIR
- string "Firmware blobs root directory"
- depends on EXTRA_FIRMWARE != ""
- default "/lib/firmware"
- help
- This option controls the directory in which the kernel build system
- looks for the firmware files listed in the EXTRA_FIRMWARE option.
- config FW_LOADER_USER_HELPER
- bool "Enable the firmware sysfs fallback mechanism"
- select FW_LOADER_SYSFS
- select FW_LOADER_PAGED_BUF
- help
- This option enables a sysfs loading facility to enable firmware
- loading to the kernel through userspace as a fallback mechanism
- if and only if the kernel's direct filesystem lookup for the
- firmware failed using the different /lib/firmware/ paths, or the
- path specified in the firmware_class path module parameter, or the
- firmware_class path kernel boot parameter if the firmware_class is
- built-in. For details on how to work with the sysfs fallback mechanism
- refer to Documentation/driver-api/firmware/fallback-mechanisms.rst.
- The direct filesystem lookup for firmware is always used first now.
- If the kernel's direct filesystem lookup for firmware fails to find
- the requested firmware a sysfs fallback loading facility is made
- available and userspace is informed about this through uevents.
- The uevent can be suppressed if the driver explicitly requested it,
- this is known as the driver using the custom fallback mechanism.
- If the custom fallback mechanism is used userspace must always
- acknowledge failure to find firmware as the timeout for the fallback
- mechanism is disabled, and failed requests will linger forever.
- This used to be the default firmware loading facility, and udev used
- to listen for uvents to load firmware for the kernel. The firmware
- loading facility functionality in udev has been removed, as such it
- can no longer be relied upon as a fallback mechanism. Linux no longer
- relies on or uses a fallback mechanism in userspace. If you need to
- rely on one refer to the permissively licensed firmwared:
- https://github.com/teg/firmwared
- Since this was the default firmware loading facility at one point,
- old userspace may exist which relies upon it, and as such this
- mechanism can never be removed from the kernel.
- You should only enable this functionality if you are certain you
- require a fallback mechanism and have a userspace mechanism ready to
- load firmware in case it is not found. One main reason for this may
- be if you have drivers which require firmware built-in and for
- whatever reason cannot place the required firmware in initramfs.
- Another reason kernels may have this feature enabled is to support a
- driver which explicitly relies on this fallback mechanism. Only two
- drivers need this today:
- o CONFIG_LEDS_LP55XX_COMMON
- o CONFIG_DELL_RBU
- Outside of supporting the above drivers, another reason for needing
- this may be that your firmware resides outside of the paths the kernel
- looks for and cannot possibly be specified using the firmware_class
- path module parameter or kernel firmware_class path boot parameter
- if firmware_class is built-in.
- A modern use case may be to temporarily mount a custom partition
- during provisioning which is only accessible to userspace, and then
- to use it to look for and fetch the required firmware. Such type of
- driver functionality may not even ever be desirable upstream by
- vendors, and as such is only required to be supported as an interface
- for provisioning. Since udev's firmware loading facility has been
- removed you can use firmwared or a fork of it to customize how you
- want to load firmware based on uevents issued.
- Enabling this option will increase your kernel image size by about
- 13436 bytes.
- If you are unsure about this, say N here, unless you are Linux
- distribution and need to support the above two drivers, or you are
- certain you need to support some really custom firmware loading
- facility in userspace.
- config FW_LOADER_USER_HELPER_FALLBACK
- bool "Force the firmware sysfs fallback mechanism when possible"
- depends on FW_LOADER_USER_HELPER
- help
- Enabling this option forces a sysfs userspace fallback mechanism
- to be used for all firmware requests which explicitly do not disable a
- a fallback mechanism. Firmware calls which do prohibit a fallback
- mechanism is request_firmware_direct(). This option is kept for
- backward compatibility purposes given this precise mechanism can also
- be enabled by setting the proc sysctl value to true:
- /proc/sys/kernel/firmware_config/force_sysfs_fallback
- If you are unsure about this, say N here.
- config FW_LOADER_COMPRESS
- bool "Enable compressed firmware support"
- help
- This option enables the support for loading compressed firmware
- files. The caller of firmware API receives the decompressed file
- content. The compressed file is loaded as a fallback, only after
- loading the raw file failed at first.
- Compressed firmware support does not apply to firmware images
- that are built into the kernel image (CONFIG_EXTRA_FIRMWARE).
- if FW_LOADER_COMPRESS
- config FW_LOADER_COMPRESS_XZ
- bool "Enable XZ-compressed firmware support"
- select FW_LOADER_PAGED_BUF
- select XZ_DEC
- default y
- help
- This option adds the support for XZ-compressed files.
- The files have to be compressed with either none or crc32
- integrity check type (pass "-C crc32" option to xz command).
- config FW_LOADER_COMPRESS_ZSTD
- bool "Enable ZSTD-compressed firmware support"
- select ZSTD_DECOMPRESS
- help
- This option adds the support for ZSTD-compressed files.
- endif # FW_LOADER_COMPRESS
- config FW_CACHE
- bool "Enable firmware caching during suspend"
- depends on PM_SLEEP
- default y if PM_SLEEP
- help
- Because firmware caching generates uevent messages that are sent
- over a netlink socket, it can prevent suspend on many platforms.
- It is also not always useful, so on such platforms we have the
- option.
- If unsure, say Y.
- config FW_UPLOAD
- bool "Enable users to initiate firmware updates using sysfs"
- select FW_LOADER_SYSFS
- select FW_LOADER_PAGED_BUF
- help
- Enabling this option will allow device drivers to expose a persistent
- sysfs interface that allows firmware updates to be initiated from
- userspace. For example, FPGA based PCIe cards load firmware and FPGA
- images from local FLASH when the card boots. The images in FLASH may
- be updated with new images provided by the user. Enable this device
- to support cards that rely on user-initiated updates for firmware files.
- If unsure, say N.
- endif # FW_LOADER
- endmenu
|