linux-kernel - Re: [PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

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] [day] [month] [year] [list]

Date:   Mon, 03 Oct 2016 12:50:27 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Stephen Warren <swarren@...dotorg.org>,
        Lee Jones <lee@...nel.org>, linux-i2c@...r.kernel.org
Subject: Re: [PATCH] i2c: bcm2835: Set up the clock stretching timeout at boot.

Wolfram Sang <wsa@...-dreams.de> writes:

> On Sun, Jul 03, 2016 at 06:02:32PM -0700, Eric Anholt wrote:
>> Wolfram Sang <wsa@...-dreams.de> writes:
>> 
>> >> +	/*
>> >> +	 * SMBUS says "Devices participating in a transfer will
>> >> +	 * timeout when any clock low exceeds the value of
>> >> +	 * T_TIMEOUT,MIN of 25 ms."
>> >> +	 */
>> >
>> > SMBus has that timeout, but I2C doesn't. How about disabling the timeout
>> > simply? Or using the max value if you want to keep the timeout
>> > detection?
>> 
>> Disabling the timeout seems fine to me.  We still have a 1-second
>> timeout around the entire transfer.  I'll be back on my DSI branch this
>> week and test it out then.
>
> Did it work?

Sorry for the long-delayed feedback: It turned out that the reason I was
getting timeouts and looking into i2c in the first place was that the
firmware was driving that controller behind my back, so I couldn't do
useful testing anyway.

I put together a patch
(https://github.com/anholt/linux/commit/894200276239d2e4c60b378bdc52164fcb13af8d)
but I'm a bit concerned by it: I don't see a way to get the controller
back to its idle state without continuing through the I2C state machine,
and if the clock is still being stretched it doesn't continue unless CLK
is triggered.

What is supposed to happen when adap->timeout times out while the clock
is being stretched?  Should we be able to try starting a fresh new I2C
transaction cleanly?

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