All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Piotr Sroka <piotrs@cadence.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] - change calculating of position page containing BBM
Date: Thu, 19 Sep 2019 14:58:19 +0200	[thread overview]
Message-ID: <20190919145819.66e74aef@xps13> (raw)
In-Reply-To: <20190919124139.10856-1-piotrs@cadence.com>

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.

"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

______________________________________________________
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: Piotr Sroka <piotrs@cadence.com>
Cc: 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>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] - change calculating of position page containing BBM
Date: Thu, 19 Sep 2019 14:58:19 +0200	[thread overview]
Message-ID: <20190919145819.66e74aef@xps13> (raw)
In-Reply-To: <20190919124139.10856-1-piotrs@cadence.com>

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.

"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

  reply	other threads:[~2019-09-19 12:58 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 [this message]
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
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=20190919145819.66e74aef@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.