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>
This commit is contained in:

committed by
Greg Kroah-Hartman

parent
880444e214
commit
113ccc3837
27
Documentation/driver-api/firmware/introduction.rst
Normal file
27
Documentation/driver-api/firmware/introduction.rst
Normal file
@@ -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.
|
Reference in New Issue
Block a user