Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5189873ybh; Wed, 7 Aug 2019 02:11:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyKtsNEWLmQY7E65hB+OuzbaJojZk8qcO+nxNf0K3hYX1AN3uwqmS2xRkWJWwLCAJQZRKLX X-Received: by 2002:a17:902:1122:: with SMTP id d31mr1581164pla.254.1565169083771; Wed, 07 Aug 2019 02:11:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565169083; cv=none; d=google.com; s=arc-20160816; b=LknwKsiIdvhfod1OxmFPUzDLEYSFHAOYBZwi6qd/RVC6KuZsL/lMjvDcekcbcRHQzg G0D33nMrXAkq9ZnZmd4VEee0Oc45vho53WG887OZP7J6K2NvRGCVKMjqiJs+segmQPLA gv0KmydJFvyL3DMl8dasMlPQcBHfITtTDNS5tWc9pYworAZtw984BTONSkgEv0DE9xB1 7RZNy7WASZY+CUmrBp6nC14Wnc3iXiJC/5odgtFjRJdfRjzsTgL4U5lsi/rHCmxcqBRC lYUU5jaJwT4NkcfN1Bjs2mSseI6yETgaBTcjlJoPeWIUMK+R5rHCO+n3j/uDPxTZ9ukK tTiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=sPKA7YAk/HSAd0nxngNjr5gmlWg/0UQOp3wXR0aBL8Q=; b=CYl5FzhxIfzhRMxgvdzUqu9szY9KwGcL5UWdOeH4Ye96SbH7DqBy9qfymzfWO9N8JN V27Av5hFrV/iLno+D4c2kKIfjkabaLNcEjJklKVM/4zi/Ka095S3CsHezacIVIcJonQ4 VAc17PBLfwk4pPiqySsyMi/ee3ZFkhiii4X/erxou+L2MyVoaFGwtZDpmZsvacM+tW/o 8k3I6ng7wnzY5c1uON6krBrdD7P645C+3xmaK6EzNDZDXIZHBa1HbFBsvH1F+/05+LZC S3p0dZ5TyaltFvrHPKLvLN8MGmDH8v+3IteBnug/+50OONmFcO28NblScRbrR5Q4SeFi /bNA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h9si16513030pju.77.2019.08.07.02.11.02; Wed, 07 Aug 2019 02:11:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728793AbfHGJJn convert rfc822-to-8bit (ORCPT + 99 others); Wed, 7 Aug 2019 05:09:43 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:53369 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728687AbfHGJJn (ORCPT ); Wed, 7 Aug 2019 05:09:43 -0400 X-Originating-IP: 86.250.200.211 Received: from xps13 (lfbn-1-17395-211.w86-250.abo.wanadoo.fr [86.250.200.211]) (Authenticated sender: miquel.raynal@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5C81E60010; Wed, 7 Aug 2019 09:09:38 +0000 (UTC) Date: Wed, 7 Aug 2019 11:09:37 +0200 From: Miquel Raynal To: shiva.linuxworks@gmail.com Cc: Richard Weinberger , David Woodhouse , Brian Norris , Marek Vasut , Vignesh Raghavendra , Boris Brezillon , Marcel Ziswiler , Frieder Schrempf , Shivamurthy Shastri , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Jeff Kletsky , Chuanhong Guo , liaoweixiong Subject: Re: [PATCH 3/8] mtd: nand: create ONFI table parsing instance Message-ID: <20190807110937.4dfe1746@xps13> In-Reply-To: <20190722055621.23526-4-sshivamurthy@micron.com> References: <20190722055621.23526-1-sshivamurthy@micron.com> <20190722055621.23526-4-sshivamurthy@micron.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Shiva, shiva.linuxworks@gmail.com wrote on Mon, 22 Jul 2019 07:56:16 +0200: > From: Shivamurthy Shastri "Create one generic ONFI table parsing instance" > > ONFI table parsing is common, as most of the variables are common > between raw and SPI NAND. The parsing function is instantiated in > onfi.c, which fills ONFI parameters into nand_memory_organization. ... into nand_memory_organization just as before. > > Signed-off-by: Shivamurthy Shastri > --- > drivers/mtd/nand/onfi.c | 32 ++++++++++++++++++++++++++++++++ > drivers/mtd/nand/raw/nand_onfi.c | 22 ++-------------------- > include/linux/mtd/onfi.h | 2 ++ > 3 files changed, 36 insertions(+), 20 deletions(-) > > diff --git a/drivers/mtd/nand/onfi.c b/drivers/mtd/nand/onfi.c > index 7aaf36dfc5e0..e78700894aea 100644 > --- a/drivers/mtd/nand/onfi.c > +++ b/drivers/mtd/nand/onfi.c > @@ -87,3 +87,35 @@ void sanitize_string(u8 *s, size_t len) > strim(s); > } > EXPORT_SYMBOL_GPL(sanitize_string); > + > +/** > + * fill_nand_memorg() - Parse ONFI table and fill memorg ^ parse_onfi_params() - Parse an ONFI table and fill a memory organization structure > + * @memorg: NAND memorg to be filled memory organization core structure to be filled > + * @p: ONFI table to be parsed > + * > + */ > +void parse_onfi_params(struct nand_memory_organization *memorg, > + struct nand_onfi_params *p) > +{ > + memorg->pagesize = le32_to_cpu(p->byte_per_page); > + > + /* > + * pages_per_block and blocks_per_lun may not be a power-of-2 size > + * (don't ask me who thought of this...). MTD assumes that these > + * dimensions will be power-of-2, so just truncate the remaining area. > + */ > + memorg->pages_per_eraseblock = > + 1 << (fls(le32_to_cpu(p->pages_per_block)) - 1); > + > + memorg->oobsize = le16_to_cpu(p->spare_bytes_per_page); > + > + memorg->luns_per_target = p->lun_count; > + memorg->planes_per_lun = 1 << p->interleaved_bits; > + > + /* See erasesize comment */ > + memorg->eraseblocks_per_lun = > + 1 << (fls(le32_to_cpu(p->blocks_per_lun)) - 1); > + memorg->max_bad_eraseblocks_per_lun = le32_to_cpu(p->blocks_per_lun); > + memorg->bits_per_cell = p->bits_per_cell; > +} > +EXPORT_SYMBOL_GPL(parse_onfi_params); > diff --git a/drivers/mtd/nand/raw/nand_onfi.c b/drivers/mtd/nand/raw/nand_onfi.c > index 2e8edfa636ef..263796d3298c 100644 > --- a/drivers/mtd/nand/raw/nand_onfi.c > +++ b/drivers/mtd/nand/raw/nand_onfi.c > @@ -181,30 +181,12 @@ int nand_onfi_detect(struct nand_chip *chip) > goto free_onfi_param_page; > } > > - memorg->pagesize = le32_to_cpu(p->byte_per_page); > - mtd->writesize = memorg->pagesize; > + parse_onfi_params(memorg, p); > > - /* > - * pages_per_block and blocks_per_lun may not be a power-of-2 size > - * (don't ask me who thought of this...). MTD assumes that these > - * dimensions will be power-of-2, so just truncate the remaining area. > - */ > - memorg->pages_per_eraseblock = > - 1 << (fls(le32_to_cpu(p->pages_per_block)) - 1); > + mtd->writesize = memorg->pagesize; > mtd->erasesize = memorg->pages_per_eraseblock * memorg->pagesize; > - > - memorg->oobsize = le16_to_cpu(p->spare_bytes_per_page); > mtd->oobsize = memorg->oobsize; > > - memorg->luns_per_target = p->lun_count; > - memorg->planes_per_lun = 1 << p->interleaved_bits; > - > - /* See erasesize comment */ > - memorg->eraseblocks_per_lun = > - 1 << (fls(le32_to_cpu(p->blocks_per_lun)) - 1); > - memorg->max_bad_eraseblocks_per_lun = le32_to_cpu(p->blocks_per_lun); > - memorg->bits_per_cell = p->bits_per_cell; > - > if (le16_to_cpu(p->features) & ONFI_FEATURE_16_BIT_BUS) > chip->options |= NAND_BUSWIDTH_16; > > diff --git a/include/linux/mtd/onfi.h b/include/linux/mtd/onfi.h > index 2c8a05a02bb0..4cacf4e9db6d 100644 > --- a/include/linux/mtd/onfi.h > +++ b/include/linux/mtd/onfi.h > @@ -183,5 +183,7 @@ void nand_bit_wise_majority(const void **srcbufs, > void *dstbuf, > unsigned int bufsize); > void sanitize_string(u8 *s, size_t len); > +void parse_onfi_params(struct nand_memory_organization *memorg, > + struct nand_onfi_params *p); > > #endif /* __LINUX_MTD_ONFI_H */ Thanks, Miquèl