summaryrefslogtreecommitdiff
path: root/Documentation/driver-api
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2018-06-05 16:29:19 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2018-06-05 16:29:19 -0700
commitec064d3c6b40697fd72f4b1eeabbf293b7947a04 (patch)
tree1c7dcd0105d2cc9da3861452da9708ca03f2ece6 /Documentation/driver-api
parentabf7dba7c4f77d781f6df50fefb19a64c5dc331f (diff)
parent8c97a46af04b4f7c0a0dded031fef1806872e648 (diff)
downloadlwn-ec064d3c6b40697fd72f4b1eeabbf293b7947a04.tar.gz
lwn-ec064d3c6b40697fd72f4b1eeabbf293b7947a04.zip
Merge tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH: "Here is the driver core patchset for 4.18-rc1. The large chunk of these are firmware core documentation and api updates. Nothing major there, just better descriptions for others to be able to understand the firmware code better. There's also a user for a new firmware api call. Other than that, there are some minor updates for debugfs, kernfs, and the driver core itself. All of these have been in linux-next for a while with no reported issues" * tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (23 commits) driver core: hold dev's parent lock when needed driver-core: return EINVAL error instead of BUG_ON() driver core: add __printf verification to device_create_groups_vargs mm: memory_hotplug: use put_device() if device_register fail base: core: fix typo 'can by' to 'can be' debugfs: inode: debugfs_create_dir uses mode permission from parent debugfs: Re-use kstrtobool_from_user() Documentation: clarify firmware_class provenance and why we can't rename the module Documentation: remove stale firmware API reference Documentation: fix few typos and clarifications for the firmware loader ath10k: re-enable the firmware fallback mechanism for testmode ath10k: use firmware_request_nowarn() to load firmware firmware: add firmware_request_nowarn() - load firmware without warnings firmware_loader: make firmware_fallback_sysfs() print more useful firmware_loader: move kconfig FW_LOADER entries to its own file firmware_loader: replace ---help--- with help firmware_loader: enhance Kconfig documentation over FW_LOADER firmware_loader: document firmware_sysfs_fallback() firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs() firmware: use () to terminate kernel-doc function names ...
Diffstat (limited to 'Documentation/driver-api')
-rw-r--r--Documentation/driver-api/firmware/fallback-mechanisms.rst14
-rw-r--r--Documentation/driver-api/firmware/firmware_cache.rst4
-rw-r--r--Documentation/driver-api/firmware/request_firmware.rst5
3 files changed, 16 insertions, 7 deletions
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index f353783ae0be..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:
@@ -83,7 +86,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 +139,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
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