linux-kernel - Re: [PATCH] tps65910: Work around silicon erratum SWCZ010

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]

Message-ID: <53F7499D.7070103@nvidia.com>
Date:	Fri, 22 Aug 2014 19:16:05 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	"Arnout Vandecappelle (Essensium/Mind)" <arnout@...d.be>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	David Brown <davidb@...eaurora.org>
Subject: Re: [PATCH] tps65910: Work around silicon erratum SWCZ010

On Friday 22 August 2014 05:44 PM, Arnout Vandecappelle (Essensium/Mind) 
wrote:
>  From http://www.ti.com/lit/pdf/SWCZ010 :
>
> Glitch on SDA-SCL not managed correctly by the I2C IP
>
> Impact:
> The standard specifies that the I2C transfer should restart on a start
> event in all cases. The current design does not support two consecutive
> Start conditions. This can cause the first real access after such a
> glitch to be corrupted.
>
> Description:
> An unexpected glitch on SDA and SCL can generate a wrong start event.
> In the current design, the SCL line must toggle two times to detect a
> new start event and completely restart the I2C access; hence the real
> start event is not detected in the case of a single SCL toggle.
>
> Workaround:
> Repeat I2C access.
>
> The first access to the tps65910 that we do is when loading the regmap
> in the probe function. If there has been a glitch during boot and the
> erratum is triggered, then the regmap loading will fail with -REMOTEIO
> since the I2C transfer is not ACKed by the tps65910.
>
> A simple retry will work around it, because a subsequent I2C start
> condition is detected properly by the tps65910.
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@...d.be>
> ---
> This patch is based on v3.17-rc1.
> Build-tested with omap2plus_defconfig.
> Runtime tested based on v3.4.97 with a custom config.
> ---
>   drivers/mfd/tps65910.c | 12 +++++++++++-
>   1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
> index f243e75..cc1ca33 100644
> --- a/drivers/mfd/tps65910.c
> +++ b/drivers/mfd/tps65910.c
> @@ -487,8 +487,18 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
>   	tps65910->id = chip_id;
>   

I think one dummy read of any register unconditionally before regmap 
init will resolve this issue.
Similar issue we face with Palmas TPS65913 and TI recommended to use 
dummy read before any valid transfer.

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