STRUCT I3C_BUS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct i3c_bus(9) πŸ’…

Okay bestie, this is from the Kernel API Manual, and it's giving documentation that actually slaps. We're talking about the struct i3c_bus β€” the I3C bus object itself. Buckle up, because this is lowkey iconic and highkey important for anyone touching I3C. ✨


🌸 NAME 🌸

struct i3c_bus β€” the I3C bus object. That's it, that's the vibe. No cap. πŸ’–


✨ SYNOPSIS ✨

struct i3c_bus {
    struct i3c_dev_desc *cur_master;
    int id;
    unsigned long addrslots[((I2C_MAX_ADDR + 1) *
I3C_ADDR_SLOT_STATUS_BITS) / BITS_PER_LONG];
    enum i3c_bus_mode mode;
    struct {
      unsigned long i3c;
      unsigned long i2c;
    } scl_rate;
    struct {
      struct list_head i3c;
      struct list_head i2c;
    } devs;
    struct rw_semaphore lock;
 };

🌟 Members 🌟

Get into it, because every single field has lore:

  • cur_master β€” the I3C master currently driving the bus. Since I3C is multi-master, this can literally change over time. It's used to let a master know whether it needs to request bus ownership before sending a frame β€” or not. Periodt. πŸ‘‘
  • id β€” the bus ID. The framework assigns it when the bus gets registered. Cute and bureaucratic. πŸŽ€
  • addrslots β€” a bitmap with 2 bits per slot that encodes the address status and makes the DAA (Dynamic Address Assignment) procedure easier. Peep enum i3c_addr_slot_status for the deets. πŸ¦‹
  • mode β€” the bus mode. Peep enum i3c_bus_mode, iykyk. 🌈
  • scl_rate β€” the SCL signal rate for I3C and I2C mode. Two modes, one struct, slay. πŸ’…
  • scl_rate.i3c β€” the maximum rate for the clock signal when doing I3C SDR/priv transfers. Fast and private, main character energy. ⚑
  • scl_rate.i2c β€” the maximum rate for the clock signal when doing I2C transfers. The classic mode still eats. πŸ“
  • devs β€” 2 lists containing all I3C/I2C devices connected to the bus. Two lists, one bus, no drama. πŸ’–
  • devs.i3c β€” a list of I3C device descriptors representing the I3C devices connected on the bus and successfully attached to the I3C master. Successfully attached = the vibe check passed. βœ…
  • devs.i2c β€” a list of I2C device descriptors representing the I2C devices connected on the bus and successfully attached to the I3C master. Same energy, I2C flavor. 🧚
  • lock β€” a read/write lock on the bus. This is needed to protect against operations that have an impact on the whole bus and the devices connected to it. For example, when asking slaves to drop their dynamic address (RSTDAA CCC), we need to make sure no one is trying to send I3C frames to these devices.
⚠️ But bestie, listen: this lock does not protect against concurrency between devices β€” several drivers can send different I3C/I2C frames through the same master in parallel. It's the master's responsibility to guarantee that frames are actually sent sequentially and not interlaced. So don't come for this lock's edges, it's doing exactly what it's supposed to. πŸ’€

πŸ‘‘ Description πŸ‘‘

The I3C bus is represented with its own object and not implicitly described by the I3C master β€” and why? To cope with the multi-master functionality, where one bus can be shared amongst several masters, each of them requesting bus ownership when they need to. It's giving collaborative, it's giving shared custody, it's giving bus diplomacy. 🫢


πŸ”₯ SEE ALSO πŸ”₯

The whole friend group, literally:


And that's the tea, bestie. β˜•

Source/version: ./include/linux/i3c β€” and this whole thing is dated October 2026. Byeee, go read your kernel headers responsibly πŸ’–πŸ«Άβœ¨

πŸ“¦ where this page comes from