diff options
author | Luis R. Rodriguez <mcgrof@kernel.org> | 2018-05-10 13:08:43 -0700 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2018-05-14 16:43:10 +0200 |
commit | 06bfd3c8ab1dbf0031022d056a90ace682f6a94c (patch) | |
tree | a6c78d27080044f797fd56411bb007c8f1ef53e0 | |
parent | 367d09824193e5a9aea98490ae0506cec8abe9c4 (diff) | |
download | linux-stable-06bfd3c8ab1dbf0031022d056a90ace682f6a94c.tar.gz linux-stable-06bfd3c8ab1dbf0031022d056a90ace682f6a94c.tar.bz2 linux-stable-06bfd3c8ab1dbf0031022d056a90ace682f6a94c.zip |
firmware_loader: move kconfig FW_LOADER entries to its own file
This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.
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>
-rw-r--r-- | drivers/base/Kconfig | 155 | ||||
-rw-r--r-- | drivers/base/firmware_loader/Kconfig | 154 |
2 files changed, 155 insertions, 154 deletions
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 0c38df32c7fe..3e63a900b330 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -88,160 +88,7 @@ config PREVENT_FIRMWARE_BUILD 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 +source "drivers/base/firmware_loader/Kconfig" config WANT_DEV_COREDUMP bool diff --git a/drivers/base/firmware_loader/Kconfig b/drivers/base/firmware_loader/Kconfig new file mode 100644 index 000000000000..eb15d976a9ea --- /dev/null +++ b/drivers/base/firmware_loader/Kconfig @@ -0,0 +1,154 @@ +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 |