linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Schrempf Frieder <frieder.schrempf@kontron.de>
To: "bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"richard@nod.at" <richard@nod.at>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	"Marek Vasut" <marek.vasut@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Schrempf Frieder <frieder.schrempf@kontron.de>
Subject: [PATCH v4 2/7] mtd: onenand: Store bad block marker position in chip struct
Date: Mon, 18 Feb 2019 10:42:41 +0000	[thread overview]
Message-ID: <20190218104122.18788-3-frieder.schrempf@kontron.de> (raw)
In-Reply-To: <20190218104122.18788-1-frieder.schrempf@kontron.de>

From: Frieder Schrempf <frieder.schrempf@kontron.de>

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 <frieder.schrempf@kontron.de>
---
 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;
 
 	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
  */
-- 
2.17.1

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2019-02-18 10:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-18 10:42 [PATCH v4 0/7] mtd: rawnand: Support bad block markers in first, second or last page Schrempf Frieder
2019-02-18 10:42 ` [PATCH v4 1/7] mtd: rawnand: Always store info about bad block markers in chip struct Schrempf Frieder
2019-04-17 10:03   ` Miquel Raynal
2019-02-18 10:42 ` Schrempf Frieder [this message]
2019-03-04 10:58   ` [PATCH v4 2/7] mtd: onenand: Store bad block marker position " Miquel Raynal
2019-03-21  8:47     ` Schrempf Frieder
2019-04-17 10:04       ` Miquel Raynal
2019-02-18 10:42 ` [PATCH v4 3/7] mtd: nand: Cleanup flags and fields for bad block marker position Schrempf Frieder
2019-04-17 10:05   ` Miquel Raynal
2019-02-18 10:42 ` [PATCH v4 4/7] mtd: nand: Make flags for bad block marker position more granular Schrempf Frieder
2019-04-17 10:05   ` Miquel Raynal
2019-02-18 10:42 ` [PATCH v4 5/7] mtd: rawnand: Support bad block markers in first, second or last page Schrempf Frieder
2019-03-04 11:21   ` Miquel Raynal
2019-03-21  9:04     ` Schrempf Frieder
2019-02-18 10:42 ` [PATCH v4 6/7] mtd: rawnand: ESMT: Also use the last page for bad block markers Schrempf Frieder
2019-04-17 10:08   ` Miquel Raynal
2019-02-18 10:42 ` [PATCH v4 7/7] mtd: rawnand: AMD: " Schrempf Frieder
2019-04-17 10:08   ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190218104122.18788-3-frieder.schrempf@kontron.de \
    --to=frieder.schrempf@kontron.de \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).