All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Kestrel <kestrelseventyfour@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: rawnand: xway: No hardcoded ECC engine for Micron Chips
Date: Fri, 6 Aug 2021 18:56:58 +0200	[thread overview]
Message-ID: <20210806185658.5b4772a7@xps13> (raw)
In-Reply-To: <20210803143256.GA5209@ubuntu>

Hi Daniel,

Daniel Kestrel <kestrelseventyfour@gmail.com> wrote on Tue, 3 Aug 2021
16:32:56 +0200:

> Some lantiq xway devices use Micron NAND chips, which use on-die ECC.
> The hardcoded setting of NAND_ECC_ENGINE_TYPE_SOFT makes them unusable,
> because the software ECC on top of the hardware ECC produces errors for
> every read and write access, not to mention that booting does not work,
> because the boot loader uses the correct ECC when trying to load the
> kernel and stops loading on severe ECC errors.
> Removing the hardcoded settings would break a number of devices that
> work with those settings.
> Adding a DTB property was considered, but did not work, because devices
> of the same type but from different manufacture dates have different
> NAND chips and as such it is not possible to determine the NAND chip
> in advance or device specific.

I understand the problem and it is a very crappy situation.

> 
> Signed-off-by: Daniel Kestrel <kestrelseventyfour@gmail.com>
> ---
>  drivers/mtd/nand/raw/xway_nand.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
> index 26751976e502..20cb5ce2f3b0 100644
> --- a/drivers/mtd/nand/raw/xway_nand.c
> +++ b/drivers/mtd/nand/raw/xway_nand.c
> @@ -10,6 +10,7 @@
>  #include <linux/of_platform.h>
>  
>  #include <lantiq_soc.h>
> +#include "internals.h"
>  
>  /* nand registers */
>  #define EBU_ADDSEL1		0x24
> @@ -148,7 +149,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len)
>  
>  static int xway_attach_chip(struct nand_chip *chip)
>  {
> -	chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
> +	if (chip->manufacturer.desc->id != NAND_MFR_MICRON)
> +		chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;

Could we make this a little bit clever with something like this:
https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/mtd/nand/raw/nand_micron.c#L434

This is far from ideal, there should definitely be a change in the DT.
But given your initial comments I guess it is not possible.

Anyway I don't find a better way as, during the attach() call, we don't
yet ran the manufacturer code, hence we don't know if on-die ECC is
actually available or not.

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: Daniel Kestrel <kestrelseventyfour@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: rawnand: xway: No hardcoded ECC engine for Micron Chips
Date: Fri, 6 Aug 2021 18:56:58 +0200	[thread overview]
Message-ID: <20210806185658.5b4772a7@xps13> (raw)
In-Reply-To: <20210803143256.GA5209@ubuntu>

Hi Daniel,

Daniel Kestrel <kestrelseventyfour@gmail.com> wrote on Tue, 3 Aug 2021
16:32:56 +0200:

> Some lantiq xway devices use Micron NAND chips, which use on-die ECC.
> The hardcoded setting of NAND_ECC_ENGINE_TYPE_SOFT makes them unusable,
> because the software ECC on top of the hardware ECC produces errors for
> every read and write access, not to mention that booting does not work,
> because the boot loader uses the correct ECC when trying to load the
> kernel and stops loading on severe ECC errors.
> Removing the hardcoded settings would break a number of devices that
> work with those settings.
> Adding a DTB property was considered, but did not work, because devices
> of the same type but from different manufacture dates have different
> NAND chips and as such it is not possible to determine the NAND chip
> in advance or device specific.

I understand the problem and it is a very crappy situation.

> 
> Signed-off-by: Daniel Kestrel <kestrelseventyfour@gmail.com>
> ---
>  drivers/mtd/nand/raw/xway_nand.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
> index 26751976e502..20cb5ce2f3b0 100644
> --- a/drivers/mtd/nand/raw/xway_nand.c
> +++ b/drivers/mtd/nand/raw/xway_nand.c
> @@ -10,6 +10,7 @@
>  #include <linux/of_platform.h>
>  
>  #include <lantiq_soc.h>
> +#include "internals.h"
>  
>  /* nand registers */
>  #define EBU_ADDSEL1		0x24
> @@ -148,7 +149,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len)
>  
>  static int xway_attach_chip(struct nand_chip *chip)
>  {
> -	chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
> +	if (chip->manufacturer.desc->id != NAND_MFR_MICRON)
> +		chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;

Could we make this a little bit clever with something like this:
https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/mtd/nand/raw/nand_micron.c#L434

This is far from ideal, there should definitely be a change in the DT.
But given your initial comments I guess it is not possible.

Anyway I don't find a better way as, during the attach() call, we don't
yet ran the manufacturer code, hence we don't know if on-die ECC is
actually available or not.

Thanks,
Miquèl

  reply	other threads:[~2021-08-06 16:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 14:32 [PATCH] mtd: rawnand: xway: No hardcoded ECC engine for Micron Chips Daniel Kestrel
2021-08-03 14:32 ` Daniel Kestrel
2021-08-06 16:56 ` Miquel Raynal [this message]
2021-08-06 16:56   ` Miquel Raynal
2021-08-08  6:45   ` Kestrel seventyfour
2021-08-08  6:45     ` Kestrel seventyfour

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=20210806185658.5b4772a7@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=boris.brezillon@collabora.com \
    --cc=kestrelseventyfour@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.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.