table of contents
STRUCT I2C_MSG(9) | I2C and SMBus Subsystem | STRUCT I2C_MSG(9) |
NAME¶
struct_i2c_msg - an I2C transaction segment beginning with START
SYNOPSIS¶
struct i2c_msg {
__u16 addr;
__u16 flags; #define I2C_M_TEN 0x0010 #define I2C_M_RD 0x0001 #define I2C_M_NOSTART 0x4000 #define I2C_M_REV_DIR_ADDR 0x2000 #define I2C_M_IGNORE_NAK 0x1000 #define I2C_M_NO_RD_ACK 0x0800 #define I2C_M_RECV_LEN 0x0400
__u16 len;
__u8 * buf; };
MEMBERS¶
addr
flags
len
buf
DESCRIPTION¶
An i2c_msg is the low level representation of one segment of an I2C transaction. It is visible to drivers in the i2c_transfer() procedure, to userspace from i2c-dev, and to I2C adapter drivers through the i2c_adapter.master_xfer() method.
Except when I2C “protocol mangling” is used, all I2C adapters implement the standard rules for I2C transactions. Each transaction begins with a START. That is followed by the slave address, and a bit encoding read versus write. Then follow all the data bytes, possibly including a byte with SMBus PEC. The transfer terminates with a NAK, or when all those bytes have been transferred and ACKed. If this is the last message in a group, it is followed by a STOP. Otherwise it is followed by the next i2c_msg transaction segment, beginning with a (repeated) START.
Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then passing certain flags may have changed those standard protocol behaviors. Those flags are only for use with broken/nonconforming slaves, and with adapters which are known to support the specific mangling options they need (one or more of IGNORE_NAK, NO_RD_ACK, NOSTART, and REV_DIR_ADDR).
COPYRIGHT¶
May 2024 | Kernel Hackers Manual 2.6. |