diff options
| author | Dave Airlie <airlied@redhat.com> | 2026-09-26 07:57:59 +1000 |
|---|---|---|
| committer | Dave Airlie <airlied@redhat.com> | 2026-09-26 07:58:24 +1000 |
| commit | a9ed3aa9b87ee41e8ab3ff471b1331c154767e45 (patch) | |
| tree | cc62d74e0eb4905246978674461e78e2f9df2afd /Documentation/driver-api/firmware/introduction.rst | |
| download | linux-stable-a9ed3aa9b87ee41e8ab3ff471b1331c154767e45.tar.gz linux-stable-a9ed3aa9b87ee41e8ab3ff471b1331c154767e45.zip | |
Merge tag 'drm-misc-fixes-2026-09-24' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixesgrafted
A number of fixes:
- bridge:
- samsung-dsim: fix GPIO lifetime
- client: Null pointer dereference fix
- imagination: error handling fix, page handling fix
- nouveau: fix reference leaks, double-frees, out-of-bounds accesses,
use-after-frees, don't reject config without SCDC, a number of
workarounds
- virtio: fix memory leak, reference leaks, null pointer dereference,
add pixel blend mode, cache coherency fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <self@mripard.dev>
Link: https://patch.msgid.link/arU22zzqUGDEco1y@houat
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 000000000..211cb44eb --- /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. |
