All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	boris.brezillon@kernel.org, linux-mtd@lists.infradead.org,
	kernel@pengutronix.de
Subject: Re: [PATCH] mtd: rawnand: micron: handle "ecc off" devices correctly
Date: Fri, 26 Jul 2019 10:28:58 +0200	[thread overview]
Message-ID: <20190726102858.3b4019d8@xps13> (raw)
In-Reply-To: <20190726074434.21627-1-m.felsch@pengutronix.de>

Hi Marco,

+ Richard
+ Working e-mail address for Boris

Marco Felsch <m.felsch@pengutronix.de> wrote on Fri, 26 Jul 2019
09:44:34 +0200:

> Some devices don't support ecc "official". By "official" I mean that the
> feature can be set trough the "SET FEATURE (EFh)" command but isn't
> reported to the "READ ID Parameter Tables". Because the "ECC Field"
> still says that it is disabled. This is applicable at least
> for the MT29F2G08ABAGA and MT29F2G08ABBGA devices. Even worse the
> datasheet describes the ECC feature in chapter "ECC Protection".
> 
> Currently the driver checks the "READ ID Parameter" field directly after
> we enabled the feature. If the check fails we return immediately but
> leave the ECC on. Now all future read/program cycles goes trough the ecc
> and the host nfc gets confused and reports ECC errors.
> 
> To address this in a common way we need to turn off the ECC directly
> after reading the "READ ID Parameter" and before checking the
> "ECC status".
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>

Good catch! However you report that on-die ECC correction is working
but you still disable it; any reason to do so ? Would it be better to
actually enable on-die ECC and explicitly mark these two chips as
buggy (see [1] for checking the chip IDs)?

[1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_macronix.c#L83

> ---
>  drivers/mtd/nand/raw/nand_micron.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> index 1622d3145587..fb199ad2f1a6 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -390,6 +390,14 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
>  	    (chip->id.data[4] & MICRON_ID_INTERNAL_ECC_MASK) != 0x2)
>  		return MICRON_ON_DIE_UNSUPPORTED;
>  
> +	/*
> +	 * It seems that there are devices which do not support ECC official.
> +	 * At least the MT29F2G08ABAGA / MT29F2G08ABBGA devices supports
> +	 * enabling the ECC feature but don't reflect that to the READ_ID table.
> +	 * So we have to guarantee that we disable the ECC feature directly
> +	 * after we did the READ_ID table command. Later we can evaluate the
> +	 * ECC_ENABLE support.
> +	 */
>  	ret = micron_nand_on_die_ecc_setup(chip, true);
>  	if (ret)
>  		return MICRON_ON_DIE_UNSUPPORTED;
> @@ -398,13 +406,13 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
>  	if (ret)
>  		return MICRON_ON_DIE_UNSUPPORTED;
>  
> -	if (!(id[4] & MICRON_ID_ECC_ENABLED))
> -		return MICRON_ON_DIE_UNSUPPORTED;
> -
>  	ret = micron_nand_on_die_ecc_setup(chip, false);
>  	if (ret)
>  		return MICRON_ON_DIE_UNSUPPORTED;
>  
> +	if (!(id[4] & MICRON_ID_ECC_ENABLED))
> +		return MICRON_ON_DIE_UNSUPPORTED;
> +
>  	ret = nand_readid_op(chip, 0, id, sizeof(id));
>  	if (ret)
>  		return MICRON_ON_DIE_UNSUPPORTED;

Thanks,
Miquèl

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

  reply	other threads:[~2019-07-26  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  7:44 [PATCH] mtd: rawnand: micron: handle "ecc off" devices correctly Marco Felsch
2019-07-26  8:28 ` Miquel Raynal [this message]
2019-07-26  8:34   ` Miquel Raynal
2019-07-26  8:59     ` Boris Brezillon
2019-07-26  8:54   ` Lucas Stach
2019-07-26  9:17     ` Miquel Raynal
2019-07-26  9:20       ` Miquel Raynal
2019-07-26  9:40         ` Marco Felsch
2019-07-26 13: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=20190726102858.3b4019d8@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=boris.brezillon@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=m.felsch@pengutronix.de \
    --cc=richard.weinberger@gmail.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.