Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752816AbbH1VOO (ORCPT ); Fri, 28 Aug 2015 17:14:14 -0400 Received: from blu004-omc1s26.hotmail.com ([65.55.116.37]:57194 "EHLO BLU004-OMC1S26.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752349AbbH1VOM (ORCPT ); Fri, 28 Aug 2015 17:14:12 -0400 X-TMN: [rsaxgwZiZ46mF9fxjONZrCpl/ZFSumb+] X-Originating-Email: [bpringle@sympatico.ca] Message-ID: From: Bill Pringlemeir To: Brian Norris CC: Stefan Agner , bpringlemeir@gmail.com, sebastian@breakpoint.cc, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, shawn.guo@linaro.org, kernel@pengutronix.de, boris.brezillon@free-electrons.com, marb@ixxat.de, aaron@tastycactus.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr, klimov.linux@gmail.com, Bill Pringlemeir Subject: Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support Organization: Twits of the world References: <1438594050-4595-1-git-send-email-stefan@agner.ch> <1438594050-4595-3-git-send-email-stefan@agner.ch> <20150825195411.GJ81844@google.com> <07a479863eef4c53ab2ef6ef85321680@agner.ch> <20150826213448.GU81844@google.com> Date: Fri, 28 Aug 2015 17:14:08 -0400 In-Reply-To: <20150826213448.GU81844@google.com> (Brian Norris's message of "Wed, 26 Aug 2015 14:34:48 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-OriginalArrivalTime: 28 Aug 2015 21:14:10.0435 (UTC) FILETIME=[7B765D30:01D0E1D6] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1646 Lines: 37 On 26 Aug 2015, computersforpeace@gmail.com wrote: > On Wed, Aug 26, 2015 at 10:57:38AM -0700, Stefan Agner wrote: >> When printing the ECC error count on ECC fail when reading an erased >> NAND flash, the numbers of bit flips (stuck at zero) seem to widely >> correlate with the number returned by the controller. While it seems >> to correlate widely, there are exceptions, as discussed in the >> thread: http://thread.gmane.org/gmane.linux.ports.arm.kernel/295424 >> Maybe this is an artifact of the ECC algorithm we just >> can't/shouldn't rely on? I am not sure where this originated, I did >> not found any indication in the reference manual about what that >> value contains in the error case. > Doesn't sound too reliable to me. And I'm not sure even if it was > reliable, that it would provide much value. We have to a lot of > re-counting anyway, so we might as well just be using our own > threshold. Or maybe I'm missing the point. >> Bill, do you have an idea why we used that value as threshold in >> early implementations? >> Otherwise I also think we should just drop the use of this value. Yes, using this value is not especially useful if we re-read with ECC disabled to count the bit flips for erased pages. I think this is what Stefan has done in the 11th patch set. -- Married men live longer than single men, but married men are much more willing to die - Dilworth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/