Update the help text to account for the fact that the kernel can now load
firmware directly from the filesystem. Also clarify how the FW_LOADER
option works.
Signed-off-by: Eric Biggers <ebigge...@gmail.com>
---
drivers/base/Kconfig | 33 +++++++++++++++++++++------------
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..2150f6c 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -78,12 +78,21 @@ config PREVENT_FIRMWARE_BUILD
If unsure, say Y here.
config FW_LOADER
- tristate "Userspace firmware loading support" if EXPERT
+ tristate "Firmware loading support" if EXPERT
default y
---help---
- This option is provided for the case where none of the in-tree modules
- require userspace firmware loading support, but a module built
- out-of-tree does.
+ If selected, the kernel will be able to load firmware when asked to do
+ so by device drivers. Firmware is usually located in a known location
+ on the filesystem such as /lib/firmware/ and is loaded by the kernel
+ on request. Firmware can also be compiled into the kernel or loaded
+ via a (deprecated) user-mode helper.
+
+ This option is automatically selected by in-tree modules that need
+ firmware loading support. If no in-tree modules need it, then you can
+ choose N, unless you have out-of-tree modules that need it in which
+ case you will need to choose M or Y.
+
+ If unsure, say Y.
config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
@@ -95,20 +104,20 @@ config FIRMWARE_IN_KERNEL
use these is to run "make firmware_install", which, after
converting ihex files to binary, copies all of the needed
binary files in firmware/ to /lib/firmware/ on your system so
- that they can be loaded by userspace helpers on request.
+ that they can be loaded by the kernel on request.
Enabling this option will build each required firmware blob
into the kernel directly, where request_firmware() will find
- them without having to call out to userspace. This may be
+ them without having to call out to the filesystem. This may be
useful if your root file system requires a device that uses
- such firmware and do not wish to use an initrd.
+ such firmware and you do not wish to use an initrd.
This single option controls the inclusion of firmware for
every driver that uses request_firmware() and ships its
firmware in the kernel source tree, which avoids a
proliferation of 'Include firmware for xxx device' options.
- Say 'N' and let firmware be loaded from userspace.
+ Say 'N' and let firmware be loaded from the filesystem.
config EXTRA_FIRMWARE
string "External firmware blobs to build into the kernel binary"
@@ -116,9 +125,9 @@ config EXTRA_FIRMWARE
help
This option allows firmware to be built into the kernel for the case
where the user either cannot or doesn't want to provide it from
- userspace at runtime (for example, when the firmware in question is
- required for accessing the boot device, and the user doesn't want to
- use an initrd).
+ the filesystem at runtime (for example, when the firmware in question
+ is required for accessing the boot device, and the user doesn't want
+ to use an initrd).
This option is a string and takes the (space-separated) names of the
firmware files -- the same names that appear in MODULE_FIRMWARE()
@@ -129,7 +138,7 @@ config EXTRA_FIRMWARE
For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy
the usb8388.bin file into the firmware directory, and build the
kernel.
Then any request_firmware("usb8388.bin") will be satisfied internally
- without needing to call out to userspace.
+ without needing to call out to the filesystem.
WARNING: If you include additional firmware files into your binary
kernel image that are not available under the terms of the GPL,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
