mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-12 21:57:43 +00:00
02c3993068
If you try to read FW_LOADER today it speaks of old riddles and unless you have been following development closely you will lose track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD is a bit fuzzy and how it fits into this big picture. Give the FW_LOADER kconfig documentation some love with more up to date developments and recommendations. While at it, wrap the FW_LOADER code into its own menu to compartmentalize and make it clearer which components really are part of the FW_LOADER. This should also make it easier to later move these kconfig entries into the firmware_loader/ directory later. This also now recommends using firmwared [0] for folks left needing a uevent handler in userspace for the sysfs firmware fallback mechanis given udev's uevent firmware mechanism was ripped out a while ago. [0] https://github.com/teg/firmwared Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
432 lines
16 KiB
Text
432 lines
16 KiB
Text
# SPDX-License-Identifier: GPL-2.0
|
|
menu "Generic Driver Options"
|
|
|
|
config UEVENT_HELPER
|
|
bool "Support for uevent helper"
|
|
default y
|
|
help
|
|
The uevent helper program is forked by the kernel for
|
|
every uevent.
|
|
Before the switch to the netlink-based uevent source, this was
|
|
used to hook hotplug scripts into kernel device events. It
|
|
usually pointed to a shell script at /sbin/hotplug.
|
|
This should not be used today, because usual systems create
|
|
many events at bootup or device discovery in a very short time
|
|
frame. One forked process per event can create so many processes
|
|
that it creates a high system load, or on smaller systems
|
|
it is known to create out-of-memory situations during bootup.
|
|
|
|
config UEVENT_HELPER_PATH
|
|
string "path to uevent helper"
|
|
depends on UEVENT_HELPER
|
|
default ""
|
|
help
|
|
To disable user space helper program execution at by default
|
|
specify an empty string here. This setting can still be altered
|
|
via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper
|
|
later at runtime.
|
|
|
|
config DEVTMPFS
|
|
bool "Maintain a devtmpfs filesystem to mount at /dev"
|
|
help
|
|
This creates a tmpfs/ramfs filesystem instance early at bootup.
|
|
In this filesystem, the kernel driver core maintains device
|
|
nodes with their default names and permissions for all
|
|
registered devices with an assigned major/minor number.
|
|
Userspace can modify the filesystem content as needed, add
|
|
symlinks, and apply needed permissions.
|
|
It provides a fully functional /dev directory, where usually
|
|
udev runs on top, managing permissions and adding meaningful
|
|
symlinks.
|
|
In very limited environments, it may provide a sufficient
|
|
functional /dev without any further help. It also allows simple
|
|
rescue systems, and reliably handles dynamic major/minor numbers.
|
|
|
|
Notice: if CONFIG_TMPFS isn't enabled, the simpler ramfs
|
|
file system will be used instead.
|
|
|
|
config DEVTMPFS_MOUNT
|
|
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
|
|
depends on DEVTMPFS
|
|
help
|
|
This will instruct the kernel to automatically mount the
|
|
devtmpfs filesystem at /dev, directly after the kernel has
|
|
mounted the root filesystem. The behavior can be overridden
|
|
with the commandline parameter: devtmpfs.mount=0|1.
|
|
This option does not affect initramfs based booting, here
|
|
the devtmpfs filesystem always needs to be mounted manually
|
|
after the rootfs is mounted.
|
|
With this option enabled, it allows to bring up a system in
|
|
rescue mode with init=/bin/sh, even when the /dev directory
|
|
on the rootfs is completely empty.
|
|
|
|
config STANDALONE
|
|
bool "Select only drivers that don't need compile-time external firmware"
|
|
default y
|
|
help
|
|
Select this option if you don't have magic firmware for drivers that
|
|
need it.
|
|
|
|
If unsure, say Y.
|
|
|
|
config PREVENT_FIRMWARE_BUILD
|
|
bool "Disable drivers features which enable custom firmware building"
|
|
default y
|
|
help
|
|
Say yes to disable driver features which enable building a custom
|
|
driver firmware at kernel build time. These drivers do not use the
|
|
kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they
|
|
use their own custom loading mechanism. The required firmware is
|
|
usually shipped with the driver, building the driver firmware
|
|
should only be needed if you have an updated firmware source.
|
|
|
|
Firmware should not be being built as part of kernel, these days
|
|
you should always prevent this and say Y here. There are only two
|
|
old drivers which enable building of its firmware at kernel build
|
|
time:
|
|
|
|
o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
|
|
o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
|
|
|
|
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 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.
|
|
|
|
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"
|
|
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.
|
|
|
|
endif # FW_LOADER
|
|
endmenu
|
|
|
|
config WANT_DEV_COREDUMP
|
|
bool
|
|
help
|
|
Drivers should "select" this option if they desire to use the
|
|
device coredump mechanism.
|
|
|
|
config ALLOW_DEV_COREDUMP
|
|
bool "Allow device coredump" if EXPERT
|
|
default y
|
|
help
|
|
This option controls if the device coredump mechanism is available or
|
|
not; if disabled, the mechanism will be omitted even if drivers that
|
|
can use it are enabled.
|
|
Say 'N' for more sensitive systems or systems that don't want
|
|
to ever access the information to not have the code, nor keep any
|
|
data.
|
|
|
|
If unsure, say Y.
|
|
|
|
config DEV_COREDUMP
|
|
bool
|
|
default y if WANT_DEV_COREDUMP
|
|
depends on ALLOW_DEV_COREDUMP
|
|
|
|
config DEBUG_DRIVER
|
|
bool "Driver Core verbose debug messages"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Say Y here if you want the Driver core to produce a bunch of
|
|
debug messages to the system log. Select this if you are having a
|
|
problem with the driver core and want to see more of what is
|
|
going on.
|
|
|
|
If you are unsure about this, say N here.
|
|
|
|
config DEBUG_DEVRES
|
|
bool "Managed device resources verbose debug messages"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
This option enables kernel parameter devres.log. If set to
|
|
non-zero, devres debug messages are printed. Select this if
|
|
you are having a problem with devres or want to debug
|
|
resource management for a managed device. devres.log can be
|
|
switched on and off from sysfs node.
|
|
|
|
If you are unsure about this, Say N here.
|
|
|
|
config DEBUG_TEST_DRIVER_REMOVE
|
|
bool "Test driver remove calls during probe (UNSTABLE)"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Say Y here if you want the Driver core to test driver remove functions
|
|
by calling probe, remove, probe. This tests the remove path without
|
|
having to unbind the driver or unload the driver module.
|
|
|
|
This option is expected to find errors and may render your system
|
|
unusable. You should say N here unless you are explicitly looking to
|
|
test this functionality.
|
|
|
|
source "drivers/base/test/Kconfig"
|
|
|
|
config SYS_HYPERVISOR
|
|
bool
|
|
default n
|
|
|
|
config GENERIC_CPU_DEVICES
|
|
bool
|
|
default n
|
|
|
|
config GENERIC_CPU_AUTOPROBE
|
|
bool
|
|
|
|
config GENERIC_CPU_VULNERABILITIES
|
|
bool
|
|
|
|
config SOC_BUS
|
|
bool
|
|
select GLOB
|
|
|
|
source "drivers/base/regmap/Kconfig"
|
|
|
|
config DMA_SHARED_BUFFER
|
|
bool
|
|
default n
|
|
select ANON_INODES
|
|
select IRQ_WORK
|
|
help
|
|
This option enables the framework for buffer-sharing between
|
|
multiple drivers. A buffer is associated with a file using driver
|
|
APIs extension; the file's descriptor can then be passed on to other
|
|
driver.
|
|
|
|
config DMA_FENCE_TRACE
|
|
bool "Enable verbose DMA_FENCE_TRACE messages"
|
|
depends on DMA_SHARED_BUFFER
|
|
help
|
|
Enable the DMA_FENCE_TRACE printks. This will add extra
|
|
spam to the console log, but will make it easier to diagnose
|
|
lockup related problems for dma-buffers shared across multiple
|
|
devices.
|
|
|
|
config DMA_CMA
|
|
bool "DMA Contiguous Memory Allocator"
|
|
depends on HAVE_DMA_CONTIGUOUS && CMA
|
|
help
|
|
This enables the Contiguous Memory Allocator which allows drivers
|
|
to allocate big physically-contiguous blocks of memory for use with
|
|
hardware components that do not support I/O map nor scatter-gather.
|
|
|
|
You can disable CMA by specifying "cma=0" on the kernel's command
|
|
line.
|
|
|
|
For more information see <include/linux/dma-contiguous.h>.
|
|
If unsure, say "n".
|
|
|
|
if DMA_CMA
|
|
comment "Default contiguous memory area size:"
|
|
|
|
config CMA_SIZE_MBYTES
|
|
int "Size in Mega Bytes"
|
|
depends on !CMA_SIZE_SEL_PERCENTAGE
|
|
default 0 if X86
|
|
default 16
|
|
help
|
|
Defines the size (in MiB) of the default memory area for Contiguous
|
|
Memory Allocator. If the size of 0 is selected, CMA is disabled by
|
|
default, but it can be enabled by passing cma=size[MG] to the kernel.
|
|
|
|
|
|
config CMA_SIZE_PERCENTAGE
|
|
int "Percentage of total memory"
|
|
depends on !CMA_SIZE_SEL_MBYTES
|
|
default 0 if X86
|
|
default 10
|
|
help
|
|
Defines the size of the default memory area for Contiguous Memory
|
|
Allocator as a percentage of the total memory in the system.
|
|
If 0 percent is selected, CMA is disabled by default, but it can be
|
|
enabled by passing cma=size[MG] to the kernel.
|
|
|
|
choice
|
|
prompt "Selected region size"
|
|
default CMA_SIZE_SEL_MBYTES
|
|
|
|
config CMA_SIZE_SEL_MBYTES
|
|
bool "Use mega bytes value only"
|
|
|
|
config CMA_SIZE_SEL_PERCENTAGE
|
|
bool "Use percentage value only"
|
|
|
|
config CMA_SIZE_SEL_MIN
|
|
bool "Use lower value (minimum)"
|
|
|
|
config CMA_SIZE_SEL_MAX
|
|
bool "Use higher value (maximum)"
|
|
|
|
endchoice
|
|
|
|
config CMA_ALIGNMENT
|
|
int "Maximum PAGE_SIZE order of alignment for contiguous buffers"
|
|
range 4 12
|
|
default 8
|
|
help
|
|
DMA mapping framework by default aligns all buffers to the smallest
|
|
PAGE_SIZE order which is greater than or equal to the requested buffer
|
|
size. This works well for buffers up to a few hundreds kilobytes, but
|
|
for larger buffers it just a memory waste. With this parameter you can
|
|
specify the maximum PAGE_SIZE order for contiguous buffers. Larger
|
|
buffers will be aligned only to this specified order. The order is
|
|
expressed as a power of two multiplied by the PAGE_SIZE.
|
|
|
|
For example, if your system defaults to 4KiB pages, the order value
|
|
of 8 means that the buffers will be aligned up to 1MiB only.
|
|
|
|
If unsure, leave the default value "8".
|
|
|
|
endif
|
|
|
|
config GENERIC_ARCH_TOPOLOGY
|
|
bool
|
|
help
|
|
Enable support for architectures common topology code: e.g., parsing
|
|
CPU capacity information from DT, usage of such information for
|
|
appropriate scaling, sysfs interface for changing capacity values at
|
|
runtime.
|
|
|
|
endmenu
|