Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5000924ybv; Mon, 17 Feb 2020 10:08:31 -0800 (PST) X-Google-Smtp-Source: APXvYqziuITb4I1Tlhl8lBRLOwt6eKnE/OOJ6GwsY0zOL/Qm2RgKZ5igFc5AAP4oovD9sK9bCNNk X-Received: by 2002:a9d:22:: with SMTP id 31mr12200844ota.173.1581962911492; Mon, 17 Feb 2020 10:08:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581962911; cv=none; d=google.com; s=arc-20160816; b=oowHESOSL0c97Ip+MyrdiyvKOF6PviUMOZX352BhVSM8NDU7codsiBoE+76l8Ms4qY Wdt+sMqyDk9Kn4+RvIiRF+9I7J7xm1LCxT81JqaOqW60T0G9kzlCSAfi0cOEbd/XUOXb vn1KqHzRkCAnv1vYNo0wEH200njSE0LL7RnSFw5EaL6ozlDOvwhY/71Y7gVViQx8RF6c q6s8a6/Kw57raRsROBFic/KkmZw+9WvN6RTmcCry1J6tl3g9dofHM8kCIw72w5De8nOv I+BpRYypElhwO0fuA4wpauDNDVOAkfubKLUn9i2xwcxDyPACD6rUK494969wShSxP4ts UyTw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=8Jhx6yIw/0TUQuBZsALOtrecffx9EOmMVzQYuCypAQI=; b=nZlFJB3EiSlSqiCyE0tqifgImUMnpDgqjumwocLxpICa9jgh4me8ZUA921oUcO2Fut zrxBdtgcnUOuDGU+WrMAhBUl/3aCsoI2ewREFNLpa5+Mz7z6q51V4ajj1R8N4fBr7rIG 1AS2PJux8XdFNGxwGyCEADggNN2wof3rTKN+2FVfOvzA5aCR+IygNhgDnY4TA+9roQva AyEhkOW6opSh4zI8TxoHMVPlC7CR8tZ/b30eAqMzA0ZVRzT+VRnxR14dOFV38SncboXV KSV1AElKCJYyY7eA3/23X5QuXBfg8kEO80sfVb094sMI/2Rtm3Yf44VepYluXGHbaqYi OyKw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r1si513486ota.259.2020.02.17.10.08.19; Mon, 17 Feb 2020 10:08:31 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729625AbgBQRYq (ORCPT + 99 others); Mon, 17 Feb 2020 12:24:46 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:42764 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729584AbgBQRYq (ORCPT ); Mon, 17 Feb 2020 12:24:46 -0500 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 1D9BE2667C2; Mon, 17 Feb 2020 17:24:44 +0000 (GMT) Date: Mon, 17 Feb 2020 18:24:38 +0100 From: Boris Brezillon To: Schrempf Frieder Cc: Boris Brezillon , Jeff Kletsky , liaoweixiong , Miquel Raynal , Richard Weinberger , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH v2 3/3] mtd: spinand: Don not erase the block before writing a bad block marker Message-ID: <20200217182438.76a25592@collabora.com> In-Reply-To: <20200217155213.5594-4-frieder.schrempf@kontron.de> References: <20200217155213.5594-1-frieder.schrempf@kontron.de> <20200217155213.5594-4-frieder.schrempf@kontron.de> Organization: Collabora X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the subject: s/Don not/Do not/ On Mon, 17 Feb 2020 15:54:12 +0000 Schrempf Frieder wrote: > From: Frieder Schrempf > > Currently when marking a block, we use spinand_erase_op() to erase > the block before writing the marker to the OOB area. Doing so without > waiting for the operation to finish can lead to the marking failing > silently and no bad block marker being written to the flash. > > In fact we don't need to do an erase at all before writing the BBM. > The ECC is disabled for the raw access to the OOB data and we don't s/the raw access/raw accesses/ > need to work around any issues with chips reporting ECC errors as it > is known to be the case for raw NAND. > > Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") > Cc: stable@vger.kernel.org > Signed-off-by: Frieder Schrempf Reviewed-by: Boris Brezillon > --- > Changes in v2: > * Instead of waiting for the erase operation to finish, just don't > do an erase at all, as it is not needed. > * Update the commit message > --- > drivers/mtd/nand/spi/core.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c > index a94287884453..8dda51bbdd11 100644 > --- a/drivers/mtd/nand/spi/core.c > +++ b/drivers/mtd/nand/spi/core.c > @@ -613,7 +613,6 @@ static int spinand_markbad(struct nand_device *nand, const struct nand_pos *pos) > }; > int ret; > > - /* Erase block before marking it bad. */ > ret = spinand_select_target(spinand, pos->target); > if (ret) > return ret; > @@ -622,8 +621,6 @@ static int spinand_markbad(struct nand_device *nand, const struct nand_pos *pos) > if (ret) > return ret; > > - spinand_erase_op(spinand, pos); > - > return spinand_write_page(spinand, &req); > } >