Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol mangling

From: Jean Delvare <khali@linux-fr.org>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	ben-linux@fluff.org, swarren@wwwdotorg.org, olof@lixom.net,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol  mangling
Date: Tue, 24 Apr 2012 15:07:50 +0200	[thread overview]
Message-ID: <20120424150750.36f8c2fc@endymion.delvare> (raw)
In-Reply-To: <20120424130118.GD4030@pengutronix.de>

On Tue, 24 Apr 2012 15:01:18 +0200, Wolfram Sang wrote:
> > > * We should allocate a new functionality flag for it.
> > > * We should update the documentation to reflect the two use cases.
> > 
> > That sounds like a good plan.  I'll try to get round to it if nobody
> > beats me to it.
> 
> Would it make sense to make all four I2C_M_* mangling features seperate
> I2C_FUNC_* options? The old I2C_FUNC_PROTOCOL_MANGLING could then be all
> four (seperately) exposed mangling features ORed. That's what I was
> wondering when looking at the patch.

The problem is that the functionality is stored in a 32-bit integer,
and we already use 17 bits in it, so every use of extra bits must be
pondered. OK, we have 15 free at the moment, but we could need some in
the future for new SMBus-style transactions, for example multi-byte
addressed block reads and writes.

I think the assumption was that mangling requires full control of the
bus lines, so a driver would either support all quirks (i2c-algo-bit)
or none (everybody else), thus having a single functionality flag. As
it seems I2C_M_NOSTART no longer fits the "quirky" category, having a
separate flag for it would make sense. But I would leave the rest alone
for the time being.

-- 
Jean Delvare