From patchwork Tue Dec 10 12:57:16 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ezequiel Garcia X-Patchwork-Id: 299649 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (unknown [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E67C32C0316 for ; Wed, 11 Dec 2013 11:21:02 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqMsc-00032l-Ug; Tue, 10 Dec 2013 12:57:39 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqMsa-0006sR-NS; Tue, 10 Dec 2013 12:57:36 +0000 Received: from top.free-electrons.com ([176.31.233.9] helo=mail.free-electrons.com) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqMsV-0006rI-BL for linux-mtd@lists.infradead.org; Tue, 10 Dec 2013 12:57:32 +0000 Received: by mail.free-electrons.com (Postfix, from userid 106) id 575267BE; Tue, 10 Dec 2013 13:57:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.3.2 Received: from localhost.localdomain (unknown [190.2.98.212]) by mail.free-electrons.com (Postfix) with ESMTPA id 3527D7BE; Tue, 10 Dec 2013 13:57:10 +0100 (CET) From: Ezequiel Garcia To: Subject: [PATCH for v3.13 2/2] mtd: nand: pxa3xx: Clear need_wait flag when starting a command Date: Tue, 10 Dec 2013 09:57:16 -0300 Message-Id: <1386680236-21698-3-git-send-email-ezequiel.garcia@free-electrons.com> X-Mailer: git-send-email 1.8.1.5 In-Reply-To: <1386680236-21698-1-git-send-email-ezequiel.garcia@free-electrons.com> References: <1386680236-21698-1-git-send-email-ezequiel.garcia@free-electrons.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131210_075731_491037_166EC8E5 X-CRM114-Status: GOOD ( 10.56 ) X-Spam-Score: -1.4 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Thomas Petazzoni , Lior Amsalem , Seif Mazareeb , Tawfik Bayouk , Arnaud Ebalard , Ezequiel Garcia , Gregory Clement , Brian Norris X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Currently the driver assumes all commands will eventually trigger a RnB transition, and thus a "device is ready" IRQ. This assumption means that on every issued command, the dev_ready completion handler is init'ed and the need_wait flag is set. However this is incorrect: some commands (such as NAND_CMD_STATUS) don't make the device 'busy' and thus a RnB transition never occurs. Given, the NAND core never calls waitfunc() after such commands, this is not a problem. Therefore, it's possible to only clear the need_wait flag on every command that is started. This fixes a current bug that can be reproduced on PXA boards by writing blank (all 0xff'ed) to a page: 1. The kernel issues NAND_CMD_STATUS and sets need_wait=1. The flag won't be cleared for this command since no RnB transition is involved. 2. NAND_CMD_PAGEPROG is issued but since the data is blank, the driver decides not to execute the command (and no IRQ activity is involved). 3. The NAND core calls waitfunc() and waits for the dev_ready completion, which will never end since the device _is_ already ready. Tested-by: Arnaud Ebalard Signed-off-by: Ezequiel Garcia --- drivers/mtd/nand/pxa3xx_nand.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index 4cdc134..53a1862 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -694,6 +694,7 @@ static void prepare_start_command(struct pxa3xx_nand_info *info, int command) info->retcode = ERR_NONE; info->ecc_err_cnt = 0; info->ndcb3 = 0; + info->need_wait = 0; switch (command) { case NAND_CMD_READ0: