diff options
author | Linus Torvalds | 2017-02-22 20:44:32 +0100 |
---|---|---|
committer | Linus Torvalds | 2017-02-22 20:44:32 +0100 |
commit | b2064617c74f301dab1448f1f9c8dbb3c8021058 (patch) | |
tree | 02998695437a023316103256e6c0242e47e4b5eb /Documentation/driver-api/firmware/introduction.rst | |
parent | Merge tag 'char-misc-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/g... (diff) | |
parent | kernfs: handle null pointers while printing node name and path (diff) | |
download | kernel-qcow2-linux-b2064617c74f301dab1448f1f9c8dbb3c8021058.tar.gz kernel-qcow2-linux-b2064617c74f301dab1448f1f9c8dbb3c8021058.tar.xz kernel-qcow2-linux-b2064617c74f301dab1448f1f9c8dbb3c8021058.zip |
Merge tag 'driver-core-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the "small" driver core patches for 4.11-rc1.
Not much here, some firmware documentation and self-test updates, a
debugfs code formatting issue, and a new feature for call_usermodehelper
to make it more robust on systems that want to lock it down in a more
secure way.
All of these have been linux-next for a while now with no reported
issues"
* tag 'driver-core-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
kernfs: handle null pointers while printing node name and path
Introduce STATIC_USERMODEHELPER to mediate call_usermodehelper()
Make static usermode helper binaries constant
kmod: make usermodehelper path a const string
firmware: revamp firmware documentation
selftests: firmware: send expected errors to /dev/null
selftests: firmware: only modprobe if driver is missing
platform: Print the resource range if device failed to claim
kref: prefer atomic_inc_not_zero to atomic_add_unless
debugfs: improve formatting of debugfs_real_fops()
Diffstat (limited to 'Documentation/driver-api/firmware/introduction.rst')
-rw-r--r-- | Documentation/driver-api/firmware/introduction.rst | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/Documentation/driver-api/firmware/introduction.rst b/Documentation/driver-api/firmware/introduction.rst new file mode 100644 index 000000000000..211cb44eb972 --- /dev/null +++ b/Documentation/driver-api/firmware/introduction.rst @@ -0,0 +1,27 @@ +============ +Introduction +============ + +The firmware API enables kernel code to request files required +for functionality from userspace, the uses vary: + +* Microcode for CPU errata +* Device driver firmware, required to be loaded onto device + microcontrollers +* Device driver information data (calibration data, EEPROM overrides), + some of which can be completely optional. + +Types of firmware requests +========================== + +There are two types of calls: + +* Synchronous +* Asynchronous + +Which one you use vary depending on your requirements, the rule of thumb +however is you should strive to use the asynchronous APIs unless you also +are already using asynchronous initialization mechanisms which will not +stall or delay boot. Even if loading firmware does not take a lot of time +processing firmware might, and this can still delay boot or initialization, +as such mechanisms such as asynchronous probe can help supplement drivers. |