linux-kernel - Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Apr 2012 15:07:50 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Laxman Dewangan <ldewangan@...dia.com>, ben-linux@...ff.org,
	swarren@...dotorg.org, olof@...om.net, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol 
 mangling

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/