From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Subject: Re: [PATCH 2/3] mtd: nand: read (from DT) and store ECC algorithm Date: Fri, 1 Apr 2016 23:23:55 +0200 Message-ID: References: <1455300685-27009-1-git-send-email-zajec5@gmail.com> <1455300685-27009-2-git-send-email-zajec5@gmail.com> <20160401160722.GC117117@google.com> <20160401200728.GA3645@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20160401200728.GA3645@localhost> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Brian Norris Cc: "linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Hauke Mehrtens , Kamal Dasu , Rob Herring , Frank Rowand , Grant Likely , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On 1 April 2016 at 22:07, Brian Norris wr= ote: > On Fri, Apr 01, 2016 at 09:32:40PM +0200, Rafa=C5=82 Mi=C5=82ecki wro= te: >> On 1 April 2016 at 18:07, Brian Norris = wrote: >> > On Fri, Feb 12, 2016 at 07:11:24PM +0100, Rafa=C5=82 Mi=C5=82ecki = wrote: >> >> This will allow drivers handle ECC properly. >> >> >> >> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki >> >> --- >> >> 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 =3D 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 *c= hip) >> >> chip->bbt_options |=3D NAND_BBT_USE_FLASH; >> >> >> >> ecc_mode =3D of_get_nand_ecc_mode(dn); >> >> + ecc_algo =3D of_get_nand_ecc_algo(dn); >> >> ecc_strength =3D of_get_nand_ecc_strength(dn); >> >> ecc_step =3D of_get_nand_ecc_step_size(dn); >> >> >> >> @@ -4003,6 +4004,9 @@ static int nand_dt_init(struct nand_chip *c= hip) >> >> if (ecc_mode >=3D 0) >> >> chip->ecc.mode =3D ecc_mode; >> >> >> >> + if (ecc_algo >=3D 0) >> >> + chip->ecc.algo =3D 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 n= eed >> > 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? That's correct. I'm planning to clean NAND subsystem first, then patch = brcmnand. --=20 Rafa=C5=82 -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ig0-x22d.google.com ([2607:f8b0:4001:c05::22d]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1am6YD-0006Pk-1s for linux-mtd@lists.infradead.org; Fri, 01 Apr 2016 21:24:18 +0000 Received: by mail-ig0-x22d.google.com with SMTP id sy18so6220310igc.1 for ; Fri, 01 Apr 2016 14:23:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160401200728.GA3645@localhost> References: <1455300685-27009-1-git-send-email-zajec5@gmail.com> <1455300685-27009-2-git-send-email-zajec5@gmail.com> <20160401160722.GC117117@google.com> <20160401200728.GA3645@localhost> Date: Fri, 1 Apr 2016 23:23:55 +0200 Message-ID: Subject: Re: [PATCH 2/3] mtd: nand: read (from DT) and store ECC algorithm From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= To: Brian Norris Cc: "linux-mtd@lists.infradead.org" , Hauke Mehrtens , Kamal Dasu , Rob Herring , Frank Rowand , Grant Likely , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 1 April 2016 at 22:07, Brian Norris wrote: > On Fri, Apr 01, 2016 at 09:32:40PM +0200, Rafa=C5=82 Mi=C5=82ecki wrote: >> On 1 April 2016 at 18:07, Brian Norris wro= te: >> > On Fri, Feb 12, 2016 at 07:11:24PM +0100, Rafa=C5=82 Mi=C5=82ecki wrot= e: >> >> This will allow drivers handle ECC properly. >> >> >> >> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki >> >> --- >> >> 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_bas= e.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 =3D 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 |=3D NAND_BBT_USE_FLASH; >> >> >> >> ecc_mode =3D of_get_nand_ecc_mode(dn); >> >> + ecc_algo =3D of_get_nand_ecc_algo(dn); >> >> ecc_strength =3D of_get_nand_ecc_strength(dn); >> >> ecc_step =3D of_get_nand_ecc_step_size(dn); >> >> >> >> @@ -4003,6 +4004,9 @@ static int nand_dt_init(struct nand_chip *chip) >> >> if (ecc_mode >=3D 0) >> >> chip->ecc.mode =3D ecc_mode; >> >> >> >> + if (ecc_algo >=3D 0) >> >> + chip->ecc.algo =3D 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 lik= e >> > 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? That's correct. I'm planning to clean NAND subsystem first, then patch brcm= nand. --=20 Rafa=C5=82