mbox_send_message(9)

okay bestie, welcome to the mbox_send_message(9) page in the Kernel API Manual — this is the little client-side call that submits a message for the remote, and yes we're gonna make it make sense 💅

💖 NAME 💖

mbox_send_message — for the client to submit a message to be sent to the remote ✨

✨ SYNOPSIS ✨

int mbox_send_message (struct mbox_chan *chan , void *mssg );

🫶 ARGUMENTS 🫶

• chan — the mailbox channel assigned to this client 💌
• mssg — the client specific message, typecasted 🎀

🌸 DESCRIPTION 🌸

okay so this is how the client submits data to the controller, and that data is destined for a remote processor. main character energy: you hand it off through the mailbox API and let it handle the delivery vibes.

If the client had set 'tx_block', the call will return either when the remote receives the data or when 'tx_tout' millisecs run out. That's the blocking-mode tea ☕

In non-blocking mode, the requests are buffered by the API, and a non-negative token is returned for each queued request. If the request is not queued, a negative token is returned. Not me keeping track of every request with tokens, but okay 🔥

Upon failure or successful TX, the API calls 'tx_done' from atomic context, and from there the client could submit yet another request. So yeah, the callback is literally giving you the green light to go again 👑

The pointer to message should be preserved until it is sent over the chan, i.e, tx_done is made. Don't let that pointer expire before its moment, bestie 😭

This function could be called from atomic context as it simply queues the data and returns a token against the request. Atomic-context-safe by just queueing and returning a token — iconic ✨

In blocking mode, it is the caller's responsibility to serialize threads' access to a channel if multi-threads are to send messages through the same channel, i.e. the caller should not call this function until any previous call returns. That's the one at a time, no cutting the line rule, periodt 💅

🎀 RETURN 🎀

Non-negative integer for successful submission (non-blocking mode) or transmission over chan (blocking mode). Negative value denotes failure. So: non-negative = slay, negative = not slay 💀

🦋 SEE ALSO 🦋

• Kernel file ./drivers/mailbox/mailbox.c
• mbox_chan_received_data(9)
• mbox_chan_txdone(9)
• mbox_client_txdone(9)
• mbox_client_peek_data(9)
• mbox_chan_tx_slots_available(9)
• mbox_flush(9)
• mbox_bind_client(9)
• mbox_request_channel(9)
• mbox_free_channel(9)
• mbox_controller_register(9)
• mbox_controller_unregister(9)
• devm_mbox_controller_register(9)

---

catch u later, bestie — source/version is ./drivers/mailbox, dated October 2026, and this page is mbox_send_message(9) 💖✨