From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 965DCC433E1 for ; Tue, 23 Mar 2021 14:06:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 50AA76199F for ; Tue, 23 Mar 2021 14:06:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231976AbhCWOGU convert rfc822-to-8bit (ORCPT ); Tue, 23 Mar 2021 10:06:20 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:38371 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231928AbhCWOGH (ORCPT ); Tue, 23 Mar 2021 10:06:07 -0400 Received: from xps13 (lfbn-tou-1-1325-59.w90-89.abo.wanadoo.fr [90.89.138.59]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id C84F7100016; Tue, 23 Mar 2021 14:06:04 +0000 (UTC) Date: Tue, 23 Mar 2021 15:06:03 +0100 From: Miquel Raynal To: Daniel Palmer Cc: linux-mtd@lists.infradead.org, Linux Kernel Mailing List Subject: Re: [PATCH v2] mtd: spinand: add support for Foresee FS35ND01G-S1Y2 Message-ID: <20210323150603.6b942a60@xps13> In-Reply-To: References: <20210213095724.3411058-1-daniel@0x0f.com> <20210215112409.1a755bf0@xps13> <20210215121653.4edd86c4@xps13> <20210322193213.18520b9a@xps13> <20210323113233.3523d66b@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, Daniel Palmer wrote on Tue, 23 Mar 2021 20:47:10 +0900: > Hi Miquel, > > On Tue, 23 Mar 2021 at 19:32, Miquel Raynal wrote: > > You can run nandbiterrs -i /dev/mtdX > > > > You'll see if there is ECC correction or not (and its level). > > These are results I get for both of the nandbiterrs tests. > > # nandbiterrs -i /dev/mtd1 > incremental biterrors test > Successfully corrected 0 bit errors per subpage > Inserted biterror @ 0/5 > Read reported 4 corrected bit errors > ECC failure, invalid data despite read success This is not a valid behavior. There is something wrong with the way ECC status is read/retrieved. The read should indeed report 4 corrected bit errors, but then the data should be valid. Here it means that the introduced error appears corrected but in fact is not. We need to understand what status are available and write the appropriate vendor code. Thanks, Miquèl