From 7dcc01343e483efda0882456f8361f061a5f416d Mon Sep 17 00:00:00 2001 From: Andres Rodriguez <andresx7@gmail.com> Date: Thu, 10 May 2018 13:08:45 -0700 Subject: firmware: add firmware_request_nowarn() - load firmware without warnings 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 <andresx7@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/driver-api/firmware/request_firmware.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst index d5ec95a7195b..f62bdcbfed5b 100644 --- a/Documentation/driver-api/firmware/request_firmware.rst +++ b/Documentation/driver-api/firmware/request_firmware.rst @@ -20,6 +20,11 @@ request_firmware .. kernel-doc:: drivers/base/firmware_loader/main.c :functions: request_firmware +firmware_request_nowarn +----------------------- +.. kernel-doc:: drivers/base/firmware_loader/main.c + :functions: firmware_request_nowarn + request_firmware_direct ----------------------- .. kernel-doc:: drivers/base/firmware_loader/main.c -- cgit v1.2.3 From 4fde24d4161358e0909684facd2226627d381fce Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: Thu, 10 May 2018 13:08:48 -0700 Subject: Documentation: fix few typos and clarifications for the firmware loader Fix a few typos, and clarify a few sentences. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++-- Documentation/driver-api/firmware/firmware_cache.rst | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index f353783ae0be..a39323ef7d29 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -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 diff --git a/Documentation/driver-api/firmware/firmware_cache.rst b/Documentation/driver-api/firmware/firmware_cache.rst index 2210e5bfb332..c2e69d9c6bf1 100644 --- a/Documentation/driver-api/firmware/firmware_cache.rst +++ b/Documentation/driver-api/firmware/firmware_cache.rst @@ -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 -- cgit v1.2.3 From f0a462970ee19930518b03798a21cfdb3fd35877 Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof@kernel.org> Date: Thu, 10 May 2018 13:08:50 -0700 Subject: Documentation: clarify firmware_class provenance and why we can't rename the module Clarify the provenance of the firmware loader firmware_class module name and why we cannot rename the module in the future. Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation/driver-api') diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index a39323ef7d29..d35fed65eae9 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -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 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 +compatibility with old userspace. To load firmware using the sysfs interface we expose a loading indicator, and a file upload firmware into: -- cgit v1.2.3