linux-kernel - Re: [PATCH v1] mtd: rawnand: micron: don't error out if internal ECC is set

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]

Date:   Thu, 16 Jan 2020 19:22:21 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     zdhays@...il.com
Cc:     zhays@...mark.com, Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Piotr Sroka <piotrs@...ence.com>,
        Marco Felsch <m.felsch@...gutronix.de>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mtd: rawnand: micron: don't error out if internal
 ECC is set

Hi Zak,

zdhays@...il.com wrote on Fri, 10 Jan 2020 11:25:01 -0500:

> From: Zak Hays <zdhays@...il.com>
> 
> Recent changes to the driver require use of on-die correction if
> the internal ECC enable bit is set. On some Micron parts, this bit
> is enabled by default and there is no method for disabling it.
> 
> This is a false assumption though as that bit being enabled does not
> necessarily mean that the on-die ECC *has* to be used. It has been
> verified with a Micron FAE that other methods of error correction are
> still valid even if this bit is set.
> 
> HW ECC offers generally higher performance than on-die so it is
> preferred in some situations. This also allows multiple NAND parts to
> be supported on the same PCB as some parts may not support on-die
> error correction.
> 
> With that in mind, only throw a warning that the on-die bit is set
> and allow the init to continue.

I don't think I can take this patch as-is. We must find a reliable way
to discriminate Micron parts features. If we cannot (I think we can't
before of the endless list of bugs they have introduced without
documenting them), the best way is to build a static table.

> 
> Signed-off-by: Zak Hays <zdhays@...il.com>
> ---
>  drivers/mtd/nand/raw/nand_micron.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> index 56654030ec7f..ec40c76443be 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -455,9 +455,7 @@ static int micron_nand_init(struct nand_chip *chip)
>  
>  	if (ondie == MICRON_ON_DIE_MANDATORY &&
>  	    chip->ecc.mode != NAND_ECC_ON_DIE) {
> -		pr_err("On-die ECC forcefully enabled, not supported\n");
> -		ret = -EINVAL;
> -		goto err_free_manuf_data;
> +		pr_warn("WARNING: On-die ECC forcefully enabled, use caution with other methods\n");
>  	}
>  
>  	if (chip->ecc.mode == NAND_ECC_ON_DIE) {

Thanks,
Miquèl