<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>struct i2c_msg</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="Linux Device Drivers" /><link rel="up" href="ch10.html" title="Chapter 10. I2C and SMBus Subsystem" /><link rel="prev" href="re759.html" title="i2c_unlock_adapter" /><link rel="next" href="re761.html" title="i2c_register_board_info" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"><span>struct i2c_msg</span></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="re759.html">Prev</a> </td><th width="60%" align="center">Chapter 10. I<sup>2</sup>C and SMBus Subsystem</th><td width="20%" align="right"> <a accesskey="n" href="re761.html">Next</a></td></tr></table><hr /></div><div class="refentry" title="struct i2c_msg"><a id="API-struct-i2c-msg"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>struct i2c_msg —
an I2C transaction segment beginning with START
</p></div><div class="refsynopsisdiv" title="Synopsis"><h2>Synopsis</h2><pre class="programlisting">
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;
}; </pre></div><div class="refsect1" title="Members"><a id="id2709331"></a><h2>Members</h2><div class="variablelist"><dl><dt><span class="term">addr</span></dt><dd><p>
Slave address, either seven or ten bits. When this is a ten
bit address, I2C_M_TEN must be set in <em class="parameter"><code>flags</code></em> and the adapter
must support I2C_FUNC_10BIT_ADDR.
</p></dd><dt><span class="term">flags</span></dt><dd><p>
I2C_M_RD is handled by all adapters. No other flags may be
provided unless the adapter exported the relevant I2C_FUNC_*
flags through <code class="function">i2c_check_functionality</code>.
</p></dd><dt><span class="term">len</span></dt><dd><p>
Number of data bytes in <em class="parameter"><code>buf</code></em> being read from or written to the
I2C slave address. For read transactions where I2C_M_RECV_LEN
is set, the caller guarantees that this buffer can hold up to
32 bytes in addition to the initial length byte sent by the
slave (plus, if used, the SMBus PEC); and this value will be
incremented by the number of block data bytes received.
</p></dd><dt><span class="term">buf</span></dt><dd><p>
The buffer into which data is read, or from which it's written.
</p></dd></dl></div></div><div class="refsect1" title="Description"><a id="id2709415"></a><h2>Description</h2><p>
An i2c_msg is the low level representation of one segment of an I2C
transaction. It is visible to drivers in the <em class="parameter"><code>i2c_transfer</code></em>() procedure,
to userspace from i2c-dev, and to I2C adapter drivers through the
<em class="parameter"><code>i2c_adapter</code></em>.<em class="parameter"><code>master_xfer</code></em>() method.
</p><p>
Except when I2C <span class="quote">“<span class="quote">protocol mangling</span>”</span> 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
<em class="parameter"><code>i2c_msg</code></em> transaction segment, beginning with a (repeated) START.
</p><p>
Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then
passing certain <em class="parameter"><code>flags</code></em> 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).
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="re759.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch10.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="re761.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"><span>i2c_unlock_adapter</span> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> <span>i2c_register_board_info</span></td></tr></table></div></body></html>
