Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5998581ybc; Wed, 27 Nov 2019 13:09:07 -0800 (PST) X-Google-Smtp-Source: APXvYqz01VPah8rs7hE3YvGpHQwa7gKCNbFi+wmjfDN/pJDsa32i755A2yRYKdJZlml4klB5Ggfy X-Received: by 2002:aa7:c5d3:: with SMTP id h19mr34692395eds.120.1574888947067; Wed, 27 Nov 2019 13:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574888947; cv=none; d=google.com; s=arc-20160816; b=y0CsXHZzkuiTLCo5BpnI5bsICpSvb539T4ZO9Oseyuoy7i4FAKjVfD7mDG0LUkeOw1 c5rUCYqPZBagH9jfqrSMbHRhT8MMHFhZCWjAmN/F3wy5iAk0U7avNiUfJHcQyt7Os160 RCB16gW4KwSN6rQBJ7SeygZ2pZZX+FoH1idm0jfd9M4fDELvxYFlpW43Y6b8b+lLLotS O3gS1wFiapJXW2gH0qrF2XBLKHya3sk0Q+55spdj4SAhZSLsjMDjwFBf/qjWwErwo39Z Zm5Z4XOnRgZ5dbosI+w1DmPOP2JLtodEQ+vbi5t2yY8dZcuGKQa5ClcQNnI0PGqWEUag L4vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=v05T8Yfkuc5Ze2QCTQxn82KYSE8WQXq6zr0YLbmohBM=; b=kxLE5vMIhft+Yht1/5s0Av+9WIYK2S7emrQX+Wlzxzw9iMNt9aIr/l6YoOwN1C1nxk mVw12diNBaC5nMtyeTaupqBi0JkxLcxBk3BlNSViPxkiyHekksDBunD/8/w775JWnOlK 24oillenuMjUtlygdhmLY2CZPRW1O3fAiixE0FmvImphOQ8cPTL+G5PEsdpYBbI3KXg/ 15X2Rw0osQ41m2zuaeJjwqjN1+Xt/D4XkmVgNGxBB5C7hYYW8qa8WK1G0QU7xPUmDHw3 0tKo5xb3dEq5Y8vj8ou9OnaE6sLwkwrk5ABcsSvu3KdpDphpfaaju3O8u51uHNcOF/UQ AVPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DAGe0ZKb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i20si11589467edv.245.2019.11.27.13.08.43; Wed, 27 Nov 2019 13:09:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DAGe0ZKb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726593AbfK0VFl (ORCPT + 99 others); Wed, 27 Nov 2019 16:05:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:59432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732310AbfK0VFi (ORCPT ); Wed, 27 Nov 2019 16:05:38 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 321BA21741; Wed, 27 Nov 2019 21:05:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574888737; bh=vBFYOrfj1IE1io4Th6lrRDVblv4ioYm1LhZ/3QjbwXI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DAGe0ZKbvahieeA1+txguNiL76LQHlgOLlKEs08/2dUKsRYNdpwo7bSIazhRcPhQw 26oj+oWn8nB26lbHNPtLmeTcZSeVZ83hC5ZqfTjNZRqewQ5JV0TEd89g90HWgJXcyM eXIIoDXOasfeocdpTFXiTh90/a/9BjhBW+MBJjxQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masahiro Yamada , Wolfram Sang , Sasha Levin Subject: [PATCH 4.19 251/306] i2c: uniphier-f: fix timeout error after reading 8 bytes Date: Wed, 27 Nov 2019 21:31:41 +0100 Message-Id: <20191127203133.235034415@linuxfoundation.org> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191127203114.766709977@linuxfoundation.org> References: <20191127203114.766709977@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Masahiro Yamada [ Upstream commit c2a653deaa81f5a750c0dfcbaf9f8e5195cbe4a5 ] I was totally screwed up in commit eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared"). Since that commit, if the number of read bytes is multiple of the FIFO size (8, 16, 24... bytes), the STOP condition could be issued twice, depending on the timing. If this happens, the controller will go wrong, resulting in the timeout error. It was more than 3 years ago when I wrote this driver, so my memory about this hardware was vague. Please let me correct the description in the commit log of eaba68785c2d. Clearing the IRQ status on exiting the IRQ handler is absolutely fine. This controller makes a pause while any IRQ status is asserted. If the IRQ status is cleared first, the hardware may start the next transaction before the IRQ handler finishes what it supposed to do. This partially reverts the bad commit with clear comments so that I will never repeat this mistake. I also investigated what is happening at the last moment of the read mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier (by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB. I consulted a hardware engineer, and I got the following information: UNIPHIER_FI2C_INT_RF asserted at the falling edge of SCL at the 8th bit. UNIPHIER_FI2C_INT_RB asserted at the rising edge of SCL at the 9th (ACK) bit. In order to avoid calling uniphier_fi2c_stop() twice, check the latter interrupt. I also commented this because it is obscure hardware internal. Fixes: eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin --- drivers/i2c/busses/i2c-uniphier-f.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c index 928ea9930d17e..dd0687e36a47b 100644 --- a/drivers/i2c/busses/i2c-uniphier-f.c +++ b/drivers/i2c/busses/i2c-uniphier-f.c @@ -173,8 +173,6 @@ static irqreturn_t uniphier_fi2c_interrupt(int irq, void *dev_id) "interrupt: enabled_irqs=%04x, irq_status=%04x\n", priv->enabled_irqs, irq_status); - uniphier_fi2c_clear_irqs(priv, irq_status); - if (irq_status & UNIPHIER_FI2C_INT_STOP) goto complete; @@ -214,7 +212,13 @@ static irqreturn_t uniphier_fi2c_interrupt(int irq, void *dev_id) if (irq_status & (UNIPHIER_FI2C_INT_RF | UNIPHIER_FI2C_INT_RB)) { uniphier_fi2c_drain_rxfifo(priv); - if (!priv->len) + /* + * If the number of bytes to read is multiple of the FIFO size + * (msg->len == 8, 16, 24, ...), the INT_RF bit is set a little + * earlier than INT_RB. We wait for INT_RB to confirm the + * completion of the current message. + */ + if (!priv->len && (irq_status & UNIPHIER_FI2C_INT_RB)) goto data_done; if (unlikely(priv->flags & UNIPHIER_FI2C_MANUAL_NACK)) { @@ -253,6 +257,13 @@ static irqreturn_t uniphier_fi2c_interrupt(int irq, void *dev_id) } handled: + /* + * This controller makes a pause while any bit of the IRQ status is + * asserted. Clear the asserted bit to kick the controller just before + * exiting the handler. + */ + uniphier_fi2c_clear_irqs(priv, irq_status); + spin_unlock(&priv->lock); return IRQ_HANDLED; -- 2.20.1