All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Kestrel seventyfour <kestrelseventyfour@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting
Date: Thu, 19 Aug 2021 10:03:34 +0200	[thread overview]
Message-ID: <20210819100334.6af2d86e@xps13> (raw)
In-Reply-To: <CAE9cyGQ+Bb3rQxiF4My9zXwg_+QYifaCckE=C6spAtN9_4dBFQ@mail.gmail.com>

Hello,

Kestrel seventyfour <kestrelseventyfour@gmail.com> wrote on Thu, 19 Aug
2021 09:21:42 +0200:

> Hi Miquèl
> 
> Am Mo., 16. Aug. 2021 um 09:31 Uhr schrieb Miquel Raynal
> <miquel.raynal@bootlin.com>:
> >
> > Hi Daniel,
> >
> > Daniel Kestrel <kestrelseventyfour@gmail.com> wrote on Sun, 8 Aug 2021
> > 09:26:43 +0200:
> >  
> > > Some 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.
> > > This patch requires the devices that currently work with the hard coded
> > > setting to set the nand-ecc-mode property to soft in their device
> > > tree.
> > >  
> >
> > Please add a Fixes: and Cc: stable tags, you will also need to send to
> > stable@vger.kernel.org a different version of the patch for the kernel
> > 5.4 IIUC.
> >  
> > > Signed-off-by: Daniel Kestrel <kestrelseventyfour@gmail.com>
> > > Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # tested on BT Home Hub 5A
> > > ---
> > >  drivers/mtd/nand/raw/xway_nand.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
> > > index 26751976e502..0a4b0aa7dd4c 100644
> > > --- a/drivers/mtd/nand/raw/xway_nand.c
> > > +++ b/drivers/mtd/nand/raw/xway_nand.c
> > > @@ -148,8 +148,6 @@ 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->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
> > >               chip->ecc.algo = NAND_ECC_ALGO_HAMMING;  
> >
> > You also need to only set the Hamming algorithm when engine_type is
> > TYPE_SOFT.
> >
> > Thanks,
> > Miquèl  
> 
> I am really struggling with what to do. For one of the affected
> devices, they created two device
> trees, one for Micron and one for all others. Which obviously had no
> effect due to the
> hardcoded settings, which led me to Patch 2 and I thought, so be it.
> But the process to figure
> out if ones device has Micron Chips is essentially flashing an image
> and if it does not work,
> use the stock OEM recovery and try the other image.
> However, since Micron is the only chip that is treated differently, I wonder
> if your first proposal, even though it is hacky, is the better
> approach to solve the issue
> for the Micron devices not booting and throwing ECC errors. What do you think?
> Follow up first patch or this one?

I am not sure we understood each other, your patch is fine, but you
need to do something like:

static int xway_attach_chip(struct nand_chip *chip)
{
    if (chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT &&
        chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
         chip->ecc.algo = NAND_ECC_ALGO_HAMMING;

In the DT you should not force any ECC engine (drop the nand-ecc-xxx
properties) and let the core handle it. It will probably choose the
most suitable engines for you.

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: Kestrel seventyfour <kestrelseventyfour@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting
Date: Thu, 19 Aug 2021 10:03:34 +0200	[thread overview]
Message-ID: <20210819100334.6af2d86e@xps13> (raw)
In-Reply-To: <CAE9cyGQ+Bb3rQxiF4My9zXwg_+QYifaCckE=C6spAtN9_4dBFQ@mail.gmail.com>

Hello,

Kestrel seventyfour <kestrelseventyfour@gmail.com> wrote on Thu, 19 Aug
2021 09:21:42 +0200:

> Hi Miquèl
> 
> Am Mo., 16. Aug. 2021 um 09:31 Uhr schrieb Miquel Raynal
> <miquel.raynal@bootlin.com>:
> >
> > Hi Daniel,
> >
> > Daniel Kestrel <kestrelseventyfour@gmail.com> wrote on Sun, 8 Aug 2021
> > 09:26:43 +0200:
> >  
> > > Some 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.
> > > This patch requires the devices that currently work with the hard coded
> > > setting to set the nand-ecc-mode property to soft in their device
> > > tree.
> > >  
> >
> > Please add a Fixes: and Cc: stable tags, you will also need to send to
> > stable@vger.kernel.org a different version of the patch for the kernel
> > 5.4 IIUC.
> >  
> > > Signed-off-by: Daniel Kestrel <kestrelseventyfour@gmail.com>
> > > Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # tested on BT Home Hub 5A
> > > ---
> > >  drivers/mtd/nand/raw/xway_nand.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/xway_nand.c b/drivers/mtd/nand/raw/xway_nand.c
> > > index 26751976e502..0a4b0aa7dd4c 100644
> > > --- a/drivers/mtd/nand/raw/xway_nand.c
> > > +++ b/drivers/mtd/nand/raw/xway_nand.c
> > > @@ -148,8 +148,6 @@ 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->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
> > >               chip->ecc.algo = NAND_ECC_ALGO_HAMMING;  
> >
> > You also need to only set the Hamming algorithm when engine_type is
> > TYPE_SOFT.
> >
> > Thanks,
> > Miquèl  
> 
> I am really struggling with what to do. For one of the affected
> devices, they created two device
> trees, one for Micron and one for all others. Which obviously had no
> effect due to the
> hardcoded settings, which led me to Patch 2 and I thought, so be it.
> But the process to figure
> out if ones device has Micron Chips is essentially flashing an image
> and if it does not work,
> use the stock OEM recovery and try the other image.
> However, since Micron is the only chip that is treated differently, I wonder
> if your first proposal, even though it is hacky, is the better
> approach to solve the issue
> for the Micron devices not booting and throwing ECC errors. What do you think?
> Follow up first patch or this one?

I am not sure we understood each other, your patch is fine, but you
need to do something like:

static int xway_attach_chip(struct nand_chip *chip)
{
    if (chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT &&
        chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
         chip->ecc.algo = NAND_ECC_ALGO_HAMMING;

In the DT you should not force any ECC engine (drop the nand-ecc-xxx
properties) and let the core handle it. It will probably choose the
most suitable engines for you.

Thanks,
Miquèl

  reply	other threads:[~2021-08-19  8:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-08  7:26 [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting Daniel Kestrel
2021-08-08  7:26 ` Daniel Kestrel
2021-08-16  7:31 ` Miquel Raynal
2021-08-16  7:31   ` Miquel Raynal
2021-08-19  7:21   ` Kestrel seventyfour
2021-08-19  7:21     ` Kestrel seventyfour
2021-08-19  8:03     ` Miquel Raynal [this message]
2021-08-19  8:03       ` Miquel Raynal
2021-08-23 11:19       ` Kestrel seventyfour
2021-08-23 11:19         ` Kestrel seventyfour
2021-08-23 15:24         ` Miquel Raynal
2021-08-23 15:24           ` Miquel Raynal
2021-08-24  7:15           ` Kestrel seventyfour
2021-08-24  7:15             ` Kestrel seventyfour
2021-08-24 17:22             ` Miquel Raynal
2021-08-24 17:22               ` Miquel Raynal
2021-08-25  8:47               ` Kestrel seventyfour
2021-08-25  8:47                 ` Kestrel seventyfour
2021-08-25  8:51                 ` Miquel Raynal
2021-08-25  8:51                   ` Miquel Raynal
2021-08-25 14:07                   ` Kestrel seventyfour
2021-08-25 14:07                     ` Kestrel seventyfour
2021-08-25 15:31                     ` Miquel Raynal
2021-08-25 15:31                       ` Miquel Raynal
2021-08-26  5:27                       ` Kestrel seventyfour
2021-08-26  5:27                         ` Kestrel seventyfour
2021-09-16 19:38 ` Jan Hoffmann
2021-09-16 19:38   ` Jan Hoffmann
2021-09-17 17:01   ` Miquel Raynal
2021-09-17 17:01     ` Miquel Raynal
2021-09-17 17:45     ` Jan Hoffmann
2021-09-17 17:45       ` Jan Hoffmann
2021-09-17 19:32       ` Miquel Raynal
2021-09-17 19:32         ` Miquel Raynal
2021-09-18 21:26         ` Jan Hoffmann
2021-09-18 21:26           ` Jan Hoffmann
2021-09-27 16:31           ` Miquel Raynal
2021-09-27 16:31             ` Miquel Raynal
2021-09-27 20:32             ` Jan Hoffmann
2021-09-27 20:32               ` Jan Hoffmann
2021-09-28  8:49               ` Miquel Raynal
2021-09-28  8:49                 ` 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=20210819100334.6af2d86e@xps13 \
    --to=miquel.raynal@bootlin.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.