From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-Id: <20120316233814.005828186@linuxfoundation.org> Date: Fri, 16 Mar 2012 16:38:48 -0700 From: Greg KH To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Ville Syrjala , Jean Delvare Subject: [ 38/41] i2c-algo-bit: Fix spurious SCL timeouts under heavy load In-Reply-To: <20120316233829.GA14022@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: 3.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ville Syrjala commit 8ee161ce5e0cfc689eb677f227a6248191165fac upstream. When the system is under heavy load, there can be a significant delay between the getscl() and time_after() calls inside sclhi(). That delay may cause the time_after() check to trigger after SCL has gone high, causing sclhi() to return -ETIMEDOUT. To fix the problem, double check that SCL is still low after the timeout has been reached, before deciding to return -ETIMEDOUT. Signed-off-by: Ville Syrjala Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/algos/i2c-algo-bit.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/i2c/algos/i2c-algo-bit.c +++ b/drivers/i2c/algos/i2c-algo-bit.c @@ -103,8 +103,14 @@ static int sclhi(struct i2c_algo_bit_dat * chips may hold it low ("clock stretching") while they * are processing data internally. */ - if (time_after(jiffies, start + adap->timeout)) + if (time_after(jiffies, start + adap->timeout)) { + /* Test one last time, as we may have been preempted + * between last check and timeout test. + */ + if (getscl(adap)) + break; return -ETIMEDOUT; + } cond_resched(); } #ifdef DEBUG