From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Wolfram Sang <w.sang@pengutronix.de>,
linux-i2c@vger.kernel.org, linux-input@vger.kernel.org,
linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING
Date: Fri, 04 May 2012 10:08:36 +0000 [thread overview]
Message-ID: <20120504100835.GB14230@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120503203617.31179f9b@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Thu, May 03, 2012 at 08:36:17PM +0200, Jean Delvare wrote:
> You must also update the description of I2C_FUNC_PROTOCOL_MANGLING to
> no longer mention I2C_M_NOSTART.
For backwards ABI compatibility _PROTCOL_MANGING still has to imply
_NOSTART, though it's unclear if that should be documented here. For
drivers it should for the most part flow naturally as I'd expect they'll
end up implementing one or more of the mangling flags anyway. For
applications I guess it means that they should fall back to checking for
_PROTOCOL_MANGLING if _NOSTART isn't there.
> > +#define I2C_FUNC_NOSTART 0x10000000 /* I2C_M_NOSTART */
> Sorry for nitpicking but wouldn't I2C_FUNC_GATHER be a better name?
> NOSTART is an implementation detail now, the high level feature is the
> ability to gather multiple messages into one.
I kept it this way mostly because it means that the capability flag has
the same name as the feature flag which seemed helpful from a usability
point of view.
There is also the fact you could in theory also implement gather support
in other ways (eg, using DMA) though at present there's no API level
support for this and the users do have to code this specific
implementation.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-04 10:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 12:37 [PATCH] i2c: Split I2C_M_NOSTART support out of I2C_FUNC_PROTOCOL_MANGLING Mark Brown
[not found] ` <1335443839-22872-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-03 9:52 ` Wolfram Sang
[not found] ` <20120503095211.GC9574-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-05-03 9:58 ` Mark Brown
[not found] ` <20120503095814.GA3955-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-03 10:58 ` Jean Delvare
2012-05-03 11:13 ` Wolfram Sang
2012-05-03 10:53 ` Mark Brown
[not found] ` <1336042416-28330-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-03 11:35 ` Wolfram Sang
2012-05-04 8:39 ` Jean Delvare
[not found] ` <20120504103929.644a05ce-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-05-04 16:07 ` Wolfram Sang
2012-05-03 18:36 ` Jean Delvare
2012-05-04 10:08 ` Mark Brown [this message]
2012-05-04 10:30 ` Mark Brown
2012-05-04 10:26 ` Mark Brown
2012-05-08 11:31 ` Jean Delvare
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=20120504100835.GB14230@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=FlorianSchandinat@gmx.de \
--cc=dmitry.torokhov@gmail.com \
--cc=khali@linux-fr.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=w.sang@pengutronix.de \
/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).