Greg Kroah-Hartman
598cf27219
Link: https://lore.kernel.org/r/20260217200002.683975158@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@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.
|