STRUCT I3C_IBI_SETUP(9)

✨ struct i3c_ibi_setup(9) ✨

okay so bestie, welcome to the Kernel API Manual entry for struct i3c_ibi_setup — aka the IBI setup object 🎀 this is the little cutie you fill out before you go ask the kernel for some IBI slots, and honestly? it's giving "small struct, big responsibility" 💅

🌸 NAME 🌸

struct i3c_ibi_setup — the IBI setup object, periodt ✨

🦋 SYNOPSIS 🦋

struct i3c_ibi_setup {
    unsigned int max_payload_len;
    unsigned int num_slots;
    void (*handler)(struct i3c_device *dev, const struct i3c_ibi_payload *payload);
 };

like, look at her. three members. no notes. 👑

💖 Members 💖

• max_payload_len — the maximum length of the payload that comes attached to an IBI. and listen, this one has teeth 🦷: if an IBI shows up with a payload bigger than this number, the IBI gets rejected. no cap, it's just gone. so pick this number like you mean it 🙈
• num_slots — how many IBI slots you're pre-allocating. the whole vibe here is: choose it so the system never runs out of IBI slots, because if it does — you'll lose IBIs 💀 literally just dropping them. so size it generously, bestie, this is not the place to be stingy 🍓
• handler — your IBI handler, and it fires every time an IBI is received ⭐ important detail: this handler is called in a workqueue context. that means it is allowed to sleep 😴 and it is allowed to send new messages on the bus. but like — keep the processing in there as fast as possible, because otherwise you're delaying the processing of other work queued on the same workqueue, and nobody wants that energy 🫶

🌈 Description 🌈

so what even is this thing? it's a temporary structure used to pass information into i3c_device_request_ibi. that's the whole job. she's a messenger 🧚

and here's the slay part: this object can be allocated on the stack ✨ because i3c_device_request_ibi copies every single bit of information out of it, and does not use it after i3c_device_request_ibi has returned. so you can just make one on the stack, hand it over, and move on with your life. iconic behavior honestly 💅

quick vibe check 🚨: stack-allocating is fine specifically because the copy happens. don't go thinking the kernel is keeping a pointer to your little stack struct — it's not, and that's the whole reason this is allowed 🙈

👑 SEE ALSO 👑

go read these next, bestie, they're all in the kernel file ./include/linux/i3c/device.h 📁:

• enum i3c_error_code(9)
• enum i3c_xfer_mode(9)
• struct i3c_xfer(9)
• enum i3c_dcr(9)
• struct i3c_device_info(9)
• struct i3c_driver(9)
• dev_to_i3cdev(9)
• module_i3c_driver(9)
• i3c_i2c_driver_register(9)
• i3c_i2c_driver_unregister(9)
• module_i3c_i2c_driver(9)

and that's the whole page, bestie 🫶 this lil gem lives in ./include/linux/i3c and it's dated October 2026 — so yeah, technically it's from the future, and honestly? it ate. 💜✨