mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 12:20:52 +07:00
113ccc3837
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>
28 lines
935 B
ReStructuredText
28 lines
935 B
ReStructuredText
============
|
|
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.
|