Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210808072643.GA5084@ubuntu> <20210816093126.442f74a1@xps13>
 <CAE9cyGQ+Bb3rQxiF4My9zXwg_+QYifaCckE=C6spAtN9_4dBFQ@mail.gmail.com> <20210819100334.6af2d86e@xps13>
In-Reply-To: <20210819100334.6af2d86e@xps13>
From:   Kestrel seventyfour <kestrelseventyfour@gmail.com>
Date:   Mon, 23 Aug 2021 13:19:43 +0200
Message-ID: <CAE9cyGSF2vTCptSZd3uMFaZPD=as=PwZY14S+zDhzjWCmsfmpQ@mail.gmail.com>
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use
 device tree setting
To:     Miquel Raynal <miquel.raynal@bootlin.com>
Cc:     Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Miqu=C3=A8l,

Am Do., 19. Aug. 2021 um 10:03 Uhr schrieb Miquel Raynal
<miquel.raynal@bootlin.com>:
>
> Hello,
>
> Kestrel seventyfour <kestrelseventyfour@gmail.com> wrote on Thu, 19 Aug
> 2021 09:21:42 +0200:
>
> > Hi Miqu=C3=A8l
> >
> > 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 202=
1
> > > 09:26:43 +0200:
> > >
> > > > Some devices use Micron NAND chips, which use on-die ECC. The hardc=
oded
> > > > setting of NAND_ECC_ENGINE_TYPE_SOFT makes them unusable, because t=
he
> > > > software ECC on top of the hardware ECC produces errors for every r=
ead
> > > > and write access, not to mention that booting does not work, becaus=
e
> > > > 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 c=
oded
> > > > 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 t=
o
> > > stable@vger.kernel.org a different version of the patch for the kerne=
l
> > > 5.4 IIUC.
> > >
> > > > Signed-off-by: Daniel Kestrel <kestrelseventyfour@gmail.com>
> > > > Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # tested on BT Ho=
me 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/ra=
w/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 *ch=
ip, const u_char *buf, int len)
> > > >
> > > >  static int xway_attach_chip(struct nand_chip *chip)
> > > >  {
> > > > -     chip->ecc.engine_type =3D NAND_ECC_ENGINE_TYPE_SOFT;
> > > > -
> > > >       if (chip->ecc.algo =3D=3D NAND_ECC_ALGO_UNKNOWN)
> > > >               chip->ecc.algo =3D NAND_ECC_ALGO_HAMMING;
> > >
> > > You also need to only set the Hamming algorithm when engine_type is
> > > TYPE_SOFT.
> > >
> > > Thanks,
> > > Miqu=C3=A8l
> >
> > 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 w=
onder
> > 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 =3D NAND_ECC_ENGINE_TYPE_SOFT &&
>         chip->ecc.algo =3D=3D NAND_ECC_ALGO_UNKNOWN)
>          chip->ecc.algo =3D 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=C3=A8l

thank you for your response.
If I remove the nand-ecc-xxx properties in the device tree, the device with
the Toshiba NAND chip is working. However, the device with the Micron
NAND fails with NO ECC functions supplied; hardware ECC not possible,
seems to be at line 5367 or equivalent.
https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_ba=
se.c#L5367

It looks like the micron nand driver supports on die only if its
specified int the
Device tree:
https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_mi=
cron.c#L511
The Micron NAND driver probably needs to set the ECC type to ON DIE if the
variable ondie contains the supported attribute?!

Any ideas? Second patch?

Thanks, Daniel.