From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
Date: Thu, 25 Oct 2012 15:18:00 +0100 [thread overview]
Message-ID: <20121025141800.GI28061@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20121025155633.609c5554@endymion.delvare>
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > > You also miss one very very very big point. This will break every I2C
> > > > using userspace program out there unless it is rebuilt - this change will
> > > > require the exact right version of those userspace programs for the
> > > > kernel that they're being used on.
> > >
> > > How that? The extra field is added in a hole, so we don't change the
> > > struct size nor the relative positions of existing fields. Why would
> > > user-space care?
> >
> > You know the layout of that struct for certain across all Linux supported
> > architectures, including some of the more obscure ones which may not
> > require pointers to be aligned?
>
> No I don't, I naively supposed it would be fine. I would expect gcc to
> always align pointers even when the architecture doesn't need them to
> be, for performance reasons, even when it doesn't have to, as long as
> attribute packed isn't used. After all, integers don't _have_ to be
> aligned on x86, but gcc aligns them.
>
> 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.
next prev parent reply other threads:[~2012-10-25 14:18 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 [this message]
2012-10-27 14:32 ` Jean Delvare
2012-10-27 16:40 ` Al Viro
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=20121025141800.GI28061@n2100.arm.linux.org.uk \
--to=linux@arm.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).