linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).