request_firmware(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay so bestie, this is request_firmware(9) from the Kernel API Manual, and it literally does what it says: it sends a firmware request and waits for it. slay. ✨

✨ SYNOPSIS ✨

The exact signature, no cap:

int request_firmware (const struct firmware **firmware_p , const char
*name , struct device *device );

πŸŽ€ ARGUMENTS πŸŽ€

  • firmware_p β€” pointer to firmware image. this is the slot where the image comes back, bestie.
  • name β€” name of firmware file.
  • device β€” device for which firmware is being loaded.

πŸ¦‹ DESCRIPTION πŸ¦‹

firmware_p will be used to return a firmware image by the name of name for device device. iconic little out-param behavior, honestly. πŸ’…

Should be called from user context where sleeping is allowed. like, actually allowed β€” not β€œprobably fine” 😭

name will be used as $FIRMWARE in the uevent environment and should be distinctive enough not to be confused with any other firmware image for this or any other device. make it unique, bestie.

No .. shenanigans: it must not contain any ".." path components β€” "foo/bar..bin" is allowed, but "foo/../bar.bin" is not. periodt, that one is a hard no. 🚫
Important: caller must hold the reference count of device. do not skip this, i’m begging. 🫢

The function can be called safely inside device's suspend and resume callback. good news bestie, that part is safe. 🌈

πŸ”₯ SEE ALSO πŸ”₯

Kernel file: ./drivers/base/firmware_loader/main.c


mwah πŸ’‹ β€” this page’s source/version is ./drivers/base/firmware_loader, and the date on it is October 2026. go be iconic with your firmware requests πŸ’…βœ¨

πŸ“¦ where this page comes from