firmware_request_platform(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– firmware_request_platform(9) πŸ’–

okay bestie, welcome to Kernel API Manual β€” this is the page for firmware_request_platform, and honestly? it's a whole vibe. ✨


🌸 NAME 🌸

firmware_request_platform β€” request firmware with platform-fw fallback

like, you ask for your firmware normally, but if that flops, it goes digging in the platform firmware instead. backup plan energy πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

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

three args, one int back. that's the whole thing. no cap. 🫢


πŸ¦‹ ARGUMENTS πŸ¦‹

  • firmware β€” pointer to firmware image. it's a const struct firmware **, so you're handing over a pointer to a pointer β€” she gets filled in for you. double pointer, double the slay. πŸ’–
  • name β€” name of firmware file. literally just the name, bestie.
  • device β€” device for which firmware is being loaded. gotta know who's asking, iykyk.

🌈 DESCRIPTION 🌈

okay so the way this works is SO iconic β€” this function is similar in behaviour to request_firmware, except that if the direct filesystem lookup fails, it will fallback to looking for a copy of the requested firmware embedded in the platform's main (e.g. UEFI) firmware.

read that again. filesystem first, platform firmware as the fallback. it's giving "i checked my bag, now i'm checking yours." 😭✨

and yes, "main (e.g. UEFI) firmware" is doing a lot of work in that sentence β€” that's the built-in copy we're talking about, not some random file lying around. 🧚


πŸ‘‘ SEE ALSO πŸ‘‘

all the siblings, and they all ate:

that's a whole friend group right there. πŸ«ΆπŸ’€


and that's the page, bestie!! πŸŽ€ sign-off time: this one lives in ./drivers/base/firmware_loader, comes to you courtesy of the Kernel API Manual, and it's dated October 2026 β€” go request some firmware, ily, bye!! πŸ’–βœ¨πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from