mbox_chan_received_data(9)

📦 version 7.3.1, in nixpkgs unstable

okay bestie, welcome to mbox_chan_received_data(9) from the Kernel API Manual — this one is literally the handoff moment between the controller driver and the upper layer. 💖

✨ NAME ✨

mbox_chan_received_data — a way for the controller driver to push data received from remote to the upper layer. 🫶

🌸 SYNOPSIS 🌸

void mbox_chan_received_data (struct mbox_chan *chan , void *mssg );

🎀 ARGUMENTS 🎀

  • chan — pointer to the mailbox channel on which RX happened. that's the actual channel where the receive event went down, bestie. 📬
  • mssg — client specific message typecasted as void *. it's giving "we don't know her type, so she's void *" energy, iykyk. 💅

💅 DESCRIPTION 💅

after startup and before shutdown, any data received on the chan is passed on to the API via atomic mbox_chan_received_data. no cap. The controller should ACK the RX only after this call returns. not before. periodt. 💀

bestie, please let the call return first before you ACK. that's the rule. the vibe check here is atomic and after, fr fr.

🦋 SEE ALSO 🦋

Kernel file ./drivers/mailbox/mailbox.c, plus mbox_chan_txdone(9), mbox_client_txdone(9), mbox_client_peek_data(9), mbox_chan_tx_slots_available(9), mbox_send_message(9), mbox_flush(9), mbox_bind_client(9), mbox_request_channel(9), mbox_free_channel(9), mbox_controller_register(9), mbox_controller_unregister(9), and devm_mbox_controller_register(9). go read those too, bestie — the lore is deep. 📚✨

and that's the page, bb. this cutie came from ./drivers/mailbox, dated October 2026, and yes, the header/title is mbox_chan_received_data(9). mwah. 💋🌈

📦 where this page comes from