Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756896AbbLBWXD (ORCPT ); Wed, 2 Dec 2015 17:23:03 -0500 Received: from mail-pa0-f48.google.com ([209.85.220.48]:36515 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752550AbbLBWXA (ORCPT ); Wed, 2 Dec 2015 17:23:00 -0500 Date: Wed, 2 Dec 2015 14:22:57 -0800 From: Brian Norris To: Jonas Gorski Cc: Boris Brezillon , Florian Fainelli , Kamal Dasu , Simon Arlott , Linux Kernel Mailing List , bcm-kernel-feedback-list , MTD Maling List , David Woodhouse Subject: Re: [PATCH] mtd: brcmnand: Workaround false ECC uncorrectable errors Message-ID: <20151202222257.GS64635@google.com> References: <5659FF4A.7080203@simon.arlott.org.uk> <565F51D2.4010204@simon.arlott.org.uk> <20151202205415.GQ64635@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1920 Lines: 40 On Wed, Dec 02, 2015 at 10:08:20PM +0100, Jonas Gorski wrote: > On Wed, Dec 2, 2015 at 9:54 PM, Brian Norris > wrote: > > If that's really an issue (i.e., we have an implementation + data), I'm > > sure we could add optimization to nand_check_erased_ecc_chunk() to > > support the bitflip_threshold == 0 case. > > Maybe I'm missing something, but wasn't the point of introducing > nand_check_erased_ecc_chunk that bitflips in erased pages should be > treated as bitflips corrected by the ecc, and therefore fixed up > before passing the data further on? So having a theshold of 0 would be > wrong / no protection at all, and could be quite destructive on MLC > nand, where bitflips in erased pages are rather common. Yes, that would be pretty destructive on MLC NAND. But there might be cases where this is reasonable. For instance, we might have: (a) SLC NAND that specifies up to 1 bitflip per 512 bytes (b) a Hamming ECC engine that can correct 1 bitflip (c) said Hamming engine does not handle all-0xff pages correctly, nor does it handle near-0xff pages (e.g., with a single 0 bit) correctly Now, we might (for instance) allow up to ecc_strength / 2 bitflips in erased pages [1], as a general rule, but for the above case, that means we don't allow any on Hamming ECC. Hence, bitflip_threshold = 1 / 2 = 0. This is kind of a degenerate case, so we might consider supporting it differently than we would for BCH. e.g., don't use nand_check_erased_ecc_chunk() at all. Brian [1] We might do this because we can expect that if an unprogrammed page has N bitflips, there might be even more than N bitflips after programming the page. -- 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/