From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: richard@nod.at, vigneshr@ti.com, boris.brezillon@collabora.com,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, bjorn.andersson@linaro.org
Subject: Re: [PATCH] mtd: rawnand: Do not check for bad block if bbt is unavailable
Date: Mon, 1 Feb 2021 15:18:24 +0100 [thread overview]
Message-ID: <20210201151824.5a9dca4a@xps13> (raw)
In-Reply-To: <20210130035412.6456-1-manivannan.sadhasivam@linaro.org>
Hi Manivannan,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote on Sat,
30 Jan 2021 09:24:12 +0530:
> The bbt pointer will be unavailable when NAND_SKIP_BBTSCAN option is
> set for a NAND chip. The intention is to skip scanning for the bad
> blocks during boot time.
I don't have the same understanding: this flag skips the bad block
table scan, not the bad block scan. We do want to scan all the devices
in order to construct a RAM based table.
> However, the MTD core will call
> _block_isreserved() and _block_isbad() callbacks unconditionally for
> the rawnand devices due to the callbacks always present while collecting
> the ecc stats.
>
> The _block_isreserved() callback for rawnand will bail out if bbt
> pointer is not available. But _block_isbad() will continue without
> checking for it. So this contradicts with the NAND_SKIP_BBTSCAN option
> since the bad block check will happen anyways (ie., not much difference
> between scanning for bad blocks and checking each block for bad ones).
>
> Hence, do not check for the bad block if bbt pointer is unavailable.
Not checking for bad blocks at all feels insane. I don't really get the
scope and goal of such change?
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/mtd/nand/raw/nand_base.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index c33fa1b1847f..f18cd1db79a9 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4286,6 +4286,9 @@ static int nand_block_isbad(struct mtd_info *mtd, loff_t offs)
> int chipnr = (int)(offs >> chip->chip_shift);
> int ret;
>
> + if (!chip->bbt)
> + return 0;
> +
> /* Select the NAND device */
> ret = nand_get_device(chip);
> if (ret)
Cheers,
Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org,
bjorn.andersson@linaro.org, boris.brezillon@collabora.com,
linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] mtd: rawnand: Do not check for bad block if bbt is unavailable
Date: Mon, 1 Feb 2021 15:18:24 +0100 [thread overview]
Message-ID: <20210201151824.5a9dca4a@xps13> (raw)
In-Reply-To: <20210130035412.6456-1-manivannan.sadhasivam@linaro.org>
Hi Manivannan,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote on Sat,
30 Jan 2021 09:24:12 +0530:
> The bbt pointer will be unavailable when NAND_SKIP_BBTSCAN option is
> set for a NAND chip. The intention is to skip scanning for the bad
> blocks during boot time.
I don't have the same understanding: this flag skips the bad block
table scan, not the bad block scan. We do want to scan all the devices
in order to construct a RAM based table.
> However, the MTD core will call
> _block_isreserved() and _block_isbad() callbacks unconditionally for
> the rawnand devices due to the callbacks always present while collecting
> the ecc stats.
>
> The _block_isreserved() callback for rawnand will bail out if bbt
> pointer is not available. But _block_isbad() will continue without
> checking for it. So this contradicts with the NAND_SKIP_BBTSCAN option
> since the bad block check will happen anyways (ie., not much difference
> between scanning for bad blocks and checking each block for bad ones).
>
> Hence, do not check for the bad block if bbt pointer is unavailable.
Not checking for bad blocks at all feels insane. I don't really get the
scope and goal of such change?
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/mtd/nand/raw/nand_base.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index c33fa1b1847f..f18cd1db79a9 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4286,6 +4286,9 @@ static int nand_block_isbad(struct mtd_info *mtd, loff_t offs)
> int chipnr = (int)(offs >> chip->chip_shift);
> int ret;
>
> + if (!chip->bbt)
> + return 0;
> +
> /* Select the NAND device */
> ret = nand_get_device(chip);
> if (ret)
Cheers,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-02-01 14:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 3:54 [PATCH] mtd: rawnand: Do not check for bad block if bbt is unavailable Manivannan Sadhasivam
2021-01-30 3:54 ` Manivannan Sadhasivam
2021-02-01 14:18 ` Miquel Raynal [this message]
2021-02-01 14:18 ` Miquel Raynal
2021-02-02 4:16 ` Manivannan Sadhasivam
2021-02-02 4:16 ` Manivannan Sadhasivam
2021-02-02 8:14 ` Miquel Raynal
2021-02-02 8:14 ` Miquel Raynal
2021-02-03 9:58 ` Manivannan Sadhasivam
2021-02-03 9:58 ` Manivannan Sadhasivam
2021-02-03 10:05 ` Miquel Raynal
2021-02-03 10:05 ` Miquel Raynal
2021-02-03 10:12 ` Manivannan Sadhasivam
2021-02-03 10:12 ` Manivannan Sadhasivam
2021-02-03 10:19 ` Boris Brezillon
2021-02-03 10:19 ` Boris Brezillon
2021-02-03 10:52 ` Manivannan Sadhasivam
2021-02-03 10:52 ` Manivannan Sadhasivam
2021-02-03 11:24 ` Boris Brezillon
2021-02-03 11:24 ` Boris Brezillon
2021-02-03 11:41 ` Manivannan Sadhasivam
2021-02-03 11:41 ` Manivannan Sadhasivam
2021-02-04 8:13 ` Miquel Raynal
2021-02-04 8:13 ` Miquel Raynal
2021-02-04 8:52 ` Manivannan Sadhasivam
2021-02-04 8:52 ` Manivannan Sadhasivam
2021-02-04 8:59 ` Boris Brezillon
2021-02-04 8:59 ` Boris Brezillon
2021-02-04 9:04 ` Miquel Raynal
2021-02-04 9:04 ` Miquel Raynal
2021-02-04 9:27 ` Boris Brezillon
2021-02-04 9:27 ` Boris Brezillon
2021-02-04 9:31 ` Miquel Raynal
2021-02-04 9:31 ` Miquel Raynal
2021-02-04 8:59 ` Miquel Raynal
2021-02-04 8:59 ` 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=20210201151824.5a9dca4a@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bjorn.andersson@linaro.org \
--cc=boris.brezillon@collabora.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=manivannan.sadhasivam@linaro.org \
--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.