Re: [PATCH 2/3] mtd: nand: read (from DT) and store ECC algorithm

From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>,
	Kamal Dasu <kdasu.kdev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2/3] mtd: nand: read (from DT) and store ECC algorithm
Date: Fri, 1 Apr 2016 13:07:28 -0700	[thread overview]
Message-ID: <20160401200728.GA3645@localhost> (raw)
In-Reply-To: <CACna6rz6mYSxAr1oSjcLc__sSKM1XdUf-cGOFanGvuij0nNC5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Apr 01, 2016 at 09:32:40PM +0200, Rafał Miłecki wrote:
> On 1 April 2016 at 18:07, Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Feb 12, 2016 at 07:11:24PM +0100, Rafał Miłecki wrote:
> >> This will allow drivers handle ECC properly.
> >>
> >> Signed-off-by: Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >>  drivers/mtd/nand/nand_base.c | 6 +++++-
> >>  include/linux/mtd/nand.h     | 1 +
> >>  2 files changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> >> index f2c8ff3..ef977f3 100644
> >> --- a/drivers/mtd/nand/nand_base.c
> >> +++ b/drivers/mtd/nand/nand_base.c
> >> @@ -3979,7 +3979,7 @@ ident_done:
> >>  static int nand_dt_init(struct nand_chip *chip)
> >>  {
> >>       struct device_node *dn = nand_get_flash_node(chip);
> >> -     int ecc_mode, ecc_strength, ecc_step;
> >> +     int ecc_mode, ecc_algo, ecc_strength, ecc_step;
> >>
> >>       if (!dn)
> >>               return 0;
> >> @@ -3991,6 +3991,7 @@ static int nand_dt_init(struct nand_chip *chip)
> >>               chip->bbt_options |= NAND_BBT_USE_FLASH;
> >>
> >>       ecc_mode = of_get_nand_ecc_mode(dn);
> >> +     ecc_algo = of_get_nand_ecc_algo(dn);
> >>       ecc_strength = of_get_nand_ecc_strength(dn);
> >>       ecc_step = of_get_nand_ecc_step_size(dn);
> >>
> >> @@ -4003,6 +4004,9 @@ static int nand_dt_init(struct nand_chip *chip)
> >>       if (ecc_mode >= 0)
> >>               chip->ecc.mode = ecc_mode;
> >>
> >> +     if (ecc_algo >= 0)
> >> +             chip->ecc.algo = ecc_algo;
> >> +
> >
> > While this might appear to handle the absence of the nand-ecc-algo
> > property correctly, this isn't safe. This means that any existing DT
> > without the property will get treated as Hamming ECC. Perhaps we need
> > the enum to have a 0 value of 'NAND_ECC_ALGO_UNKNOWN' or something like
> > that?
> 
> You're commenting on an old series. If you take a look at:
> https://patchwork.ozlabs.org/patch/601180/
> that also got applied to the:
> https://github.com/linux-nand/linux/commits/nand/next
> repo, you'll see we have NAND_ECC_UNKNOWN there.

Ah, I guess I missed that because I was searching for the patch to
brcmnand (i.e., fixing the original problem you saw). AFAICT, this v2
series doesn't actually resolve your issue with brcmnand, no?

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html