From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: vigneshr@ti.com, kdasu.kdev@gmail.com, richard@nod.at,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-mtd@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com,
computersforpeace@gmail.com, sumit.semwal@linaro.org,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3] mtd: rawnand: brcmnand: correctly verify erased pages
Date: Tue, 12 May 2020 09:34:51 +0200 [thread overview]
Message-ID: <20200512093451.4cde5384@xps13> (raw)
In-Reply-To: <50E32C0E-7485-4180-A072-F7F1CFB45B06@gmail.com>
Hi Álvaro,
Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
09:24:32 +0200:
> Hi Miquèl
>
> > El 12 may 2020, a las 9:16, Miquel Raynal <miquel.raynal@bootlin.com> escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
> > 08:51:11 +0200:
> >
> >> The current code checks that the whole OOB area is erased.
> >> This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
> >> fail due to the usable OOB bytes not being 0xff.
> >> Correct this by only checking that data and ECC bytes aren't 0xff.
> >>
> >> Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
> >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> >> ---
> >> v3: Fix commit log and merge nand_check_erased_ecc_chunk calls.
> >> v2: Add Fixes tag
> >>
> >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 19 ++++++++++++++-----
> >> 1 file changed, 14 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> index e4e3ceeac38f..80fe01f03516 100644
> >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> @@ -2018,8 +2018,9 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
> >> static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> struct nand_chip *chip, void *buf, u64 addr)
> >> {
> >> + struct mtd_oob_region oobecc;
> >> int i, sas;
> >> - void *oob = chip->oob_poi;
> >> + void *oob;
> >> int bitflips = 0;
> >> int page = addr >> chip->page_shift;
> >> int ret;
> >> @@ -2035,11 +2036,19 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> if (ret)
> >> return ret;
> >>
> >> - for (i = 0; i < chip->ecc.steps; i++, oob += sas) {
> >> + for (i = 0; i < chip->ecc.steps; i++) {
> >> ecc_chunk = buf + chip->ecc.size * i;
> >> - ret = nand_check_erased_ecc_chunk(ecc_chunk,
> >> - chip->ecc.size,
> >> - oob, sas, NULL, 0,
> >> +
> >> + if (mtd->ooblayout->ecc(mtd, i, &oobecc)) {
> >
> > Please use the mtdcore.c's helpers
> > (mtd_ooblayout_set/get_data/free/ecc/bytes).
> >
> > Also, what are you trying to discriminate with the return code of the
> > function? Shouldn't this function "always" work?
>
> Just making sure it doesn’t return an ERANGE in case chip->ecc.size doesn’t match the sections from mtd->ooblayout->ecc, which shouldn’t happen, so I think we can remove that...
The style we prefer for error checking is:
ret = function();
if (ret)
do someting;
instead of:
if (function())
Anyway, I really don't know if it can happen or not. I suppose it does.
What I don't understand is your "oob = chip->oob_poi + oobecc.offset".
If you expect an error, then you should not update this pointer, right?
Don't you need to use 2 * i instead of i here? Following your other
contribution, sections are distributed like "data/ecc/data/ecc/etc".
>
> >
> >> + oob = NULL;
> >> + oobecc.length = 0;
> >> + } else {
> >> + oob = chip->oob_poi + oobecc.offset;
> >> + }
> >> +
> >> + ret = nand_check_erased_ecc_chunk(ecc_chunk, chip->ecc.size,
> >> + oob, oobecc.length,
> >> + NULL, 0,
> >> chip->ecc.strength);
> >
> > As I told you, this helper takes "maid data" then "spare area" then
> > "ecc bytes". The names are pretty important here as you want to avoid
> > checking the spare OOB bytes on purpose, so maybe you could have more
> > meaningful names and call "ecc" instead of "oob" the ecc region?
>
> Actually I thought you meant the commit log, not the code itself...
No problem ;) I meant both actually, And I think you should name the
oob pointer ecc_bytes.
>
> >
> >> if (ret < 0)
> >> return ret;
> >
> >
> > Thanks,
> > Miquèl
>
> Regards,
> Álvaro.
>
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: vigneshr@ti.com, kdasu.kdev@gmail.com, richard@nod.at,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-mtd@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com,
computersforpeace@gmail.com, linux-media@vger.kernel.org
Subject: Re: [PATCH v3] mtd: rawnand: brcmnand: correctly verify erased pages
Date: Tue, 12 May 2020 09:34:51 +0200 [thread overview]
Message-ID: <20200512093451.4cde5384@xps13> (raw)
In-Reply-To: <50E32C0E-7485-4180-A072-F7F1CFB45B06@gmail.com>
Hi Álvaro,
Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
09:24:32 +0200:
> Hi Miquèl
>
> > El 12 may 2020, a las 9:16, Miquel Raynal <miquel.raynal@bootlin.com> escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
> > 08:51:11 +0200:
> >
> >> The current code checks that the whole OOB area is erased.
> >> This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
> >> fail due to the usable OOB bytes not being 0xff.
> >> Correct this by only checking that data and ECC bytes aren't 0xff.
> >>
> >> Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
> >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> >> ---
> >> v3: Fix commit log and merge nand_check_erased_ecc_chunk calls.
> >> v2: Add Fixes tag
> >>
> >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 19 ++++++++++++++-----
> >> 1 file changed, 14 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> index e4e3ceeac38f..80fe01f03516 100644
> >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> @@ -2018,8 +2018,9 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
> >> static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> struct nand_chip *chip, void *buf, u64 addr)
> >> {
> >> + struct mtd_oob_region oobecc;
> >> int i, sas;
> >> - void *oob = chip->oob_poi;
> >> + void *oob;
> >> int bitflips = 0;
> >> int page = addr >> chip->page_shift;
> >> int ret;
> >> @@ -2035,11 +2036,19 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> if (ret)
> >> return ret;
> >>
> >> - for (i = 0; i < chip->ecc.steps; i++, oob += sas) {
> >> + for (i = 0; i < chip->ecc.steps; i++) {
> >> ecc_chunk = buf + chip->ecc.size * i;
> >> - ret = nand_check_erased_ecc_chunk(ecc_chunk,
> >> - chip->ecc.size,
> >> - oob, sas, NULL, 0,
> >> +
> >> + if (mtd->ooblayout->ecc(mtd, i, &oobecc)) {
> >
> > Please use the mtdcore.c's helpers
> > (mtd_ooblayout_set/get_data/free/ecc/bytes).
> >
> > Also, what are you trying to discriminate with the return code of the
> > function? Shouldn't this function "always" work?
>
> Just making sure it doesn’t return an ERANGE in case chip->ecc.size doesn’t match the sections from mtd->ooblayout->ecc, which shouldn’t happen, so I think we can remove that...
The style we prefer for error checking is:
ret = function();
if (ret)
do someting;
instead of:
if (function())
Anyway, I really don't know if it can happen or not. I suppose it does.
What I don't understand is your "oob = chip->oob_poi + oobecc.offset".
If you expect an error, then you should not update this pointer, right?
Don't you need to use 2 * i instead of i here? Following your other
contribution, sections are distributed like "data/ecc/data/ecc/etc".
>
> >
> >> + oob = NULL;
> >> + oobecc.length = 0;
> >> + } else {
> >> + oob = chip->oob_poi + oobecc.offset;
> >> + }
> >> +
> >> + ret = nand_check_erased_ecc_chunk(ecc_chunk, chip->ecc.size,
> >> + oob, oobecc.length,
> >> + NULL, 0,
> >> chip->ecc.strength);
> >
> > As I told you, this helper takes "maid data" then "spare area" then
> > "ecc bytes". The names are pretty important here as you want to avoid
> > checking the spare OOB bytes on purpose, so maybe you could have more
> > meaningful names and call "ecc" instead of "oob" the ecc region?
>
> Actually I thought you meant the commit log, not the code itself...
No problem ;) I meant both actually, And I think you should name the
oob pointer ecc_bytes.
>
> >
> >> if (ret < 0)
> >> return ret;
> >
> >
> > Thanks,
> > Miquèl
>
> Regards,
> Álvaro.
>
Thanks,
Miquèl
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: computersforpeace@gmail.com, kdasu.kdev@gmail.com,
richard@nod.at, vigneshr@ti.com, sumit.semwal@linaro.org,
linux-mtd@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v3] mtd: rawnand: brcmnand: correctly verify erased pages
Date: Tue, 12 May 2020 09:34:51 +0200 [thread overview]
Message-ID: <20200512093451.4cde5384@xps13> (raw)
In-Reply-To: <50E32C0E-7485-4180-A072-F7F1CFB45B06@gmail.com>
Hi Álvaro,
Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
09:24:32 +0200:
> Hi Miquèl
>
> > El 12 may 2020, a las 9:16, Miquel Raynal <miquel.raynal@bootlin.com> escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas <noltari@gmail.com> wrote on Tue, 12 May 2020
> > 08:51:11 +0200:
> >
> >> The current code checks that the whole OOB area is erased.
> >> This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
> >> fail due to the usable OOB bytes not being 0xff.
> >> Correct this by only checking that data and ECC bytes aren't 0xff.
> >>
> >> Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
> >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> >> ---
> >> v3: Fix commit log and merge nand_check_erased_ecc_chunk calls.
> >> v2: Add Fixes tag
> >>
> >> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 19 ++++++++++++++-----
> >> 1 file changed, 14 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> index e4e3ceeac38f..80fe01f03516 100644
> >> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >> @@ -2018,8 +2018,9 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
> >> static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> struct nand_chip *chip, void *buf, u64 addr)
> >> {
> >> + struct mtd_oob_region oobecc;
> >> int i, sas;
> >> - void *oob = chip->oob_poi;
> >> + void *oob;
> >> int bitflips = 0;
> >> int page = addr >> chip->page_shift;
> >> int ret;
> >> @@ -2035,11 +2036,19 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> >> if (ret)
> >> return ret;
> >>
> >> - for (i = 0; i < chip->ecc.steps; i++, oob += sas) {
> >> + for (i = 0; i < chip->ecc.steps; i++) {
> >> ecc_chunk = buf + chip->ecc.size * i;
> >> - ret = nand_check_erased_ecc_chunk(ecc_chunk,
> >> - chip->ecc.size,
> >> - oob, sas, NULL, 0,
> >> +
> >> + if (mtd->ooblayout->ecc(mtd, i, &oobecc)) {
> >
> > Please use the mtdcore.c's helpers
> > (mtd_ooblayout_set/get_data/free/ecc/bytes).
> >
> > Also, what are you trying to discriminate with the return code of the
> > function? Shouldn't this function "always" work?
>
> Just making sure it doesn’t return an ERANGE in case chip->ecc.size doesn’t match the sections from mtd->ooblayout->ecc, which shouldn’t happen, so I think we can remove that...
The style we prefer for error checking is:
ret = function();
if (ret)
do someting;
instead of:
if (function())
Anyway, I really don't know if it can happen or not. I suppose it does.
What I don't understand is your "oob = chip->oob_poi + oobecc.offset".
If you expect an error, then you should not update this pointer, right?
Don't you need to use 2 * i instead of i here? Following your other
contribution, sections are distributed like "data/ecc/data/ecc/etc".
>
> >
> >> + oob = NULL;
> >> + oobecc.length = 0;
> >> + } else {
> >> + oob = chip->oob_poi + oobecc.offset;
> >> + }
> >> +
> >> + ret = nand_check_erased_ecc_chunk(ecc_chunk, chip->ecc.size,
> >> + oob, oobecc.length,
> >> + NULL, 0,
> >> chip->ecc.strength);
> >
> > As I told you, this helper takes "maid data" then "spare area" then
> > "ecc bytes". The names are pretty important here as you want to avoid
> > checking the spare OOB bytes on purpose, so maybe you could have more
> > meaningful names and call "ecc" instead of "oob" the ecc region?
>
> Actually I thought you meant the commit log, not the code itself...
No problem ;) I meant both actually, And I think you should name the
oob pointer ecc_bytes.
>
> >
> >> if (ret < 0)
> >> return ret;
> >
> >
> > Thanks,
> > Miquèl
>
> Regards,
> Álvaro.
>
Thanks,
Miquèl
next prev parent reply other threads:[~2020-05-12 7:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 9:29 [PATCH] nand: brcmnand: correctly verify erased pages Álvaro Fernández Rojas
2020-05-04 9:29 ` Álvaro Fernández Rojas
2020-05-04 9:29 ` Álvaro Fernández Rojas
2020-05-04 21:43 ` Florian Fainelli
2020-05-04 21:43 ` Florian Fainelli
2020-05-04 21:43 ` Florian Fainelli
2020-05-05 8:24 ` Álvaro Fernández Rojas
2020-05-05 8:20 ` [PATCH v2] " Álvaro Fernández Rojas
2020-05-05 8:20 ` Álvaro Fernández Rojas
2020-05-05 8:20 ` Álvaro Fernández Rojas
2020-05-11 16:43 ` Miquel Raynal
2020-05-11 16:43 ` Miquel Raynal
2020-05-12 6:51 ` [PATCH v3] mtd: rawnand: " Álvaro Fernández Rojas
2020-05-12 6:51 ` Álvaro Fernández Rojas
2020-05-12 6:51 ` Álvaro Fernández Rojas
2020-05-12 7:16 ` Miquel Raynal
2020-05-12 7:16 ` Miquel Raynal
2020-05-12 7:16 ` Miquel Raynal
2020-05-12 7:24 ` Álvaro Fernández Rojas
2020-05-12 7:24 ` Álvaro Fernández Rojas
2020-05-12 7:24 ` Álvaro Fernández Rojas
2020-05-12 7:34 ` Miquel Raynal [this message]
2020-05-12 7:34 ` Miquel Raynal
2020-05-12 7:34 ` Miquel Raynal
2020-05-12 8:24 ` Álvaro Fernández Rojas
2020-05-12 8:24 ` Álvaro Fernández Rojas
2020-05-12 8:24 ` Álvaro Fernández Rojas
2020-05-12 8:24 ` [PATCH v4] " Álvaro Fernández Rojas
2020-05-12 8:24 ` Álvaro Fernández Rojas
2020-05-12 8:24 ` Álvaro Fernández Rojas
2020-05-24 19:16 ` Miquel Raynal
2020-05-24 19:16 ` Miquel Raynal
2020-05-24 19:16 ` Miquel Raynal
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=20200512093451.4cde5384@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kdasu.kdev@gmail.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=noltari@gmail.com \
--cc=richard@nod.at \
--cc=sumit.semwal@linaro.org \
--cc=vigneshr@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.