Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp547167pxb; Fri, 15 Oct 2021 10:44:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLSvjEY8JFdFfelHahcQY791TILxkLGbjYM32QZ9ufDXyXyJRycDHpTNsW/fZAoFZKEICC X-Received: by 2002:a05:6402:51d3:: with SMTP id r19mr19544477edd.258.1634319872078; Fri, 15 Oct 2021 10:44:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634319872; cv=none; d=google.com; s=arc-20160816; b=OIlqpZK4cdZKFpGIU/HniKOyVZx2Q2kIi84oGI9X255CpUW3aVaPaz/pNAZHbbsHBz fe8Yu/FAjyTbs0rzUoDxzzrPi6RN6ge8DvXMSGBTICoBbum3Av9uFQZFfwMoKV1MOgXG FsOGQG+4kkEXkjmvbNGAol0rAHPn2k2cU+6k2cLalv9PtMMOUGZW3AOKvcOlKD92w3Lr ppgyyJnyDaFBlNbNPO10yCA7i6OCC8mLIwCEN5JeUOs/yF3LQAtMu9a21Ok6Tpw3+XCm gHMfYhgulL5OEbbuIijHxZwlxW4ctgfiISNqIBCKJ1X5B95uP2NoD9Hu+OY3q0YMZTCN fLDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=Agbq14osmcRsJxHU06fh15gRGsese8FXf+1sqmynIsU=; b=Q7gWmmoTxRJ0PFy3iValsgFpIXbsZkZvvNPse1HvA81NvCt+W0xGHifKxi13wRk8WR so4lYnDtI5g4yMhVkt/aiwvc6aDrMrkLuq5TXyVlK4upcr/3Jt37sfiVjGMU4xvCgJzg Zc2RQG2k1obgn6TBOuANxH/66vQC9B+l5kxFvbZqtT1DB9Gn9adzabjpkHEup3sGpNmR HNwm7Al2SqJO4gNmA+GE6Ms8GTHOk6aAARP9hGLah2+P7zQPua2dtu+5/PExnISZyuKL w+gqVb2EzlJ9AoJxyIszGDQlMJbC5Nvx9fr6YZHW0m0F+MLnJbrjGpwCLxdapBYPL8nW sl4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j5si8496156ejm.413.2021.10.15.10.44.08; Fri, 15 Oct 2021 10:44:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237470AbhJOJh0 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 15 Oct 2021 05:37:26 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:53311 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236690AbhJOJh0 (ORCPT ); Fri, 15 Oct 2021 05:37:26 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 5FFA710000E; Fri, 15 Oct 2021 09:35:17 +0000 (UTC) Date: Fri, 15 Oct 2021 11:35:15 +0200 From: Miquel Raynal To: Paul Cercueil Cc: Richard Weinberger , Vignesh Raghavendra , Harvey Hunt , list@opendingux.net, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/3] mtd: rawnand: Export nand_read_page_hwecc_oob_first() Message-ID: <20211015113515.7b10a2d5@xps13> In-Reply-To: <89I01R.QTBARVYLTBT02@crapouillou.net> References: <20211009184952.24591-1-paul@crapouillou.net> <20211009184952.24591-3-paul@crapouillou.net> <20211015081313.60018976@xps13> <70G01R.2VROMW06O3O83@crapouillou.net> <20211015105146.3d2fbd08@xps13> <89I01R.QTBARVYLTBT02@crapouillou.net> 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 Paul, > >> */ > >> >> >> /* An ECC layout for using 4-bit ECC with small-page flash, >> storing > >> >> @@ -648,7 +580,7 @@ static int davinci_nand_attach_chip(struct >> >> nand_chip *chip) > >> >> } else if (chunks == 4 || chunks == 8) { > >> >> mtd_set_ooblayout(mtd, > >> >> nand_get_large_page_ooblayout()); > >> >> - chip->ecc.read_page = >> nand_davinci_read_page_hwecc_oob_first; > >> >> + chip->ecc.read_page = nand_read_page_hwecc_oob_first; > >> >> } else { > >> >> return -EIO; > >> >> } > >> >> diff --git a/drivers/mtd/nand/raw/nand_base.c >> >> b/drivers/mtd/nand/raw/nand_base.c > >> >> index 3d6c6e880520..cb5f343b9fa2 100644 > >> >> --- a/drivers/mtd/nand/raw/nand_base.c > >> >> +++ b/drivers/mtd/nand/raw/nand_base.c > >> >> @@ -3160,6 +3160,75 @@ static int nand_read_page_hwecc(struct >> >> nand_chip *chip, uint8_t *buf, > >> >> return max_bitflips; > >> >> } > >> >> >> +/** > >> >> + * nand_read_page_hwecc_oob_first - Hardware ECC page read >> with ECC > >> >> + * data read from OOB area > >> >> + * @chip: nand chip info structure > >> >> + * @buf: buffer to store read data > >> >> + * @oob_required: caller requires OOB data read to >> chip->oob_poi > >> >> + * @page: page number to read > >> >> + * > >> >> + * Hardware ECC for large page chips, require OOB to be read >> >> first. For this > >> > > >> > requires > >> > > >> > With this ECC configuration? > >> > > >> >> + * ECC mode, the write_page method is re-used from ECC_HW. >> These >> methods > >> > > >> > I do not understand this sentence nor the next one about >> syndrome. I > >> > believe it is related to your engine and should not leak into the >> > core. > >> > > >> >> + * read/write ECC from the OOB area, unlike the >> ECC_HW_SYNDROME >> support with > >> >> + * multiple ECC steps, follows the "infix ECC" scheme and >> >> reads/writes ECC from > >> >> + * the data area, by overwriting the NAND manufacturer bad >> block >> markings. > >> > > >> > That's a sentence I don't like. What do you mean exactly? > >> > > >> > What "Infix ECC" scheme is? > >> > > >> > Do you mean that unlike the syndrome mode it *does not* >> overwrite the > >> > BBM ? > >> >> I don't mean anything. I did not write that comment. I just moved >> the function verbatim with no changes. If something needs to be >> fixed, then it needs to be fixed before/after this patch. > > > > Well, this comment should be adapted because as-is I don't think it's > > wise to move it around. > > OK. > > I think it says that BBM can be overwritten with this configuration, but that would be if the OOB layout covers the BBM area. If the ooblayout prevents the BBM to be smatched I'm fine and this sentence should disappear because it's misleading. > >> >> >> + */ > >> >> +int nand_read_page_hwecc_oob_first(struct nand_chip *chip, >> uint8_t >> *buf, > >> >> + int oob_required, int page) > >> >> +{ > >> >> + struct mtd_info *mtd = nand_to_mtd(chip); > >> >> + int i, eccsize = chip->ecc.size, ret; > >> >> + int eccbytes = chip->ecc.bytes; > >> >> + int eccsteps = chip->ecc.steps; > >> >> + uint8_t *p = buf; > >> >> + uint8_t *ecc_code = chip->ecc.code_buf; > >> >> + unsigned int max_bitflips = 0; > >> >> + > >> >> + /* Read the OOB area first */ > >> >> + ret = nand_read_oob_op(chip, page, 0, chip->oob_poi, >> >> mtd->oobsize); > >> >> + if (ret) > >> >> + return ret; > >> >> + > >> >> + ret = nand_read_page_op(chip, page, 0, NULL, 0); > >> > > >> > Definitely not, your are requesting the chip to do the read_page > >> > operation twice. You only need a nand_change_read_column I >> believe. > >> >> Again, this code is just being moved around - don't shoot the >> messenger :) > > > > haha > > > > Well, now you touch the core, so I need to be more careful, and the > > code is definitely wrong, so even if we don't move that code off, you > > definitely want to fix it in order to improve your performances. > > I don't see the read_page being done twice? > > There's one read_oob, one read_page, then read_data in the loop. read_oob and read_page both end up sending READ0 and READSTART so they do request the chip to perform an internal read twice. You need this only once. The call to nand_read_page_op() should be a nand_change_read_column() with no data requested. > >> >> /** > >> >> * nand_read_page_syndrome - [REPLACEABLE] hardware ECC >> syndrome >> based page read > >> >> * @chip: nand chip info structure > >> >> diff --git a/include/linux/mtd/rawnand.h >> >> b/include/linux/mtd/rawnand.h > >> >> index b2f9dd3cbd69..5b88cd51fadb 100644 > >> >> --- a/include/linux/mtd/rawnand.h > >> >> +++ b/include/linux/mtd/rawnand.h > >> >> @@ -1539,6 +1539,8 @@ int nand_read_data_op(struct nand_chip >> *chip, >> void *buf, unsigned int len, > >> >> bool force_8bit, bool check_only); > >> >> int nand_write_data_op(struct nand_chip *chip, const void *buf, > >> >> unsigned int len, bool force_8bit); > >> >> +int nand_read_page_hwecc_oob_first(struct nand_chip *chip, >> uint8_t >> *buf, > >> >> + int oob_required, int page); > >> > > >> > You certainly want to add this symbol closer to the other >> read/write > >> > page helpers? > >> >> Where would that be? The other read/write page helpers are all >> "static" so they don't appear in any header. > > > > I believe we should keep this header local as long as there are no > > other users. > > I'll move it to internal.h then. Why do you want to put it there is there is only one user? Thanks, Miquèl