tb_nvm_alloc(9)

✨ tb_nvm_alloc(9) ✨

okay so bestie, this one's a kernel API manual page — tb_nvm_alloc — and it's literally the function that makes you a fresh NVM struct. That's the whole vibe. 💖

---

🌸 NAME 🌸

tb_nvm_alloc — allocate a shiny new NVM structure, no cap

---

🎀 SYNOPSIS 🎀

struct tb_nvm * tb_nvm_alloc (struct device *dev );

---

🦋 ARGUMENTS 🦋

• dev — the device that owns the NVM, like it's the parent and the NVM is its baby 🫶

---

💅 DESCRIPTION 💅

So what it does: it allocates a brand-new NVM structure, gives it a unique id (yes, every single one gets its own, iconic), and hands it right back to you. That's it. That's the function. ✨

---

👑 RETURN 👑

• Pointer to struct tb_nvm — on success, obviously, slay 💅
• -EOPNOTSUPP — this is the "girl I don't know her" era: it comes back if the NVM format of the dev is not known by the kernel 😭
• ERR_PTR — in case of failure, fr fr

---

🌈 SEE ALSO 🌈

Kernel file ./drivers/thunderbolt/nvm.c, plus the whole friend group:

• struct tb_nvm_vendor_ops(9)
• struct tb_nvm_vendor(9)
• tb_nvm_read_version(9)
• tb_nvm_validate(9)
• tb_nvm_write_headers(9)
• tb_nvm_add_active(9)
• tb_nvm_write_buf(9)
• tb_nvm_add_non_active(9)
• tb_nvm_free(9)
• tb_nvm_read_data(9)
• tb_nvm_write_data(9)

---

quick reminder bestie: if you get -EOPNOTSUPP back, it's not you, it's the kernel not recognising that NVM format 💀 don't take it personally.

okay that's the page!! this one lives in ./drivers/thunderbolt, October 2026 edition, so go off and allocate responsibly 🎀💜

— xoxo, your local kernel bestie 🧚‍♀️⭐