All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>, linux-mtd@lists.infradead.org
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>
Subject: Re: [PATCH 1/3] mtd: rawnand: Add a NAND_NO_BBM_QUIRK flag
Date: Mon, 27 Apr 2020 09:28:36 +0200	[thread overview]
Message-ID: <20200427092836.40152b2a@collabora.com> (raw)
In-Reply-To: <20200427072453.375642-1-boris.brezillon@collabora.com>

On Mon, 27 Apr 2020 09:24:51 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> Some controllers with embedded ECC engines override the BBM marker with
> data or ECC bytes, thus making bad block detection through bad block
> marker impossible. Let's flag those chips so the core knows it shouldn't
> check the BBM and consider all blocks good.
> 
> This should allow us to get rid of two implementers of the
> legacy.block_bad() hook.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
>  drivers/mtd/nand/raw/nand_base.c | 3 +++
>  include/linux/mtd/rawnand.h      | 8 ++++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index f81b54634061..749ef0b40684 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -345,6 +345,9 @@ static int nand_block_bad(struct nand_chip *chip, loff_t ofs)
>  
>  static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs)
>  {
> +	if (chip->options & NAND_NO_BBM_QUIRK)
> +		return 0;
> +
>  	if (chip->legacy.block_bad)
>  		return chip->legacy.block_bad(chip, ofs);
>  
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 99f4ac47c8d3..37613dd9e04b 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -222,6 +222,14 @@ enum nand_ecc_algo {
>   */
>  #define NAND_KEEP_TIMINGS	0x00800000
>  
> +/*
> + * Some controllers with pipelined ECC engines override the BBM marker with
> + * data or ECC bytes, thus making bad block detection through bad block marker
> + * impossible. Let's flag those chips so the core knows it shouldn't check the
> + * BBM and consider all blocks good.
> + */
> +#define NAND_NO_BBM_QUIRK	0

Oops, should be 

#define NAND_NO_BBM_QUIRK	0x08000000

I'll have to rebase it on Miquel's series re-ordering the flag
definitions and using the BIT() macro anyway. But please don't take this
as an excuse for not reviewing this version :P.

> +
>  /* Cell info constants */
>  #define NAND_CI_CHIPNR_MSK	0x03
>  #define NAND_CI_CELLTYPE_MSK	0x0C


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2020-04-27  7:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  7:24 [PATCH 1/3] mtd: rawnand: Add a NAND_NO_BBM_QUIRK flag Boris Brezillon
2020-04-27  7:24 ` [PATCH 2/3] mtd: rawnand: cafe: Set the " Boris Brezillon
2020-04-27 19:28   ` Miquel Raynal
2020-04-27  7:24 ` [PATCH 3/3] mtd: rawnand: diskonchip: " Boris Brezillon
2020-04-27 19:30   ` Miquel Raynal
2020-04-27  7:28 ` Boris Brezillon [this message]
2020-04-27 19:30   ` [PATCH 1/3] mtd: rawnand: Add a " Miquel Raynal
2020-04-27 19:26 ` 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=20200427092836.40152b2a@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@microchip.com \
    --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.