From: "Shevchenko, Andriy" <andriy.shevchenko@intel.com>
To: "wsa@the-dreams.de" <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH 01/18] i2c: guarantee that I2C_M_RD will be 0x0001 forever
Date: Mon, 4 Apr 2016 10:29:02 +0000 [thread overview]
Message-ID: <1459765801.2503.17.camel@intel.com> (raw)
In-Reply-To: <1459765571.2503.15.camel@linux.intel.com>
On Mon, 2016-04-04 at 13:26 +0300, Andy Shevchenko wrote:
> On Sun, 2016-04-03 at 20:44 +0200, Wolfram Sang wrote:
> >
> > There is code out there in user space and kernel space which relies
> > on
> > I2C_M_RD being bit 0 to simplify their bit operations. Add a
> > comment
> > to
> > make sure this will never break. Do proper sorting of the defines
> > while
> > we are here.
> Didn't see a comment as stated though.
Ah, overlooked it. Anyway, perhaps worth to mention under
Documentation. What do you think?
>
> >
> >
> > Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> > ---
> > include/uapi/linux/i2c.h | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
> > index b0a7dd61eb353a..adcbef4bff610a 100644
> > --- a/include/uapi/linux/i2c.h
> > +++ b/include/uapi/linux/i2c.h
> > @@ -68,14 +68,15 @@
> > struct i2c_msg {
> > __u16 addr; /* slave address
> > *
> > /
> > __u16 flags;
> > -#define I2C_M_TEN 0x0010 /* this is a ten
> > bit
> > chip address */
> > #define I2C_M_RD 0x0001 /* read data, from
> > slave to master */
> > -#define I2C_M_STOP 0x8000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > -#define I2C_M_NOSTART 0x4000 /* if
> > I2C_FUNC_NOSTART */
> > -#define I2C_M_REV_DIR_ADDR 0x2000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > -#define I2C_M_IGNORE_NAK 0x1000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > -#define I2C_M_NO_RD_ACK 0x0800 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > + /* I2C_M_RD is guaranteed
> > to
> > be 0x0001! */
> > +#define I2C_M_TEN 0x0010 /* this is a ten
> > bit
> > chip address */
> > #define I2C_M_RECV_LEN 0x0400 /* length will
> > be first received byte */
> > +#define I2C_M_NO_RD_ACK 0x0800 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > +#define I2C_M_IGNORE_NAK 0x1000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > +#define I2C_M_REV_DIR_ADDR 0x2000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > +#define I2C_M_NOSTART 0x4000 /* if
> > I2C_FUNC_NOSTART */
> > +#define I2C_M_STOP 0x8000 /* if
> > I2C_FUNC_PROTOCOL_MANGLING */
> > __u16 len; /* msg length
> > */
> > __u8 *buf; /* pointer to msg data
> > */
> > };
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
next prev parent reply other threads:[~2016-04-04 10:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-03 18:44 [PATCH 00/18] i2c: make creation of 8 bit addresses consistent Wolfram Sang
2016-04-03 18:44 ` [PATCH 01/18] i2c: guarantee that I2C_M_RD will be 0x0001 forever Wolfram Sang
2016-04-04 10:26 ` Andy Shevchenko
2016-04-04 10:29 ` Shevchenko, Andriy [this message]
2016-04-11 16:54 ` Wolfram Sang
2016-04-04 10:47 ` Wolfram Sang
2016-04-03 18:44 ` [PATCH 02/18] i2c: introduce helper function to get 8 bit address from a message Wolfram Sang
2016-04-03 18:44 ` [PATCH 03/18] i2c: core: use new 8 bit address helper function Wolfram Sang
2016-04-04 10:27 ` Andy Shevchenko
2016-04-03 18:44 ` [PATCH 04/18] i2c: i2c-bcm-iproc: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 05/18] i2c: i2c-bcm-kona: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 06/18] i2c: i2c-brcmstb: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 07/18] i2c: i2c-cpm: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 08/18] i2c: i2c-ibm_iic: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 09/18] i2c: i2c-img-scb: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 10/18] i2c: i2c-iop3xx: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 11/18] i2c: i2c-lpc2k: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 12/18] i2c: i2c-mt65xx: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 13/18] i2c: i2c-ocores: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 14/18] i2c: i2c-powermac: " Wolfram Sang
2016-04-03 18:44 ` [PATCH 15/18] i2c: i2c-qup: " Wolfram Sang
2016-05-05 18:27 ` [15/18] " Naveen Kaje
2016-04-03 18:44 ` [PATCH 16/18] i2c: i2c-sh_mobile: " Wolfram Sang
2016-04-03 18:45 ` [PATCH 17/18] i2c: i2c-sirf: " Wolfram Sang
2016-04-03 18:45 ` [PATCH 18/18] i2c: i2c-st: " Wolfram Sang
2016-04-04 10:31 ` [PATCH 00/18] i2c: make creation of 8 bit addresses consistent Andy Shevchenko
2016-04-11 17:07 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1459765801.2503.17.camel@intel.com \
--to=andriy.shevchenko@intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).