| Luis R. Rodriguez | 113ccc3 | 2016-12-16 03:10:36 -0800 | [diff] [blame] | 1 | ============ |
| 2 | Introduction |
| 3 | ============ |
| 4 | |
| 5 | The firmware API enables kernel code to request files required |
| 6 | for functionality from userspace, the uses vary: |
| 7 | |
| 8 | * Microcode for CPU errata |
| 9 | * Device driver firmware, required to be loaded onto device |
| 10 | microcontrollers |
| 11 | * Device driver information data (calibration data, EEPROM overrides), |
| 12 | some of which can be completely optional. |
| 13 | |
| 14 | Types of firmware requests |
| 15 | ========================== |
| 16 | |
| 17 | There are two types of calls: |
| 18 | |
| 19 | * Synchronous |
| 20 | * Asynchronous |
| 21 | |
| 22 | Which one you use vary depending on your requirements, the rule of thumb |
| 23 | however is you should strive to use the asynchronous APIs unless you also |
| 24 | are already using asynchronous initialization mechanisms which will not |
| 25 | stall or delay boot. Even if loading firmware does not take a lot of time |
| 26 | processing firmware might, and this can still delay boot or initialization, |
| 27 | as such mechanisms such as asynchronous probe can help supplement drivers. |