STRUCT INTEL_M10BMC_FLASH_BULK_OPS(9)

✨ NAME ✨

Okay bestie, welcome to the struct intel_m10bmc_flash_bulk_ops page 💅 — this is the section 9 (Kernel API Manual) entry for it, and it's literally just the device-specific ops that make flash reads and writes happen. That's it, that's the vibe 🦋

---

🌸 SYNOPSIS 🌸

struct intel_m10bmc_flash_bulk_ops {
    int (*read)(struct intel_m10bmc *m10bmc, u8 *buf, u32 addr, u32 size);
    int (*write)(struct intel_m10bmc *m10bmc, const u8 *buf, u32 offset, u32 size);
    int (*lock_write)(struct intel_m10bmc *m10bmc);
    void (*unlock_write)(struct intel_m10bmc *m10bmc);
};

Like, four function pointers, one struct, zero drama ✨

---

🎀 Members 🎀

• read — reads a block of data from flash 📖 (yes it takes struct intel_m10bmc *m10bmc, u8 *buf, u32 addr, u32 size — the whole squad)
• write — writes a block of data to flash ✍️ (same energy: struct intel_m10bmc *m10bmc, const u8 *buf, u32 offset, u32 size)
• lock_write — locks flash access for erase+write 🔒 bestie this is the bouncer at the club
• unlock_write — unlocks flash access 🔓 thank u, next

---

💖 DESCRIPTION 💖

So here's the tea, and it's important ☕: write must be protected with lock_write and unlock_write. Like, not optional. Not a suggestion. Protect your writes, periodt 🫶

And while the flash is locked, read returns -EBUSY 😭 — so don't come for reads while the lock is held, it's giving "closed for maintenance". It's literally in the source, no cap.

⚠️ Fr fr: lock around your writes with lock_write / unlock_write, and expect -EBUSY from read while that lock is held. That's the whole rule 💀

---

🌈 SEE ALSO 🌈

• Kernel file ./include/linux/mfd/intel-m10-bmc.h
• struct m10bmc_csr_map(9)
• struct intel_m10bmc_platform_info(9)
• struct intel_m10bmc(9)

iykyk 👑

---

✨ that's the whole page, go read the header file ✨

Cute lil sign-off 🎀: this one lives in ./include/linux/mfd, stamped October 2026, and the page header/footer still say struct intel_m10bmc_flash_bulk_ops(9) — mwah, bye 💜