[PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: viro@ZenIV.linux.org.uk (Al Viro)
Date: 2012-10-27 16:40:13
Also in:
linux-i2c, linux-omap
From: viro@ZenIV.linux.org.uk (Al Viro)
Date: 2012-10-27 16:40:13
Also in:
linux-i2c, linux-omap
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:quoted
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:quoted
The original idea of using the hole in the i2c_msg structure is from David Brownell, who was apparently familiar with such practice, so I assumed it was OK. Actually I still assume it is, until someone comes with an supported architecture where it is not.According to Al Viro, that would be m68k.OK... So to make things clear, let me ask Al directly about it. Al, can you please tell us if:
[snip]
would break binary compatibility on m68k or any other architecture you are familiar with? Note that struct i2c_msg isn't declared with attribute packed, so my assumption was that pointer "buf" was align on at least 4 bytes, leaving a hole between len and buf. Am I wrong?
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.