From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Subject: Re: [RFC PATCH 1/3] i2c: add 'actual' field to struct i2c_msg
Date: Fri, 29 Jun 2012 14:33:20 +0200 [thread overview]
Message-ID: <20120629143320.42f51c0a@endymion.delvare> (raw)
In-Reply-To: <1340967927-27354-2-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
On Fri, 29 Jun 2012 16:35:25 +0530, Shubhrajyoti D wrote:
> In case of a NACK, it's wise to tell our clients
> drivers about how many bytes were actually transferred.
>
> Support this by adding an extra field to the struct
> i2c_msg which gets incremented the amount of bytes
> actually transferred.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> ---
> include/linux/i2c.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index ddfa041..0cb6b83 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -547,6 +547,7 @@ struct i2c_msg {
> #define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */
> #define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */
> __u16 len; /* msg length */
> + __u16 actual; /* actual bytes transferred */
> __u8 *buf; /* pointer to msg data */
> };
>
David Brownell discussed this a long time ago:
http://marc.info/?l=linux-i2c&m=121103523020494&w=2
This structure is exported to user-space through i2c-dev, so changing
it is tough if possible at all. You first have to ensure that the
change doesn't alter the structure size. In other words, the field you
add must fit in a padding hole the structure had previously. This
appears to be the case here, but I'm not sure how to prove it for all
supported architectures.
Then, as you are inserting a field in the middle of the structure, you
must ensure that every initialization follows C99. And you have to do
that _before_ the above change, not after as you did in patch 3/3. This
needs to be done in both the whole kernel tree and as many user-space
applications as possible. At least i2c-tools is clean, but there must
be other (possibly unpublished) tools using this API, which your change
may break. We can't fix them all, but at least we will have to document
the change clearly and explain how to fix in case of breakage. The i2c
wiki might be the right place for that.
--
Jean Delvare
next prev parent reply other threads:[~2012-06-29 12:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 11:05 [RFC PATCH 0/3] I2C: Report the actual transferred bytes Shubhrajyoti D
[not found] ` <1340967927-27354-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
2012-06-29 11:05 ` [RFC PATCH 1/3] i2c: add 'actual' field to struct i2c_msg Shubhrajyoti D
[not found] ` <1340967927-27354-2-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
2012-06-29 12:33 ` Jean Delvare [this message]
2012-07-02 13:27 ` Jean Delvare
2012-06-29 11:05 ` [RFC PATCH 2/3] i2c: omap: implement handling for 'actual' bytes transferred Shubhrajyoti D
2012-06-29 11:05 ` [RFC PATCH 3/3] i2c: inititalise the actual transferred to zero Shubhrajyoti D
2012-06-29 12:40 ` Jean Delvare
[not found] ` <20120629144002.3b4a31ee-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-06-29 12:57 ` Jean Delvare
2012-06-29 13:12 ` Shubhrajyoti
[not found] ` <4FEDA9A8.1050504-l0cyMroinI0@public.gmane.org>
2012-06-29 13:18 ` Jean Delvare
2012-07-02 11:54 ` Felipe Balbi
[not found] ` <20120702115422.GC2730-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-07-02 13:20 ` Jean Delvare
2012-07-16 8:17 ` 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=20120629143320.42f51c0a@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=balbi-l0cyMroinI0@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=shubhrajyoti-l0cyMroinI0@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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).