From: viro@ZenIV.linux.org.uk (Al Viro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
Date: Sat, 27 Oct 2012 17:40:13 +0100 [thread overview]
Message-ID: <20121027164013.GV2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20121027163224.67d57aef@endymion.delvare>
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:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > 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.
next prev parent reply other threads:[~2012-10-27 16:40 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 9:46 [PATCH 0/8] I2C patches for v3.8 merge window Felipe Balbi
2012-10-22 9:46 ` [PATCH 1/8] i2c: omap: no need to access platform_device Felipe Balbi
2012-10-22 9:46 ` [PATCH 2/8] i2c: omap: reorder exit path of omap_i2c_xfer_msg() Felipe Balbi
2012-10-25 11:40 ` Shubhrajyoti Datta
2012-10-25 12:01 ` Felipe Balbi
2012-10-22 9:46 ` [PATCH 3/8] i2c: omap: fix error checking Felipe Balbi
2012-10-24 14:41 ` Michael Trimarchi
2012-10-25 10:10 ` Felipe Balbi
2012-10-25 10:33 ` Michael Trimarchi
2012-10-25 10:48 ` Felipe Balbi
2012-10-22 9:46 ` [PATCH 4/8] i2c: omap: also complete() when stat becomes zero Felipe Balbi
2012-10-22 9:46 ` [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3 Felipe Balbi
2012-10-22 12:27 ` Benoit Cousson
2012-10-22 12:28 ` Felipe Balbi
2012-10-22 13:05 ` Benoit Cousson
2012-10-22 13:09 ` Felipe Balbi
2012-10-22 13:18 ` [PATCH v2 5/8] i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS Felipe Balbi
2012-10-22 9:46 ` [PATCH 6/8] i2c: omap: wait for transfer completion before sending STP bit Felipe Balbi
2012-10-22 9:46 ` [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg Felipe Balbi
2012-10-25 12:57 ` Jean Delvare
2012-10-25 13:14 ` Russell King - ARM Linux
2012-10-25 13:42 ` Jean Delvare
2012-10-25 13:46 ` Russell King - ARM Linux
2012-10-25 13:56 ` Jean Delvare
2012-10-25 14:18 ` Russell King - ARM Linux
2012-10-27 14:32 ` Jean Delvare
2012-10-27 16:40 ` Al Viro [this message]
2012-10-27 17:02 ` Al Viro
2012-10-27 17:10 ` Al Viro
2012-10-27 19:03 ` Jean Delvare
2012-10-27 17:25 ` Russell King - ARM Linux
2012-10-22 9:46 ` [PATCH 8/8] i2c: omap: implement handling for 'transferred' bytes Felipe Balbi
2012-10-22 13:30 ` [PATCH 0/8] I2C patches for v3.8 merge window Felipe Balbi
2012-10-22 14:06 ` Shubhrajyoti Datta
2012-10-22 14:06 ` Felipe Balbi
2012-10-22 15:02 ` Shubhrajyoti
2012-11-14 16:58 ` Wolfram Sang
2012-10-25 12:25 ` [PATCH v2 0/7] " Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 1/7] i2c: omap: no need to access platform_device Felipe Balbi
2012-10-25 12:41 ` Santosh Shilimkar
2012-10-25 12:25 ` [PATCH v2 2/7] i2c: omap: reorder exit path of omap_i2c_xfer_msg() Felipe Balbi
2012-10-25 12:42 ` Santosh Shilimkar
2012-10-25 12:40 ` Felipe Balbi
2012-10-25 12:53 ` Lothar Waßmann
2012-10-25 12:25 ` [PATCH v2 3/7] i2c: omap: also complete() when stat becomes zero Felipe Balbi
2012-10-25 12:43 ` Santosh Shilimkar
2012-10-25 12:39 ` Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 4/7] i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS Felipe Balbi
2012-10-25 12:53 ` Santosh Shilimkar
2012-10-25 12:52 ` Felipe Balbi
2012-10-25 13:06 ` Santosh Shilimkar
2012-10-25 12:25 ` [PATCH v2 5/7] i2c: omap: wait for transfer completion before sending STP bit Felipe Balbi
2012-10-25 12:32 ` Felipe Balbi
2012-10-25 12:34 ` [PATCH v3 " Felipe Balbi
2012-10-25 13:01 ` [PATCH v2 " Santosh Shilimkar
2012-10-25 14:15 ` Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 6/7] i2c: add 'transferred' field to struct i2c_msg Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 7/7] i2c: omap: implement handling for 'transferred' bytes Felipe Balbi
2012-10-27 18:55 ` Paul Walmsley
2012-11-05 8:10 ` [PATCH v2 0/7] I2C patches for v3.8 merge window Felipe Balbi
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=20121027164013.GV2616@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).