From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:51
Greg,
Here is what I have queued up for the firmware_loader for v4.18. It
includes a slew of cleanup work, and the new firmware_request_nowarn()
which is quiet but enables the sysfs fallback mechanism. I've gone ahead
and also queued up a few minor fixes for the firmware loader documentation
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.
0-day sends its blessings.
The patches from Mimi's series still require a bit more discussion and
review. The discussion over the EFI firmware fallback mechanism is still
ongoing.
As for the rename that you wanted, perhaps we can do this late in the
merge window considering we're at rc4 now. I can prep something up for
that later.
Question, and specially rants are warmly welcomed.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20180508-firmware_loader_for-v4.18-try2
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20180508-firmware_loader_for-v4.18-try2
Andres Rodriguez (6):
firmware: wrap FW_OPT_* into an enum
firmware: use () to terminate kernel-doc function names
firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
firmware: add firmware_request_nowarn() - load firmware without
warnings
ath10k: use firmware_request_nowarn() to load firmware
ath10k: re-enable the firmware fallback mechanism for testmode
Luis R. Rodriguez (7):
firmware_loader: document firmware_sysfs_fallback()
firmware_loader: enhance Kconfig documentation over FW_LOADER
firmware_loader: move kconfig FW_LOADER entries to its own file
firmware_loader: make firmware_fallback_sysfs() print more useful
Documentation: fix few typos and clarifications for the firmware
loader
Documentation: remove stale firmware API reference
Documentation: clarify firmware_class provenance and why we can't
rename the module
Documentation/dell_rbu.txt | 3 -
.../firmware/fallback-mechanisms.rst | 14 +-
.../driver-api/firmware/firmware_cache.rst | 4 +-
.../driver-api/firmware/request_firmware.rst | 5 +
drivers/base/Kconfig | 90 ++--------
drivers/base/firmware_loader/Kconfig | 154 ++++++++++++++++++
drivers/base/firmware_loader/fallback.c | 53 ++++--
drivers/base/firmware_loader/fallback.h | 18 +-
drivers/base/firmware_loader/firmware.h | 37 ++++-
drivers/base/firmware_loader/main.c | 57 +++++--
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
include/linux/firmware.h | 10 ++
13 files changed, 319 insertions(+), 130 deletions(-)
create mode 100644 drivers/base/firmware_loader/Kconfig
--
2.17.0
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:36
From: Andres Rodriguez <redacted>
The kernel-doc spec dictates a function name ends in ().
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Randy Dunlap <redacted>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: adjust since the wide API rename is not yet merged]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 8 ++++----
drivers/base/firmware_loader/main.c | 22 +++++++++++-----------
2 files changed, 15 insertions(+), 15 deletions(-)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:37
From: Andres Rodriguez <redacted>
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: small coding style changes]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 8 ++++----
drivers/base/firmware_loader/fallback.h | 16 ++++++++--------
drivers/base/firmware_loader/firmware.h | 2 +-
drivers/base/firmware_loader/main.c | 2 +-
4 files changed, 14 insertions(+), 14 deletions(-)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:38
This also sets the expecations for future fallback interfaces, even
if they are not exported.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:42
From: Andres Rodriguez <redacted>
Currently the firmware loader only exposes one silent path for querying
optional firmware, and that is firmware_request_direct(). This function
also disables the sysfs fallback mechanism, which might not always be the
desired behaviour [0].
This patch introduces a variations of request_firmware() that enable the
caller to disable the undesired warning messages but enables the sysfs
fallback mechanism. This is equivalent to adding FW_OPT_NO_WARN to the
old behaviour.
[0]: https://git.kernel.org/linus/c0cc00f250e1
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: used the old API calls as the full rename is not done yet, and
add the caller for when FW_LOADER is disabled, enhance documentation ]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/request_firmware.rst | 5 ++++
drivers/base/firmware_loader/main.c | 27 +++++++++++++++++++
include/linux/firmware.h | 10 +++++++
3 files changed, 42 insertions(+)
@@ -631,6 +631,33 @@ request_firmware(const struct firmware **firmware_p, const char *name,}EXPORT_SYMBOL(request_firmware);+/**+*firmware_request_nowarn()-requestforanoptionalfwmodule+*@firmware:pointertofirmwareimage+*@name:nameoffirmwarefile+*@device:deviceforwhichfirmwareisbeingloaded+*+*Thisfunctionissimilarinbehaviourtorequest_firmware(),except+*itdoesn'tproducewarningmessageswhenthefileisnotfound.+*Thesysfsfallbackmechanismisenabledifdirectfilesystemlookupfails,+*however,howeverfailurestofindthefirmwarefilewithitarestill+*supressed.Itisthereforeuptothedrivertocheckforthereturnvalue+*ofthiscallandtodecidewhentoinformtheusersoferrors.+**/+intfirmware_request_nowarn(conststructfirmware**firmware,constchar*name,+structdevice*device)+{+intret;++/* Need to pin this module until return */+__module_get(THIS_MODULE);+ret=_request_firmware(firmware,name,device,NULL,0,+FW_OPT_UEVENT|FW_OPT_NO_WARN);+module_put(THIS_MODULE);+returnret;+}+EXPORT_SYMBOL_GPL(firmware_request_nowarn);+/***request_firmware_direct()-loadfirmwaredirectlywithoutusermodehelper*@firmware_p:pointertofirmwareimage
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:44
From: Andres Rodriguez <redacted>
The ath10k testmode uses request_firmware_direct() in order to avoid
producing firmware load warnings. Disabling the fallback mechanism was a
side effect of disabling warnings.
We now have a new API that allows us to avoid warnings while keeping the
fallback mechanism enabled. So use that instead.
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Kalle Valo <redacted>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:47
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by associating the device used to make the request as the device's parent. The sysfs directory's file attributes are defined and controlled through the new device's class (firmware_class) and group (fw_dev_attr_groups).-This is actually where the original firmware_class.c file name comes from,-as originally the only firmware loading mechanism available was the-mechanism we now use as a fallback mechanism.+This is actually where the original firmware_class module name came from,+given that originally the only firmware loading mechanism available was the+mechanism we now use as a fallback mechanism, which which registers a+struct class firmware_class. Because the attributes exposed are part of the+module name, the module name firmware_class cannot be renamed in the future, to+ensure backward compatibilty with old userspace. To load firmware using the sysfs interface we expose a loading indicator, and a file upload firmware into:
From: Andres Rodriguez <hidden> Date: 2018-05-08 18:53:39
On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote:
quoted hunk
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by associating the device used to make the request as the device's parent. The sysfs directory's file attributes are defined and controlled through the new device's class (firmware_class) and group (fw_dev_attr_groups).-This is actually where the original firmware_class.c file name comes from,-as originally the only firmware loading mechanism available was the-mechanism we now use as a fallback mechanism.+This is actually where the original firmware_class module name came from,+given that originally the only firmware loading mechanism available was the+mechanism we now use as a fallback mechanism, which which registers a
Just a tiny repeated word here, "which which".
-Andres
+struct class firmware_class. Because the attributes exposed are part of the
+module name, the module name firmware_class cannot be renamed in the future, to
+ensure backward compatibilty with old userspace.
To load firmware using the sysfs interface we expose a loading indicator,
and a file upload firmware into:
Em Tue, 8 May 2018 11:12:47 -0700
"Luis R. Rodriguez" [off-list ref] escreveu:
quoted hunk
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by associating the device used to make the request as the device's parent. The sysfs directory's file attributes are defined and controlled through the new device's class (firmware_class) and group (fw_dev_attr_groups).-This is actually where the original firmware_class.c file name comes from,-as originally the only firmware loading mechanism available was the-mechanism we now use as a fallback mechanism.+This is actually where the original firmware_class module name came from,+given that originally the only firmware loading mechanism available was the+mechanism we now use as a fallback mechanism, which which registers a+struct class firmware_class. Because the attributes exposed are part of the+module name, the module name firmware_class cannot be renamed in the future, to+ensure backward compatibilty with old userspace.
Ah, now the explanation makes a lot more sense to me :-)
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To load firmware using the sysfs interface we expose a loading indicator,
and a file upload firmware into:
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:52
From: Andres Rodriguez <redacted>
This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: coding style fixes, merge kdoc with enum move]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 12 ++++----
drivers/base/firmware_loader/fallback.h | 6 ++--
drivers/base/firmware_loader/firmware.h | 37 +++++++++++++++++++------
drivers/base/firmware_loader/main.c | 6 ++--
4 files changed, 42 insertions(+), 19 deletions(-)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:12:59
If you try to read FW_LOADER today it speaks of old riddles and
unless you have been following development closely you will loose
track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
is a bit fuzzy and how it fits into this big picture.
Give the FW_LOADER kconfig documentation some love with more up to
date developments and recommendations. While at it, wrap the FW_LOADER
code into its own menu to compartamentalize and make it clearer which
components really are part of the FW_LOADER. This should also make
it easier to later move these kconfig entries into the firmware_loader/
directory later.
This also now recommends using firmwared [0] for folks left needing a uevent
handler in userspace for the sysfs firmware fallback mechanis given udev's
uevent firmware mechanism was ripped out a while ago.
[0] https://github.com/teg/firmwared
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/Kconfig | 165 ++++++++++++++++++++++++++++++++++---------
1 file changed, 131 insertions(+), 34 deletions(-)
@@ -70,39 +70,64 @@ config STANDALONEIfunsure,sayY.configPREVENT_FIRMWARE_BUILD-bool"Prevent firmware from being built"+bool"Disable drivers features which enable custom firmware building"defaultyhelp-Sayyestoavoidbuildingfirmware.Firmwareisusuallyshipped-withthedriverandonlywhenupdatingthefirmwareshoulda-rebuildbemade.-Ifunsure,sayYhere.+Sayyestodisabledriverfeatureswhichenablebuildingacustom+driverfirmwaratkernelbuildtime.Thesedriversdonotusethe+kernelfirmwareAPItoloadfirmware(CONFIG_FW_LOADER),insteadthey+usetheirowncustomloadingmechanism.Therequiredfirmwareis+usuallyshippedwiththedriver,buildingthedriverfirmware+shouldonlybeneededifyouhaveanupdatedfirmwaresource.++Firmwareshouldnotbebeingbuiltaspartofkernel,thesedays+youshouldalwayspreventthisandsayYhere.Thereareonlytwo+olddriverswhichenablebuildingofitsfirmwareatkernelbuild+time:++oCONFIG_WANXLthroughCONFIG_WANXL_BUILD_FIRMWARE+oCONFIG_SCSI_AIC79XXthroughCONFIG_AIC79XX_BUILD_FIRMWARE++menu"Firmware loader"configFW_LOADER-tristate"Userspace firmware loading support"ifEXPERT+tristate"Firmware loading facility"ifEXPERTdefaulty---help----Thisoptionisprovidedforthecasewherenoneofthein-treemodules-requireuserspacefirmwareloadingsupport,butamodulebuilt-out-of-treedoes.+Thisenablesthefirmwareloadingfacilityinthekernel.Thekernel+willfirstlookforbuilt-infirmware,ifithasany.Next,itwill+lookfortherequestedfirmwareinaseriesoffilesystempaths:++ofirmware_classpathmoduleparameterorkernelbootparam+o/lib/firmware/updates/UTS_RELEASE+o/lib/firmware/updates+o/lib/firmware/UTS_RELEASE+o/lib/firmware++Enablingthisfeatureonlyincreasesyourkernelimagebyabout+828bytes,enablethisoptionunlessyouarecertainyoudon't+needfirmware.++Youtypicallywantthisbuilt-in(=y)butyoucanalsoenablethis+asamodule,inwhichcasethefirmware_classmodulewillbebuilt.+Youalsowanttobesuretoenablethisbuilt-inifyouaregoingto+enablebuilt-infirmware(CONFIG_EXTRA_FIRMWARE).++ifFW_LOADERconfigEXTRA_FIRMWARE-string"External firmware blobs to build into the kernel binary"-depends onFW_LOADER+string"Build these firmware blobs into the kernel binary"help-Variousdriversinthekernelsourcetreemayrequirefirmware,-whichisgenerallyavailableinyourdistribution'slinux-firmware-package.+Devicedriverswhichrequirefirmwarecantypicallydealwith+havingthekernelloadfirmwarefromthevarioussupported+/lib/firmware/paths.Thisoptionenablesyoutobuildintothe+kernelfirmwarefiles.Built-infirmwaresearchesarepreceeded+overfirmwarelookupsusingyourfilesystemoverthesupported+/lib/firmwarepathsdocumentedonCONFIG_FW_LOADER.-Thelinux-firmwarepackageshouldinstallfirmwareinto-/lib/firmware/onyoursystem,sotheycanbeloadedbyuserspace-helpersonrequest.--Thisoptionallowsfirmwaretobebuiltintothekernelforthecase-wheretheusereithercannotordoesn'twanttoprovideitfrom-userspaceatruntime(forexample,whenthefirmwareinquestionis-requiredforaccessingthebootdevice,andtheuserdoesn'twantto-useaninitrd).+Thismaybeusefulfortestingorifthefirmwareisrequiredearlyon+inbootandcannotrelyonthefirmwarebeingplacedinaninitrdor+initramfs.Thisoptionisastringandtakesthe(space-separated)namesofthefirmwarefiles--thesamenamesthatappearinMODULE_FIRMWARE()
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez [off-list ref] wrote:
If you try to read FW_LOADER today it speaks of old riddles and
unless you have been following development closely you will loose
Typo: lose
track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
is a bit fuzzy and how it fits into this big picture.
Give the FW_LOADER kconfig documentation some love with more up to
date developments and recommendations. While at it, wrap the FW_LOADER
code into its own menu to compartamentalize and make it clearer which
Typo: compartmentalize
quoted hunk
components really are part of the FW_LOADER. This should also make
it easier to later move these kconfig entries into the firmware_loader/
directory later.
This also now recommends using firmwared [0] for folks left needing a uevent
handler in userspace for the sysfs firmware fallback mechanis given udev's
uevent firmware mechanism was ripped out a while ago.
[0] https://github.com/teg/firmwared
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/Kconfig | 165 ++++++++++++++++++++++++++++++++++---------
1 file changed, 131 insertions(+), 34 deletions(-)
@@ -70,39 +70,64 @@ config STANDALONEIfunsure,sayY.configPREVENT_FIRMWARE_BUILD-bool"Prevent firmware from being built"+bool"Disable drivers features which enable custom firmware building"defaultyhelp-Sayyestoavoidbuildingfirmware.Firmwareisusuallyshipped-withthedriverandonlywhenupdatingthefirmwareshoulda-rebuildbemade.-Ifunsure,sayYhere.+Sayyestodisabledriverfeatureswhichenablebuildingacustom+driverfirmwaratkernelbuildtime.Thesedriversdonotusethe
Typo: firmware
+ kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they
+ use their own custom loading mechanism. The required firmware is
+ usually shipped with the driver, building the driver firmware
+ should only be needed if you have an updated firmware source.
+
+ Firmware should not be being built as part of kernel, these days
+ you should always prevent this and say Y here. There are only two
+ old drivers which enable building of its firmware at kernel build
+ time:
+
+ o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
+ o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
+
+menu "Firmware loader"
config FW_LOADER
- tristate "Userspace firmware loading support" if EXPERT
+ tristate "Firmware loading facility" 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.
+ 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 "External firmware blobs to build into the kernel binary"
- depends on FW_LOADER
+ string "Build these firmware blobs into the kernel binary"
Maybe "Build named firmware blobs ..." "these" took me a while to figure out.
help
- Various drivers in the kernel source tree may require firmware,
- which is generally available in your distribution's linux-firmware
- package.
+ 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 preceeded
Typo: preceded
quoted hunk
+ over firmware lookups using your filesystem over the supported
+ /lib/firmware paths documented on CONFIG_FW_LOADER.
- The linux-firmware package should install firmware into
- /lib/firmware/ on your system, so they can be loaded by userspace
- helpers on request.
-
- 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).
+ 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()
@@ -113,7 +138,7 @@ config EXTRA_FIRMWARE 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- without needing to call out to userspace.+ 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,
@@ -130,22 +155,94 @@ config EXTRA_FIRMWARE_DIR looks for the firmware files listed in the EXTRA_FIRMWARE option. config FW_LOADER_USER_HELPER- bool+ 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 firwmare is always used first now.
Typo: firmware
+
+ If the kernel's direct filesystem lookup for firware 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 supressed 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:
Typo: firmware
+
+ 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 possibily 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 "Fallback user-helper invocation for firmware loading"
- depends on FW_LOADER
- select FW_LOADER_USER_HELPER
+ bool "Force the firmware sysfs fallback mechanism when possible"
+ depends on FW_LOADER_USER_HELPER
help
- 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. Moreover, the udev support has
- been deprecated upstream.
+ 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
+
config WANT_DEV_COREDUMP
bool
help
--
2.17.0
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-09 20:55:44
On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez [off-list ref] wrote:
quoted
+ 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:
Typo: firmware
Thanks fixed all typos except this one, this one is meant to be firmwared as
that is the name of the project, the url is below.
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez [off-list ref] wrote:
On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
quoted
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez [off-list ref] wrote:
quoted
+ 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:
Typo: firmware
Thanks fixed all typos except this one, this one is meant to be firmwared as
that is the name of the project, the url is below.
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:13:01
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.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/Kconfig | 155 +--------------------------
drivers/base/firmware_loader/Kconfig | 154 ++++++++++++++++++++++++++
2 files changed, 155 insertions(+), 154 deletions(-)
create mode 100644 drivers/base/firmware_loader/Kconfig
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:13:02
If we resort to using the sysfs fallback mechanism we don't print
the filename. This can be deceiving given we could have a series of
callers intertwined and it'd be unclear exactly for what firmware
this was meant for.
Additionally, although we don't currently use FW_OPT_NO_WARN when
dealing with the fallback mechanism, we will soon, so just respect
its use consistently.
And even if you *don't* want to print always on failure, you may
want to print when debugging so enable dynamic debug print when
FW_OPT_NO_WARN is used.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
@@ -690,6 +690,11 @@ int firmware_fallback_sysfs(struct firmware *fw, const char *name,if(!fw_run_sysfs_fallback(opt_flags))returnret;-dev_warn(device,"Falling back to user helper\n");+if(!(opt_flags&FW_OPT_NO_WARN))+dev_warn(device,"Falling back to syfs fallback for: %s\n",+name);+else+dev_dbg(device,"Falling back to sysfs fallback for: %s\n",+name);returnfw_load_from_user_helper(fw,name,device,opt_flags);}
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:13:06
From: Andres Rodriguez <redacted>
This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"
Signed-off-by: Andres Rodriguez <redacted>
Acked-by: Kalle Valo <redacted>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:13:09
Fix a few typos, and clarify a few sentences.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++--
Documentation/driver-api/firmware/firmware_cache.rst | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
@@ -83,7 +83,7 @@ and a file upload firmware into:* /sys/$DEVPATH/data To upload firmware you will echo 1 onto the loading file to indicate-you are loading firmware. You then cat the firmware into the data file,+you are loading firmware. You then write the firmware into the data file, and you notify the kernel the firmware is ready by echo'ing 0 onto the loading file.
@@ -136,7 +136,8 @@ by kobject uevents. This is specially exacerbated due to the fact that most distributions today disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK. Refer to do_firmware_uevent() for details of the kobject event variables-setup. Variables passwdd with a kobject add event:+setup. The variables currently passed to userspace with a "kobject add"+event are:* FIRMWARE=firmware name* TIMEOUT=timeout value
@@ -29,8 +29,8 @@ Some implementation details about the firmware cache setup:* If an asynchronous call is used the firmware cache is only set up for a device if if the second argument (uevent) to request_firmware_nowait() is true. When uevent is true it requests that a kobject uevent be sent to- userspace for the firmware request. For details refer to the Fackback- mechanism documented below.+ userspace for the firmware request through the sysfs fallback mechanism+ if the firmware file is not found.* If the firmware cache is determined to be needed as per the above two criteria the firmware cache is setup by adding a devres entry for the
From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: 2018-05-08 18:13:11
It refers to a pending patch, but this was merged eons ago.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/dell_rbu.txt | 3 ---
1 file changed, 3 deletions(-)
@@ -121,9 +121,6 @@ read back the image downloaded. .. note::- This driver requires a patch for firmware_class.c which has the modified- request_firmware_nowait function.- Also after updating the BIOS image a user mode application needs to execute code which sends the BIOS update request to the BIOS. So on the next reboot the BIOS knows about the new image downloaded and it updates itself.
@@ -121,9 +121,6 @@ read back the image downloaded. .. note::- This driver requires a patch for firmware_class.c which has the modified- request_firmware_nowait function.-
Also after updating the BIOS image a user mode application needs to execute
code which sends the BIOS update request to the BIOS. So on the next reboot
the BIOS knows about the new image downloaded and it updates itself.
You should likely remove the "Also" here.
With that,
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Regards,
Mauro
@@ -121,9 +121,6 @@ read back the image downloaded. .. note::- This driver requires a patch for firmware_class.c which has the modified- request_firmware_nowait function.-
quoted
Also after updating the BIOS image a user mode application needs to execute
code which sends the BIOS update request to the BIOS. So on the next reboot
the BIOS knows about the new image downloaded and it updates itself.
You should likely remove the "Also" here.
Good catch. Will adjust.
With that,
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez [off-list ref] wrote:
Greg,
Here is what I have queued up for the firmware_loader for v4.18. It
includes a slew of cleanup work, and the new firmware_request_nowarn()
which is quiet but enables the sysfs fallback mechanism. I've gone ahead
and also queued up a few minor fixes for the firmware loader documentation
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.
0-day sends its blessings.
The patches from Mimi's series still require a bit more discussion and
review. The discussion over the EFI firmware fallback mechanism is still
ongoing.
As for the rename that you wanted, perhaps we can do this late in the
merge window considering we're at rc4 now. I can prep something up for
that later.
Question, and specially rants are warmly welcomed.
I sent some typo catches, but with those fixed, please consider the
whole series:
Reviewed-by: Kees Cook <redacted>
Thanks!
-Kees
--
Kees Cook
Pixel Security