Thread (60 messages) 60 messages, 12 authors, 2012-11-14
STALE4966d

[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

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help