From: Schrempf Frieder <frieder.schrempf@kontron.de> To: Miquel Raynal <miquel.raynal@bootlin.com> Cc: "bbrezillon@kernel.org" <bbrezillon@kernel.org>, "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>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 2/7] mtd: onenand: Store bad block marker position in chip struct Date: Thu, 21 Mar 2019 08:47:52 +0000 [thread overview] Message-ID: <71f425a5-4028-1a8a-26db-b4b0860326dc@kontron.de> (raw) In-Reply-To: <20190304115853.35216632@xps13> On 04.03.19 11:58, Miquel Raynal wrote: > Hi Frieder, > > Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Mon, 18 Feb > 2019 10:42:41 +0000: > >> 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; > > Any reason not to unsign this field? It was signed so far, but you're right that it makes more sense to unsign it. > >> >> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Schrempf Frieder <frieder.schrempf@kontron.de> To: Miquel Raynal <miquel.raynal@bootlin.com> Cc: "bbrezillon@kernel.org" <bbrezillon@kernel.org>, "richard@nod.at" <richard@nod.at>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Marek Vasut <marek.vasut@gmail.com>, Kyungmin Park <kyungmin.park@samsung.com>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, Brian Norris <computersforpeace@gmail.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v4 2/7] mtd: onenand: Store bad block marker position in chip struct Date: Thu, 21 Mar 2019 08:47:52 +0000 [thread overview] Message-ID: <71f425a5-4028-1a8a-26db-b4b0860326dc@kontron.de> (raw) In-Reply-To: <20190304115853.35216632@xps13> On 04.03.19 11:58, Miquel Raynal wrote: > Hi Frieder, > > Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Mon, 18 Feb > 2019 10:42:41 +0000: > >> 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; > > Any reason not to unsign this field? It was signed so far, but you're right that it makes more sense to unsign it. > >> >> 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 > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-03-21 8:47 UTC|newest] Thread overview: 36+ 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 ` 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-02-18 10:42 ` Schrempf Frieder 2019-04-17 10:03 ` Miquel Raynal 2019-04-17 10:03 ` Miquel Raynal 2019-02-18 10:42 ` [PATCH v4 2/7] mtd: onenand: Store bad block marker position " Schrempf Frieder 2019-02-18 10:42 ` Schrempf Frieder 2019-03-04 10:58 ` Miquel Raynal 2019-03-04 10:58 ` Miquel Raynal 2019-03-21 8:47 ` Schrempf Frieder [this message] 2019-03-21 8:47 ` Schrempf Frieder 2019-04-17 10:04 ` Miquel Raynal 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-02-18 10:42 ` Schrempf Frieder 2019-04-17 10:05 ` Miquel Raynal 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-02-18 10:42 ` Schrempf Frieder 2019-04-17 10:05 ` Miquel Raynal 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-02-18 10:42 ` Schrempf Frieder 2019-03-04 11:21 ` Miquel Raynal 2019-03-04 11:21 ` Miquel Raynal 2019-03-21 9:04 ` Schrempf Frieder 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-02-18 10:42 ` Schrempf Frieder 2019-04-17 10:08 ` Miquel Raynal 2019-04-17 10:08 ` Miquel Raynal 2019-02-18 10:42 ` [PATCH v4 7/7] mtd: rawnand: AMD: " Schrempf Frieder 2019-02-18 10:42 ` Schrempf Frieder 2019-04-17 10:08 ` Miquel Raynal 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=71f425a5-4028-1a8a-26db-b4b0860326dc@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.