Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2352490imb; Mon, 4 Mar 2019 02:59:54 -0800 (PST) X-Google-Smtp-Source: AHgI3IbV2C57Cs2PT+25GZMdBUag0u3n3f4MomGvSQVL99SOCv2atm/i0D9B7pWfrgH0KNxYHNkm X-Received: by 2002:a62:f204:: with SMTP id m4mr19186158pfh.58.1551697194075; Mon, 04 Mar 2019 02:59:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551697194; cv=none; d=google.com; s=arc-20160816; b=cK92zc/6KbK2O8ovjP1zoh5kJZKfjXge+VDZw2Nt3uVuZepuc/Ad3T/VJ1FZ2qNf2A RHSZfE/PhSwo7tya0onL0tbM8aUyz6MylWQBSSkIh5JM4B4qjk4B2St3uXmVKPwTWldC z5gUNL1s1hEX0vlJvuzu9FBxBbsc0VWjbdt4eeFj7e6WR2Wd5iJqFdhCBY7CAKyVD2dQ LOS51lfkEXJNrGqE6fqfJ/h9KJjhIuIN6bk08Umlfo79a918ORu2Ykjk9mQ0wq63OjjM uEFeiIY+fN/nf9BnLqyBm9yvxSZwpDLRboCyDbkoxXuLE8rrx6Gx59+mXzsVwXkEnMZQ t9OA== 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=PyjhVZcStXR8y+srVkM3MJs1zvyEkfWpJcUrzd/m0WU=; b=iplPwOZjPmZJA6jb1rjldLBa8dSfTduVM+HNXQ1N1NgnQWLh1mLtYqX6/cnkLrXD6P XhG9OTVbFwv2M7DM0U964e1jNKbFUgzKxarou71rWTdybbpwiYDgS/UZ5g133d0scBOe ffMhKrgQxzzMoK3/qdZkM9PGoJ14gf47orq9wo47zd/FhUc3IHwt4mkusc5LPWCE0po6 LJXG+98QG0iB4+sRCQddThS13o0calysuCB9BVURglv5h1NGc7bR1TI8qGfE8qG3dyTk XE0UO+eEFVAtrVmdP+sphnQ96t/jYOCcRguLyOfRQ/yNzLNNhqYYF1CRhyD6GF8eLHGO 8b3w== 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 x3si5187165pll.376.2019.03.04.02.59.38; Mon, 04 Mar 2019 02:59:54 -0800 (PST) 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 S1726305AbfCDK7A convert rfc822-to-8bit (ORCPT + 99 others); Mon, 4 Mar 2019 05:59:00 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:41073 "EHLO relay9-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726079AbfCDK67 (ORCPT ); Mon, 4 Mar 2019 05:58:59 -0500 X-Originating-IP: 90.88.147.150 Received: from xps13 (aaubervilliers-681-1-27-150.w90-88.abo.wanadoo.fr [90.88.147.150]) (Authenticated sender: miquel.raynal@bootlin.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id D2353FF80F; Mon, 4 Mar 2019 10:58:54 +0000 (UTC) Date: Mon, 4 Mar 2019 11:58:53 +0100 From: Miquel Raynal To: Schrempf Frieder Cc: "bbrezillon@kernel.org" , "richard@nod.at" , Kyungmin Park , David Woodhouse , Brian Norris , "Marek Vasut" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v4 2/7] mtd: onenand: Store bad block marker position in chip struct Message-ID: <20190304115853.35216632@xps13> In-Reply-To: <20190218104122.18788-3-frieder.schrempf@kontron.de> References: <20190218104122.18788-1-frieder.schrempf@kontron.de> <20190218104122.18788-3-frieder.schrempf@kontron.de> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (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 Frieder, Schrempf Frieder wrote on Mon, 18 Feb 2019 10:42:41 +0000: > From: Frieder Schrempf > > The information about where the manufacturer puts the bad block > markers inside the bad block and in the OOB data is stored in > different places. Let's move this information to the chip struct, > as we did it for rawnand. > > Signed-off-by: Frieder Schrempf > --- > drivers/mtd/nand/onenand/onenand_base.c | 5 ++++- > drivers/mtd/nand/onenand/onenand_bbt.c | 3 --- > include/linux/mtd/onenand.h | 3 +++ > 3 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/mtd/nand/onenand/onenand_base.c b/drivers/mtd/nand/onenand/onenand_base.c > index 4ca4b194e7d7..f41d76248550 100644 > --- a/drivers/mtd/nand/onenand/onenand_base.c > +++ b/drivers/mtd/nand/onenand/onenand_base.c > @@ -2458,7 +2458,7 @@ static int onenand_default_block_markbad(struct mtd_info *mtd, loff_t ofs) > bbm->bbt[block >> 2] |= 0x01 << ((block & 0x03) << 1); > > /* We write two bytes, so we don't have to mess with 16-bit access */ > - ofs += mtd->oobsize + (bbm->badblockpos & ~0x01); > + ofs += mtd->oobsize + (this->badblockpos & ~0x01); > /* FIXME : What to do when marking SLC block in partition > * with MLC erasesize? For now, it is not advisable to > * create partitions containing both SLC and MLC regions. > @@ -3967,6 +3967,9 @@ int onenand_scan(struct mtd_info *mtd, int maxchips) > if (!(this->options & ONENAND_SKIP_INITIAL_UNLOCKING)) > this->unlock_all(mtd); > > + /* Set the bad block marker position */ > + this->badblockpos = ONENAND_BADBLOCK_POS; > + > ret = this->scan_bbt(mtd); > if ((!FLEXONENAND(this)) || ret) > return ret; > diff --git a/drivers/mtd/nand/onenand/onenand_bbt.c b/drivers/mtd/nand/onenand/onenand_bbt.c > index dde20487937d..57c31c81be18 100644 > --- a/drivers/mtd/nand/onenand/onenand_bbt.c > +++ b/drivers/mtd/nand/onenand/onenand_bbt.c > @@ -190,9 +190,6 @@ static int onenand_scan_bbt(struct mtd_info *mtd, struct nand_bbt_descr *bd) > if (!bbm->bbt) > return -ENOMEM; > > - /* Set the bad block position */ > - bbm->badblockpos = ONENAND_BADBLOCK_POS; > - > /* Set erase shift */ > bbm->bbt_erase_shift = this->erase_shift; > > diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h > index 0aaa98b219a4..e03aea7f7e61 100644 > --- a/include/linux/mtd/onenand.h > +++ b/include/linux/mtd/onenand.h > @@ -94,6 +94,7 @@ struct onenand_chip { > unsigned int technology; > unsigned int density_mask; > unsigned int options; > + int badblockpos; Any reason not to unsign this field? > > unsigned int erase_shift; > unsigned int page_shift; > @@ -188,6 +189,8 @@ struct onenand_chip { > /* Check byte access in OneNAND */ > #define ONENAND_CHECK_BYTE_ACCESS(addr) (addr & 0x1) > > +#define ONENAND_BADBLOCK_POS 0 > + > /* > * Options bits > */ Thanks, Miquèl