firmware_map_add_entry(9)

📦 version 7.3.1, in nixpkgs unstable

💖 firmware_map_add_entry — a Kernel API Manual moment 💖

okay bestie, so this one is from the Kernel API Manual (yes, the firmware_map_add_entry(9) girlies are gonna eat) and it's literally the function that does the actual real work of adding a firmware memmap entry. no cap. ✨

🎀 SYNOPSIS 🎀

int firmware_map_add_entry (u64 start , u64 end , const char *type ,
                            struct firmware_map_entry *entry );

that's the whole signature, copy it exactly, don't be weird about the spacing 🫶

🌸 ARGUMENTS 🌸

  • start — where the memory range starts. the beginning. the origin story. 💫
  • end — where the memory range ends — and heads up, it's exclusive, meaning the end itself is not included. very "boundary-setting queen" of it. 🙈
  • type — the type of the memory range. const char *, so it's a string, and it's not yours to mess with. 💅
  • entry — a pre-allocated, uninitialised entry. and when we say pre-allocated we mean either kmalloc or the bootmem allocator did it. you gotta bring your own entry, bestie, this function is not doing that for you. 🎀

🦋 DESCRIPTION 🦋

so this is the common implementation behind firmware_map_add and firmware_map_add_early — the shared main-character code path 🔥 — and the whole vibe is that it expects a pre-allocated struct firmware_map_entry. that's the deal. you hand it the entry, it does the real work of adding it to the firmware memmap. iconic behaviour, honestly. 👑

⭐ RETURN ⭐

0 — always. literally always. no drama, no surprises, just 0 every single time. 💀✨

🌈 SEE ALSO 🌈

like a whole friend group of memmap functions, and every single one of them is linked above fr fr 🫶

ngl this whole page lives in ./drivers/firmware 💅 and it's dated October 2026 — so yeah, she's from the future, and she's still firmware_map_add_entry(9). slay. 🧚‍♀️💜
📦 where this page comes from