From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Schrempf Frieder <frieder.schrempf@kontron.de>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
Boris Brezillon <bbrezillon@kernel.org>,
Richard Weinberger <richard@nod.at>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marek Vasut <marek.vasut@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Piotr Sroka <piotrs@cadence.com>
Subject: Re: [PATCH] - change calculating of position page containing BBM
Date: Thu, 19 Sep 2019 15:18:20 +0200 [thread overview]
Message-ID: <20190919151820.2bb8313d@xps13> (raw)
In-Reply-To: <f03d93a5-4393-2405-b597-80b762059f01@kontron.de>
Hello,
Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Thu, 19 Sep
2019 13:15:08 +0000:
> On 19.09.19 14:58, Miquel Raynal wrote:
> > Hi Piotr,
> >
> > Piotr Sroka <piotrs@cadence.com> wrote on Thu, 19 Sep 2019 13:41:35
> > +0100:
> >
> >> Change calculating of position page containing BBM
> >>
> >> If none of BBM flags is set then function nand_bbm_get_next_page
> >> reports EINVAL. It causes that BBM is not read at all during scanning
> >> factory bad blocks. The result is that the BBT table is build without
> >> checking factory BBM at all. For Micron flash memories none of this
> >> flag is set if page size is different than 2048 bytes.
>
> I wonder if it wouldn't be better to fix the Micron driver instead:
>
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -448,6 +448,8 @@ static int micron_nand_init(struct nand_chip *chip)
>
> if (mtd->writesize == 2048)
> chip->options |= NAND_BBM_FIRSTPAGE |
> NAND_BBM_SECONDPAGE;
> + else
> + chip->options |= NAND_BBM_FIRSTPAGE;
That's what I forgot in my last answer to this thread, I think I only
told Piotr privately: I would like both. I think it is important to fix
the bbm_get_next_page function but for clarity, setting the FIRSTPAGE
flag in Micron's driver seems also pertinent.
>
> ondie = micron_supports_on_die_ecc(chip);
>
>
> >
> > "none of these flags are set"
> >
> >>
> >> This patch changes the nand_bbm_get_next_page function.
> >
> > "Address this regression by changing the
> > nand_bbm_get_next_page_function."
> >
> >> It will return 0 if none of BBM flag is set and page parameter is 0.
> >
> > no BBM flag is set
> >
> >> After that modification way of discovering factory bad blocks will work
> >> similar as in kernel version 5.1.
> >>
> >
> > Fixes + stable tags would be great!
> >
> >> Signed-off-by: Piotr Sroka <piotrs@cadence.com>
> >> ---
> >> drivers/mtd/nand/raw/nand_base.c | 8 ++++++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> >> index 5c2c30a7dffa..f64e3b6605c6 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -292,12 +292,16 @@ int nand_bbm_get_next_page(struct nand_chip *chip, int page)
> >> struct mtd_info *mtd = nand_to_mtd(chip);
> >> int last_page = ((mtd->erasesize - mtd->writesize) >>
> >> chip->page_shift) & chip->pagemask;
> >> + unsigned int bbm_flags = NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE
> >> + | NAND_BBM_LASTPAGE;
> >>
> >> + if (page == 0 && !(chip->options & bbm_flags))
> >> + return 0;
> >> if (page == 0 && chip->options & NAND_BBM_FIRSTPAGE)
> >> return 0;
> >> - else if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE)
> >> + if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE)
> >> return 1;
> >> - else if (page <= last_page && chip->options & NAND_BBM_LASTPAGE)
> >> + if (page <= last_page && chip->options & NAND_BBM_LASTPAGE)
> >> return last_page;
> >>
> >> return -EINVAL;
> >
> > Lookgs good otherwise.
> >
> > Thanks,
> > Miquèl
> >
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: Piotr Sroka <piotrs@cadence.com>,
Richard Weinberger <richard@nod.at>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
"Marek Vasut" <marek.vasut@gmail.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
"Boris Brezillon" <bbrezillon@kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] - change calculating of position page containing BBM
Date: Thu, 19 Sep 2019 15:18:20 +0200 [thread overview]
Message-ID: <20190919151820.2bb8313d@xps13> (raw)
In-Reply-To: <f03d93a5-4393-2405-b597-80b762059f01@kontron.de>
Hello,
Schrempf Frieder <frieder.schrempf@kontron.de> wrote on Thu, 19 Sep
2019 13:15:08 +0000:
> On 19.09.19 14:58, Miquel Raynal wrote:
> > Hi Piotr,
> >
> > Piotr Sroka <piotrs@cadence.com> wrote on Thu, 19 Sep 2019 13:41:35
> > +0100:
> >
> >> Change calculating of position page containing BBM
> >>
> >> If none of BBM flags is set then function nand_bbm_get_next_page
> >> reports EINVAL. It causes that BBM is not read at all during scanning
> >> factory bad blocks. The result is that the BBT table is build without
> >> checking factory BBM at all. For Micron flash memories none of this
> >> flag is set if page size is different than 2048 bytes.
>
> I wonder if it wouldn't be better to fix the Micron driver instead:
>
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -448,6 +448,8 @@ static int micron_nand_init(struct nand_chip *chip)
>
> if (mtd->writesize == 2048)
> chip->options |= NAND_BBM_FIRSTPAGE |
> NAND_BBM_SECONDPAGE;
> + else
> + chip->options |= NAND_BBM_FIRSTPAGE;
That's what I forgot in my last answer to this thread, I think I only
told Piotr privately: I would like both. I think it is important to fix
the bbm_get_next_page function but for clarity, setting the FIRSTPAGE
flag in Micron's driver seems also pertinent.
>
> ondie = micron_supports_on_die_ecc(chip);
>
>
> >
> > "none of these flags are set"
> >
> >>
> >> This patch changes the nand_bbm_get_next_page function.
> >
> > "Address this regression by changing the
> > nand_bbm_get_next_page_function."
> >
> >> It will return 0 if none of BBM flag is set and page parameter is 0.
> >
> > no BBM flag is set
> >
> >> After that modification way of discovering factory bad blocks will work
> >> similar as in kernel version 5.1.
> >>
> >
> > Fixes + stable tags would be great!
> >
> >> Signed-off-by: Piotr Sroka <piotrs@cadence.com>
> >> ---
> >> drivers/mtd/nand/raw/nand_base.c | 8 ++++++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> >> index 5c2c30a7dffa..f64e3b6605c6 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -292,12 +292,16 @@ int nand_bbm_get_next_page(struct nand_chip *chip, int page)
> >> struct mtd_info *mtd = nand_to_mtd(chip);
> >> int last_page = ((mtd->erasesize - mtd->writesize) >>
> >> chip->page_shift) & chip->pagemask;
> >> + unsigned int bbm_flags = NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE
> >> + | NAND_BBM_LASTPAGE;
> >>
> >> + if (page == 0 && !(chip->options & bbm_flags))
> >> + return 0;
> >> if (page == 0 && chip->options & NAND_BBM_FIRSTPAGE)
> >> return 0;
> >> - else if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE)
> >> + if (page <= 1 && chip->options & NAND_BBM_SECONDPAGE)
> >> return 1;
> >> - else if (page <= last_page && chip->options & NAND_BBM_LASTPAGE)
> >> + if (page <= last_page && chip->options & NAND_BBM_LASTPAGE)
> >> return last_page;
> >>
> >> return -EINVAL;
> >
> > Lookgs good otherwise.
> >
> > Thanks,
> > Miquèl
> >
Thanks,
Miquèl
next prev parent reply other threads:[~2019-09-19 13:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 12:41 [PATCH] - change calculating of position page containing BBM Piotr Sroka
2019-09-19 12:41 ` Piotr Sroka
2019-09-19 12:58 ` Miquel Raynal
2019-09-19 12:58 ` Miquel Raynal
2019-09-19 13:15 ` Schrempf Frieder
2019-09-19 13:15 ` Schrempf Frieder
2019-09-19 13:18 ` Miquel Raynal [this message]
2019-09-19 13:18 ` Miquel Raynal
2019-09-19 13:33 ` Schrempf Frieder
2019-09-19 13:33 ` Schrempf Frieder
2019-09-23 12:13 ` Piotr Sroka
2019-09-23 12:13 ` Piotr Sroka
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=20190919151820.2bb8313d@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@kontron.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=piotrs@cadence.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/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.