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 12:38:35 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	"w.sang@...gutronix.de" <w.sang@...gutronix.de>,
	"ben-linux@...ff.org" <ben-linux@...ff.org>,
	"swarren@...dotorg.org" <swarren@...dotorg.org>,
	"olof@...om.net" <olof@...om.net>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...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, Apr 24, 2012 at 02:51:13PM +0530, Laxman Dewangan wrote:
> On Tuesday 24 April 2012 02:25 PM, Jean Delvare wrote:

> >>Adding support for protocol mangling I2C_M_NOSTART.
> >>When multiple message transfer request made through i2c
> >>and if any message is flagged with I2C_M_NOSTART then
> >>it will not send the start/repeat start/address of that
> >>message i.e. send the data directly.

> >What do you need this for?

> The primary use-case here is scatter-gather of multiple I2C
> messages; the first message will contain the START and perhaps some
> transfers, then subsequent messages will continue with more data
> transfers. This removes the need to put all the data transfers into
> a single message, and hence avoids some copying of commands/data.

> Mark Brown says this is important for regmap. This feature is
> implement gather support for I2C transfers - the resulting I2C
> transfer is entirely normal but this ends up being implemented by
> the controller doing two transfers back to back with no start on the
> second transfer. To the outside world it looks like a perfectly
> normal transfer. This behaviour can be emulated by allocating a
> buffer and coalescing the data into that buffer before sending it to
> the hardware but this introduces an avoidable and sometimes
> noticeable overhead.

I'm sure I've seen that block of text somewhere before :)

This is it, you've got some big blob like a firmware image somewhere 
or perhaps even just a small block of data to write in one and you want
to put a register address on the front and send it.  It's much easier
and slightly faster if you can avoid having to allocate a temporary
buffer - not so much for I2C per se (it's generally very slow after all)
as for the overall system, often when you're doing this stuff when the
system is generally very busy so it's helpful to avoid introducing
needless extra work.

In the grand scheme it's not the end of the world if it's missing but
if the hardware supports it we may as well use it, it's usually just
setting a single register bit.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)