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 14:32:41 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	w.sang@...gutronix.de, ben-linux@...ff.org, swarren@...dotorg.org,
	olof@...om.net, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH V1 2/2] i2c: tegra: support for I2C_M_NOSTART protocol 
 mangling

Hi Laxman, Mark,

On Tue, 24 Apr 2012 14:51:13 +0530, Laxman Dewangan wrote:
> 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.

Please keep in mind that support for I2C_M_NOSTART at the bus driver
level is optional. This means that device drivers are encouraged to not
rely on it unconditionally. Originally the flag was meant to workaround
bogus hardware (the infamous Matrox Maven if memory serves) which
changed the transfer direction without a repeated start in the middle
(which is not allowed by the I2C specification.) It wasn't meant to be
implemented and used widely (as written in
Documentation/i2c/i2c-protocol), which is why it is one of the
I2C_FUNC_PROTOCOL_MANGLING features rather than having its own I2C
functionality flag.

If you want to do scatter-gather for I2C messages, I understand the
benefit and I have no objection, and I agree that I2C_M_NOSTART lets
you do that, but then:
* We should allocate a new functionality flag for it.
* We should update the documentation to reflect the two use cases.

Thanks,
-- 
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/