[PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg

[khali@linux-fr.org (Jean Delvare)]

Hi Al,

On Sat, 27 Oct 2012 18:10:36 +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> > On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> >
> > > You are wrong.  Assumption that pointers are aligned to 32bit boundary
> > > is simply not true.  In particular, on m68k alignment is 16bit, i.e. there
> > > struct foo {
> > > 	char x;
> > > 	void *p;
> > > }; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
> > > occupied by p.
> > >
> > > Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
> > > surprised by e.g. coldfire-based SoC with i2c on it.
> >
> > BTW, that's easily verified - take a cross-compiler and do this:
> > ; cat >a.c <<'EOF'
> > struct { char x; void *y; } v;
> > int z = (char *)&v.y - (char *)&v;
> > EOF
> > ; m68k-linux-gnu-gcc -S a.c
> > ; grep -A1 'z:' a.s
> > z:
> >         .long   2
> > ;
> > and watch what it puts into z.  gcc is very liberal about what it considers
> > a constant expression, so it allows that sort of expressions as initializers
> > for global variables.  Not a portable C, but convenient for experiments like
> > that; just grab a cross-toolchain and feed it testcases of that kind...

Thanks for the fast and complete answer.

> ... and google for i2c coldfire immediately turns up this:
> http://mailman.uclinux.org/pipermail/uclinux-dev/2012-May/051874.html
> with
> +config I2C_COLDFIRE
> +       tristate "Freescale Coldfire I2C driver"
> +       depends on !M5272
> +       help
> +         This driver supports the I2C interface availible on most Freescale
> +         Coldfire processors.
> +
> +         This driver can be built as a module.  If so, the module
> +         will be called i2c-coldfire.
> 
> in it, along with addition of drivers/i2c/busses/i2c-coldfire.c...  IOW,
> i2c on m68k is quite real.  Sorry, no go - you don't even have an excuse
> of i2c never existing on the architecture in question.

You are completely right, we will have to find another way to let bus
drivers report how much of each message they managed to transmit or
receive.

Thanks again,
-- 
Jean Delvare