From patchwork Wed Jun 6 09:50:13 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shmulik Ladkani X-Patchwork-Id: 163309 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1709DB6FBB for ; Wed, 6 Jun 2012 19:52:04 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1ScCsk-0004AZ-P6; Wed, 06 Jun 2012 09:50:26 +0000 Received: from mail-we0-f177.google.com ([74.125.82.177]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1ScCsg-00049c-NO for linux-mtd@lists.infradead.org; Wed, 06 Jun 2012 09:50:23 +0000 Received: by werc12 with SMTP id c12so5071515wer.36 for ; Wed, 06 Jun 2012 02:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=4FGDQAm4g8hW0Kfgy+8akfjaSynqn6irBwqofwBRY5Y=; b=NcdpgVQRxP2q7I6/BXwV//sjOg1ZLyVIUISUMHN4DyLgJsC3X9t5DizWCbe/EGmAXU OoFEOpKmK1q1H/4pi/EiLmGoRWTzdESoGp8BzXWMPe/5tOKwStzsgwQU/sq294mY04fc GAL0WLsYwv4bR5R3LJmp38/Q1Pecu3totwgJBCMUMIRFy31v4eyz1XIT0W9RzyOLtm2n JyTVAOKn5O26CFqJUdAvjykMGXwIGNiNCxBgNfhR1UjhRsEK8Alta5Zj2YTWr/2OxdmK tU0EJBBqDGthUGJNE/MNpV36238xwjFbhnjVrvvxIldZR1FjTF97na44w0FPANCjG7Rh 2R6Q== Received: by 10.216.142.215 with SMTP id i65mr16151818wej.29.1338976220687; Wed, 06 Jun 2012 02:50:20 -0700 (PDT) Received: from pixies.home.jungo.com (212-150-239-254.bb.netvision.net.il. [212.150.239.254]) by mx.google.com with ESMTPS id fo7sm1600626wib.9.2012.06.06.02.50.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jun 2012 02:50:19 -0700 (PDT) Date: Wed, 6 Jun 2012 12:50:13 +0300 From: Shmulik Ladkani To: Sascha Hauer , Mike Dunn Subject: Re: flash bbt broken due to unitialized bitflip_threshold? Message-ID: <20120606125013.5897a02d@pixies.home.jungo.com> In-Reply-To: <20120605220647.GV30400@pengutronix.de> References: <20120605220647.GV30400@pengutronix.de> Mime-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shmulik.ladkani[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.177 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Artem Bityutskiy , linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Sascha, On Wed, 6 Jun 2012 00:06:47 +0200 Sascha Hauer wrote: > Hi All, > > nand_scan_tail calls chip->scan_bbt which in case of a flash based bbt > calls mtd_read. mtd_read returns -EUCLEAN when the number of errors > exceeds bitflip_threshold. The problem is that bitflip_threshold is > uninitialized at that time, it is initialized in add_mtd_device which is > called after nand_scan. This is seen on the mxc_nand controller, but > probably on other drivers aswell. > > Am I missing something? Yep, you are correct. The result is that the BBTs will always be scrubbed (re-programmed). I think the below fix is missing, should do the job. Mike, does it look sane to you? It assigns a 'bitflip_threshold' for the master mtd (defaults to ecc_strength unless previously set by the driver). It makes page reads of the BBT area adhere to an erase-block "health" policy, either initially set by the driver, or set by default to ecc_strength. Note that if multiple partitions are later registered, one can't later override the master's bitflip_threshold via sysfs. But I guess this isn't important as the BBT is read once, when the nand is probed. diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 61805e7..46c7d2b 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3484,6 +3484,8 @@ int nand_scan_tail(struct mtd_info *mtd) /* propagate ecc info to mtd_info */ mtd->ecclayout = chip->ecc.layout; mtd->ecc_strength = chip->ecc.strength; + if (!mtd->bitflip_threshold) + mtd->bitflip_threshold = mtd->ecc_strength; /* Check, if we should skip the bad block table scan */ if (chip->options & NAND_SKIP_BBTSCAN)