HSI2C_MASTER_ST_LOSE state is not documented properly, extensive tests show that hardware is usually able to recover from this state without interrupting the transfer. On the other side enforcing transfer repetition in such case does not help in many situations, especially on busy systems and causes -EAGAIN and -ETIMEOUT errors. Moreover documentation says that such state can be caused by slave clock stretching, and should not be treated as an error. Signed-off-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx> --- drivers/i2c/busses/i2c-exynos5.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c index 4ca43980e2ed..d579b45b3092 100644 --- a/drivers/i2c/busses/i2c-exynos5.c +++ b/drivers/i2c/busses/i2c-exynos5.c @@ -445,12 +445,6 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id) i2c->state = -ETIMEDOUT; goto stop; } - - trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS); - if ((trans_status & HSI2C_MASTER_ST_MASK) == HSI2C_MASTER_ST_LOSE) { - i2c->state = -EAGAIN; - goto stop; - } } else if (int_status & HSI2C_INT_I2C) { trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS); if (trans_status & HSI2C_NO_DEV_ACK) { -- 2.15.0