CONFIG_FW_LOADER_USER_HELPER: Enable the firmware sysfs fallback mechanism

General informations

The Linux kernel configuration item CONFIG_FW_LOADER_USER_HELPER has multiple definitions:

Enable the firmware sysfs fallback mechanism found in drivers/base/firmware_loader/Kconfig

The configuration item CONFIG_FW_LOADER_USER_HELPER:

• prompt: Enable the firmware sysfs fallback mechanism
• type: bool
• depends on: (none)
• defined in drivers/base/firmware_loader/Kconfig
• found in Linux kernels: 4.18–4.20, 5.0–5.19, 6.0–6.8, 6.9-rc+HEAD

Help text

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 LEDS_LP55XX_COMMON o 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.

found in drivers/base/Kconfig

The configuration item CONFIG_FW_LOADER_USER_HELPER:

• prompt:
• type: bool
• depends on: (none)
• defined in drivers/base/Kconfig
• found in Linux kernels: 3.17–3.19, 4.0–4.17

Help text

(none)

Fallback user-helper invocation for firmware loading found in drivers/base/Kconfig

The configuration item CONFIG_FW_LOADER_USER_HELPER:

• prompt: Fallback user-helper invocation for firmware loading
• type: bool
• depends on: CONFIG_FW_LOADER
• defined in drivers/base/Kconfig
• found in Linux kernels: 3.9–3.16

Help text

This option enables / disables the invocation of user-helper (e.g. udev) for loading firmware files as a fallback after the direct file loading in kernel fails. The user-mode helper is no longer required unless you have a special firmware file that resides in a non-standard path.

Hardware

LKDDb

Raw data from LKDDb:

• (none)

Sources

This page is automaticly generated with free (libre, open) software lkddb(see lkddb-sources).

The data is retrived from:

• Linux kernel
• Linux Kernel Driver DataBase (LKDDb)

Automatic links from Google (and ads)

Custom Search

Popular queries: