STRUCT SLIM_CONTROLLER(9)

🌸 struct slim_controller(9) 🌸

okay bestie, buckle up — this is from the Kernel API Manual, and it's literally the struct that controls every single instance of SLIMbus. think of it as the 'master' on SPI, but make it SLIMbus energy 💅

---

✨ SYNOPSIS ✨

struct slim_controller {
    struct device           *dev;
    unsigned int            id;
    char name[SLIMBUS_NAME_SIZE];
    int min_cg;
    int max_cg;
    int clkgear;
    struct ida              laddr_ida;
    struct slim_framer      *a_framer;
    struct mutex            lock;
    struct list_head        devices;
    struct idr              tid_idr;
    spinlock_t txn_lock;
    struct slim_sched       sched;
    int (*xfer_msg)(struct slim_controller *ctrl, struct slim_msg_txn *tx);
    int (*set_laddr)(struct slim_controller *ctrl, struct slim_eaddr *ea, u8 laddr);
    int (*get_laddr)(struct slim_controller *ctrl, struct slim_eaddr *ea, u8 *laddr);
    int (*enable_stream)(struct slim_stream_runtime *rt);
    int (*disable_stream)(struct slim_stream_runtime *rt);
    int (*wakeup)(struct slim_controller *ctrl);
 };

no cap, that's the whole blueprint 🫶

---

🎀 Members 🎀

okay so here's the member-by-member breakdown, and yes i'm gonna be normal about it (i'm not):

• dev — the device interface to this driver. the whole connection to the outside world, basically its main character portal ✨
• id — board-specific number identifier for this controller/bus. its little government-issued ID 🪪
• name — name for this controller. what we call it 💖
• min_cg — minimum clock gear supported by this controller (default value: 1). the slowest it's willing to go, no further 😤
• max_cg — maximum clock gear supported by this controller (default value: 10). the fastest it can go, absolute ceiling 🔥
• clkgear — current clock gear in which this bus is running. what gear it's in right now, live, in the moment 🏎️
• laddr_ida — logical address id allocator. hands out logical addresses like a little ticket dispenser 🎟️
• a_framer — active framer which is clocking the bus managed by this controller. the one currently keeping the beat 👑
• lock — mutex protecting controller data structures. keeps everything from getting messy 🧼
• devices — Slim device list. the roster, the lineup, the guest list 📋
• tid_idr — tid id allocator. another allocator, but for tids 🎀
• txn_lock — lock to protect table of transactions. yes another lock, this one's for the transaction table 💅
• sched — scheduler structure used by the controller. the planner of the whole operation 🌈
• xfer_msg — transfer a message on this controller (this can be a broadcast control/status message like data channel setup, or a unicast message like value element read/write. — literally the messenger function, does both the shout-to-everyone and the whisper-to-one thing 📨
• set_laddr — setup logical address at laddr for the slave with elemental address e_addr. Drivers implementing controller will be expected to send unicast message to this device with its logical address. ngl, this is the "here's your address, bestie" function 🏠
• get_laddr — it is possible that controller needs to set fixed logical address table and get_laddr can be used in that case so that controller can do this assignment. Use case is when the master is on the remote processor side, who is resposible for allocating laddr. yep, that's the original spelling and i'm not touching it — it's part of the vibe now 🦋
• enable_stream — this function pointer implements controller-specific procedure to enable a stream. turning it ON, per-controller style ▶️
• disable_stream — this function pointer implements controller-specific procedure to disable stream. turning it OFF, per-controller style ⏹️
• wakeup — this function pointer implements controller-specific procedure to wake it up from clock-pause. Framework will call this to bring the controller out of clock pause. rise and shine icon ☀️

---

💜 Description 💜

so the manager device is responsible for things like bandwidth allocation, channel setup, and port associations per channel. (yes, the original page opens this paragraph mid-thought — we respect the source 💀)

Device management means logical address assignment/removal based on enumeration (report-present, report-absent) of a device.

Bandwidth allocation is done dynamically by the manager based on active channels on the bus, message-bandwidth requests made by SLIMbus devices.

Based on current bandwidth usage, manager chooses a frequency to run the bus at (in steps of 'clock-gear', 1 through 10, each clock gear representing twice the frequency than the previous gear). doubling each step, iconic behavior 📈

Manager is also responsible for entering (and exiting) low-power-mode (known as 'clock pause'). 😴

Manager can do handover of framer if there are multiple framers on the bus and a certain usecase warrants using certain framer to avoid keeping previous framer being powered-on. passing the crown 👑➡️👑

The controller here performs duties of the manager device, and 'interface device'. Interface device is responsible for monitoring the bus and reporting information such as loss-of-synchronization, data slot-collision. so it's both the boss and the lookout 👀

---

🔍 SEE ALSO 🔍

Kernel file ./drivers/slimbus/slimbus.h: struct slim_framer(9), struct slim_msg_txn(9), enum slim_clk_state(9), struct slim_sched(9), enum slim_port_direction(9), enum slim_port_state(9), enum slim_channel_state(9), enum slim_ch_data_fmt(9), enum slim_ch_aux_bit_fmt(9), struct slim_channel(9), struct slim_port(9), enum slim_transport_protocol(9), struct slim_stream_runtime(9)

go read those too, i'm literally begging 🥺

---

ok that's the whole page, no skips, no cuts, every field accounted for 💯 if you're writing a SLIMbus controller driver, this struct is your bestie now. treat it right 🫶

💖 sign-off time: this lil page lives at ./drivers/slimbus, dated October 2026, and it's about struct slim_controller(9) — kay bye, love u, read ur kernel headers 💅✨