[PATCH] drivers: Update help for firmware loading options

[PATCH] 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@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

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

[Greg KH]

On Sun, Aug 09, 2015 at 05:01:16PM -0500, Eric Biggers wrote:
> 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@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

Are you sure?  I think this should stay as "Userspace..." as that is
what it does, right?

Turning it off should only drop the userspace callouts, it shouldn't
stop the kernel from loading firmware from the filesystem all on its own
with no help.

thanks,

greg k-h

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

[Eric Biggers]

On Sun, Oct 04, 2015 at 08:14:16PM +0100, Greg KH wrote:
> 
> Are you sure?  I think this should stay as "Userspace..." as that is
> what it does, right?
> 
> Turning it off should only drop the userspace callouts, it shouldn't
> stop the kernel from loading firmware from the filesystem all on its own
> with no help.

As far as I can tell that's not true.  With FW_LOADER=n, firmware_class.c is
compiled out and request_firmware() always returns -EINVAL.  My patch tries to
make it more clear that FW_LOADER is the "top-level" option which covers all
three firmware loading mechanisms: built-in, directly from the filesystem, and
the user-mode helper.