[PATCH RESEND] drivers: Update help for firmware loading options

[Eric Biggers]

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 <ebiggers3@xxxxxxxxx>
---
 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/