linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	Richard Weinberger <richard@nod.at>,
	zhays@lexmark.com, zdhays@gmail.com,
	linux-kernel@vger.kernel.org,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	linux-mtd@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Piotr Sroka <piotrs@cadence.com>
Subject: Re: [PATCH v1] mtd: rawnand: micron: don't error out if internal ECC is set
Date: Fri, 17 Jan 2020 08:10:26 +0100	[thread overview]
Message-ID: <20200117071026.gydlruw2cxre2r2u@pengutronix.de> (raw)
In-Reply-To: <20200116192221.49986c13@xps13>

Hi Zak, Miquel,

On 20-01-16 19:22, Miquel Raynal wrote:
> Hi Zak,
> 
> zdhays@gmail.com wrote on Fri, 10 Jan 2020 11:25:01 -0500:
> 
> > From: Zak Hays <zdhays@gmail.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.

Which changes did you mean here?

> > 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.

It would be cool if a micron FAE can provide a document with all the
quirks and how those quirks can be handled.

> > 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.

By HW ECC you mean the host ecc controller?

> > 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.

+1 for 'find a reliable way to discriminate Micron parts features'

Regards,
  Marco

> > 
> > Signed-off-by: Zak Hays <zdhays@gmail.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
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-01-17  7:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 16:25 [PATCH v1] mtd: rawnand: micron: don't error out if internal ECC is set zdhays
2020-01-16 18:22 ` Miquel Raynal
2020-01-17  7:10   ` Marco Felsch [this message]
     [not found]     ` <CANZat+hHJy0H17xGmOP003_M1yWesJ2BjoPmW3hr7CS=HuQR+g@mail.gmail.com>
2020-01-17 19:32       ` Zak Hays

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=20200117071026.gydlruw2cxre2r2u@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=bbrezillon@kernel.org \
    --cc=frieder.schrempf@kontron.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=piotrs@cadence.com \
    --cc=richard@nod.at \
    --cc=tglx@linutronix.de \
    --cc=vigneshr@ti.com \
    --cc=zdhays@gmail.com \
    --cc=zhays@lexmark.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).