linux-kernel - Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use device tree setting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9cyGQ+Bb3rQxiF4My9zXwg_+QYifaCckE=C6spAtN9_4dBFQ@mail.gmail.com>
Date:   Thu, 19 Aug 2021 09:21:42 +0200
From:   Kestrel seventyfour <kestrelseventyfour@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mtd: rawnand: xway: No hardcoded ECC engine, use
 device tree setting

Hi Miquèl

Am Mo., 16. Aug. 2021 um 09:31 Uhr schrieb Miquel Raynal
<miquel.raynal@...tlin.com>:
>
> Hi Daniel,
>
> Daniel Kestrel <kestrelseventyfour@...il.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@...r.kernel.org a different version of the patch for the kernel
> 5.4 IIUC.
>
> > Signed-off-by: Daniel Kestrel <kestrelseventyfour@...il.com>
> > Tested-by: Aleksander Jan Bajkowski <olek2@...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?

Thanks, Daniel.