Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp2984588imm; Sun, 1 Jul 2018 09:42:21 -0700 (PDT) X-Google-Smtp-Source: AAOMgpckIhwya100A6zDeFrl7wy+1MxDOnjfBFfyMzRu91P3s7u2/N+kFAFoC+SW5uo3oIjQhUa3 X-Received: by 2002:a62:4494:: with SMTP id m20-v6mr10547152pfi.205.1530463341184; Sun, 01 Jul 2018 09:42:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530463341; cv=none; d=google.com; s=arc-20160816; b=b1Lo6cuHqoHJ6VKhkBDQldFpnegi29esmKxhK52lQ8bvR7Uev5JU8tTvndOCfp1du3 Rc/THrB1eruPbpTZiHK3u6+9/iXxc7U657TvNRUstdgA7PjG2PU8ti5RXfCE+DELgrxj XCIb2VcXOJVdCME4GgLX5Lyl0ZmpADHxp+/bgD0u/mYHpJokvrq1G+cMIy6ke3l4rd7c OF4CSd0AfXUyozwd4kuWnLa2gFbZF114tDIfTOztvYfTCAMPyAqWlR1s9Sr9u25VMhB5 8Hd44G/gAqYtdyOkwXb/XjQyyMkkztXenOTiWbkiAaUmthKldgHVFTxwSHzMTKAqpMP+ AvPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=1pP+ki3Jfb44mDJls2PUzGTF5W/kmbpLdW4KcYKIgrw=; b=KSiRLCPm79gO7LMCD3GsHBGu5sQtgpcZDMbJLCNwTnrlE9Xzed4hYu/RJAQCpTCWE8 eayH5tI6avBDv03cCmBjC8pjAOfNPCtpJtxDPuLuaOLzXFaTgq4pwirZ6RLF+Blq8OZU YGnuN1yk9q3Sl3qpmwKYUuKSLyPdbmPt9s9/7Qun19zSV75RQuk6pLfalMG26ow1YZm5 yF/MVeVoDHoYFhmoEA1Kix9B/8s6A3IaTVgYeDK7S3BjnHE6bAdmhMNs9CpKedD5aiTF OUkdjumGUKnHUyuxwzg2kFFruc4l0sU9k70dwUdJi7JmeGPhQgb0QGGi0mS//oZKPG+W aaSg== ARC-Authentication-Results: i=1; mx.google.com; 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 u10-v6si12186241pgc.261.2018.07.01.09.42.06; Sun, 01 Jul 2018 09:42:21 -0700 (PDT) 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; 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 S1032012AbeGAQlL (ORCPT + 99 others); Sun, 1 Jul 2018 12:41:11 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37298 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031508AbeGAQlG (ORCPT ); Sun, 1 Jul 2018 12:41:06 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id D9539ACC; Sun, 1 Jul 2018 16:41:05 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Boris Brezillon , Miquel Raynal Subject: [PATCH 4.17 099/220] mtd: rawnand: Do not check FAIL bit when executing a SET_FEATURES op Date: Sun, 1 Jul 2018 18:22:03 +0200 Message-Id: <20180701160912.545449483@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180701160908.272447118@linuxfoundation.org> References: <20180701160908.272447118@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.17-stable review patch. If anyone has any objections, please let me know. ------------------ From: Boris Brezillon commit 782d1967d0479ffd59412b2f3179c8bb35f50ff6 upstream. The ONFI spec clearly says that FAIL bit is only valid for PROGRAM, ERASE and READ-with-on-die-ECC operations, and should be ignored otherwise. It seems that checking it after sending a SET_FEATURES is a bad idea because a previous READ, PROGRAM or ERASE op may have failed, and depending on the implementation, the FAIL bit is not cleared until a new READ, PROGRAM or ERASE is started. This leads to ->set_features() returning -EIO while it actually worked, which can sometimes stop a batch of READ/PROGRAM ops. Note that we only fix the ->exec_op() path here, because some drivers are abusing the NAND_STATUS_FAIL flag in their ->waitfunc() implementation to propagate other kind of errors, like wait-ready-timeout or controller-related errors. Let's not try to fix those drivers since they worked fine so far. Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation") Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon Acked-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/raw/nand_base.c | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -2174,7 +2174,6 @@ static int nand_set_features_op(struct n struct mtd_info *mtd = nand_to_mtd(chip); const u8 *params = data; int i, ret; - u8 status; if (chip->exec_op) { const struct nand_sdr_timings *sdr = @@ -2188,26 +2187,18 @@ static int nand_set_features_op(struct n }; struct nand_operation op = NAND_OPERATION(instrs); - ret = nand_exec_op(chip, &op); - if (ret) - return ret; - - ret = nand_status_op(chip, &status); - if (ret) - return ret; - } else { - chip->cmdfunc(mtd, NAND_CMD_SET_FEATURES, feature, -1); - for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i) - chip->write_byte(mtd, params[i]); - - ret = chip->waitfunc(mtd, chip); - if (ret < 0) - return ret; - - status = ret; + return nand_exec_op(chip, &op); } - if (status & NAND_STATUS_FAIL) + chip->cmdfunc(mtd, NAND_CMD_SET_FEATURES, feature, -1); + for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i) + chip->write_byte(mtd, params[i]); + + ret = chip->waitfunc(mtd, chip); + if (ret < 0) + return ret; + + if (ret & NAND_STATUS_FAIL) return -EIO; return 0;