STRUCT I2C_ADAPTER_QUIRKS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 NAME 🌸

struct i2c_adapter_quirks β€” describe flaws of an i2c adapter. From the Kernel API Manual, bestie, and yes, this is the little struct that spills the tea on an adapter’s quirky limits. πŸ’…

✨ SYNOPSIS ✨

       struct i2c_adapter_quirks {
           u64 flags;
           int max_num_msgs;
           u16 max_write_len;
           u16 max_read_len;
           u16 max_comb_1st_msg_len;
           u16 max_comb_2nd_msg_len;
        };

🫢 Members 🫢

  • flags β€” see I2C_AQ_* for possible flags, and read below for the full story. ✨
  • max_num_msgs β€” maximum number of messages per transfer. That’s the cap, no cap. πŸŽ€
  • max_write_len β€” maximum length of a write message. Keep it cute and within bounds. πŸ’–
  • max_read_len β€” maximum length of a read message. Same energy, different direction. πŸ¦‹
  • max_comb_1st_msg_len β€” maximum length of the first msg in a combined message. Yes, β€œmsg” is the word here. 🌸
  • max_comb_2nd_msg_len β€” maximum length of the second msg in a combined message. The sequel has limits too. πŸ’€

πŸ”₯ Description πŸ”₯

Okay so, the note about combined messages: some I2C controllers can only send one message per transfer, plus something called combined message or write-then-read. This is (usually) a small write message followed by a read message and barely enough to access register based devices like EEPROMs. There is a flag to support this mode. It implies max_num_msg = 2 and does the length checks with max_comb_*_len because combined message mode usually has its own limitations. Because of HW implementations, some controllers can actually do write-then-anything or other variants. To support that, write-then-read has been broken out into smaller bits like write-first and read-second which can be combined as needed. 🧚

🌈 SEE ALSO 🌈


Bye bestie! πŸ’– Source/version/date tea: ./include/linux, dated October 2026, and the page is struct i2c_adapter_quirks(9). πŸŽ€ πŸ‘‘

πŸ“¦ where this page comes from