STRUCT MBOX_CHAN_OPS(9)

🦋 struct mbox_chan_ops(9) — the kernel API manual, bestie edition 🦋

okay so this is a page from the Kernel API Manual, and today's main character is struct mbox_chan_ops. yes we're reading manpages together, that's the friendship we have 💅

---

✨ NAME ✨

struct mbox_chan_ops — literally just methods to control mailbox channels 🎀

---

🌸 SYNOPSIS 🌸

here's the whole vibe, character for character, do not touch:

struct mbox_chan_ops {
    int (*send_data)(struct mbox_chan *chan, void *data);
    int (*flush)(struct mbox_chan *chan, unsigned long timeout);
    int (*startup)(struct mbox_chan *chan);
    void (*shutdown)(struct mbox_chan *chan);
    bool (*last_tx_done)(struct mbox_chan *chan);
    bool (*peek_data)(struct mbox_chan *chan);
 };

look at her. six little function pointers. iconic behavior honestly 🔥

---

👑 Members 👑

💖 send_data

the API rolls up to the MBOX controller driver and is like "bestie, in atomic context, try to transmit a message on the bus." 🚀

• returns 0 if the data is accepted for transmission
• returns -EBUSY while rejecting — but only if the remote hasn't yet read the last data sent 🙈
• the actual transmission of data is reported by the controller via mbox_chan_txdone (if it has some TX ACK irq, iykyk)
• it must not sleep 😴🚫 no naps allowed, atomic context, periodt

💖 flush

called when a client requests transmissions to be blocking but the context doesn't allow sleeping 😭 typically the controller will implement a busy loop waiting for the data to flush out. yes, a busy loop. she's doing her best 🫶

💖 startup

called when a client requests the chan ✨ the controller could ask clients for additional parameters of communication to be provided via the client's chan_data. this call may block 💤

after this call, the controller must forward any data received on the chan by calling mbox_chan_received_data 👈 and yeah, the controller may do stuff that needs to sleep 🌙

💖 shutdown

called when a client relinquishes control of a chan 🚪 this call may block too 😴

the controller must not forward any received data anymore ⛔ and yes — the controller may do stuff that needs to sleep 🌸

💖 last_tx_done

if the controller sets 'txdone_poll', the API calls this to poll status of last TX 👀 the controller must give priority to the IRQ method over polling and never set both txdone_poll and txdone_irq — that's a hard no, fr fr 💀

only in polling mode is send_data expected to return -EBUSY ⚠️ the controller may do stuff that needs sleep/block 😴

used only if txdone_poll:=true && txdone_irq:=false ✅

💖 peek_data

atomic check for any received data 🔍 return true if the controller has some data to push to the client, false otherwise. short, sweet, to the point, she ate 💅

---

🌈 SEE ALSO 🌈

• Kernel file ./include/linux/mailbox_controller.h
• struct mbox_controller(9)
• struct mbox_chan(9)

go read those next, we're making this a whole study session 🧚📚

---

lowkey a reminder: every one of these is a real detail from the original page — the flags, the return values, the sleep rules, all of it. i would never lie to you about kernel internals 💜

---

and that's the page!! 🎀 sign-off time: this one lives in ./include/linux, dated October 2026, filed under struct mbox_chan_ops(9) — mwah, go forth and transmit responsibly ✨💖