From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Schrempf Frieder <frieder.schrempf@kontron.de>
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: Wed, 17 Apr 2019 12:04:41 +0200 [thread overview]
Message-ID: <20190417120441.119ae33e@xps13> (raw)
In-Reply-To: <71f425a5-4028-1a8a-26db-b4b0860326dc@kontron.de>
Hi Frieder,
Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Thu, 21 Mar
2019 08:47:52 +0000:
> 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.
With this addressed please add my:
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Schrempf Frieder <frieder.schrempf@kontron.de>
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: Wed, 17 Apr 2019 12:04:41 +0200 [thread overview]
Message-ID: <20190417120441.119ae33e@xps13> (raw)
In-Reply-To: <71f425a5-4028-1a8a-26db-b4b0860326dc@kontron.de>
Hi Frieder,
Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Thu, 21 Mar
2019 08:47:52 +0000:
> 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.
With this addressed please add my:
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
next prev parent reply other threads:[~2019-04-17 10:05 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
2019-03-21 8:47 ` Schrempf Frieder
2019-04-17 10:04 ` Miquel Raynal [this message]
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 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 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 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=20190417120441.119ae33e@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@kontron.de \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.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 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.