diff options
| author | Luis R. Rodriguez | 2016-12-16 12:10:36 +0100 |
|---|---|---|
| committer | Greg Kroah-Hartman | 2017-01-11 09:42:59 +0100 |
| commit | 113ccc38378b6f0b24c0993040c6044e35163a51 (patch) | |
| tree | 2a1fbd9a1ad5144dc316834ccf52505a84191cb3 /Documentation/driver-api/firmware/introduction.rst | |
| parent | selftests: firmware: send expected errors to /dev/null (diff) | |
| download | kernel-qcow2-linux-113ccc38378b6f0b24c0993040c6044e35163a51.tar.gz kernel-qcow2-linux-113ccc38378b6f0b24c0993040c6044e35163a51.tar.xz kernel-qcow2-linux-113ccc38378b6f0b24c0993040c6044e35163a51.zip | |
firmware: revamp firmware documentation
Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.
v2: typos and small fixes
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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. |