* [PATCH v2 0/2] Fix OMAP2 ECC/OOB layout logic @ 2021-01-20 10:17 Miquel Raynal 2021-01-20 10:17 ` [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps Miquel Raynal 2021-01-20 10:17 ` [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures Miquel Raynal 0 siblings, 2 replies; 5+ messages in thread From: Miquel Raynal @ 2021-01-20 10:17 UTC (permalink / raw) To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd Cc: Boris Brezillon, Adam Ford, ladis, Miquel Raynal Hello, I already sent a v1 for this fix but the problem I had was that it was using the software BCH ECC engine internal structure and this was kind of breaking the layering. I attempted to export more variables which could be useful to the users, avoiding the need to dereference private structures, but then I realized we already had everything in hand. Patch 1 is new and simply adds a helper that will be used by patch 2 for readability. I plan to send both patches through the next fixes PR. Cheers, Miquèl Miquel Raynal (2): mtd: nand: Add a helper to retrieve the number of ECC steps mtd: rawnand: omap: Use ECC information from the generic structures drivers/mtd/nand/raw/omap2.c | 16 ++++++++++------ include/linux/mtd/nand.h | 12 ++++++++++++ 2 files changed, 22 insertions(+), 6 deletions(-) -- 2.20.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps 2021-01-20 10:17 [PATCH v2 0/2] Fix OMAP2 ECC/OOB layout logic Miquel Raynal @ 2021-01-20 10:17 ` Miquel Raynal 2021-01-20 10:30 ` Boris Brezillon 2021-01-20 10:17 ` [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures Miquel Raynal 1 sibling, 1 reply; 5+ messages in thread From: Miquel Raynal @ 2021-01-20 10:17 UTC (permalink / raw) To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd Cc: Boris Brezillon, Adam Ford, ladis, Miquel Raynal This operation is very common and deserves a helper. It of course only works after the ECC engine initialization. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- include/linux/mtd/nand.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 414f8a4d2853..27e87c02971c 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -585,6 +585,18 @@ nanddev_get_ecc_conf(struct nand_device *nand) return &nand->ecc.ctx.conf; } +/** + * nanddev_get_ecc_nsteps() - Extract the actual number of ECC steps + * @nand: NAND device + */ +static inline unsigned int +nanddev_get_ecc_nsteps(struct nand_device *nand) +{ + const struct nand_ecc_props *conf = nanddev_get_ecc_conf(nand); + + return nanddev_page_size(nand) / conf->step_size; +} + /** * nanddev_get_ecc_requirements() - Extract the ECC requirements from a NAND * device -- 2.20.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps 2021-01-20 10:17 ` [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps Miquel Raynal @ 2021-01-20 10:30 ` Boris Brezillon 0 siblings, 0 replies; 5+ messages in thread From: Boris Brezillon @ 2021-01-20 10:30 UTC (permalink / raw) To: Miquel Raynal Cc: Vignesh Raghavendra, Tudor Ambarus, Richard Weinberger, ladis, linux-mtd, Adam Ford On Wed, 20 Jan 2021 11:17:49 +0100 Miquel Raynal <miquel.raynal@bootlin.com> wrote: > This operation is very common and deserves a helper. It of course only > works after the ECC engine initialization. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > --- > include/linux/mtd/nand.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h > index 414f8a4d2853..27e87c02971c 100644 > --- a/include/linux/mtd/nand.h > +++ b/include/linux/mtd/nand.h > @@ -585,6 +585,18 @@ nanddev_get_ecc_conf(struct nand_device *nand) > return &nand->ecc.ctx.conf; > } > > +/** > + * nanddev_get_ecc_nsteps() - Extract the actual number of ECC steps > + * @nand: NAND device > + */ > +static inline unsigned int > +nanddev_get_ecc_nsteps(struct nand_device *nand) > +{ > + const struct nand_ecc_props *conf = nanddev_get_ecc_conf(nand); > + > + return nanddev_page_size(nand) / conf->step_size; Some ECC engines might cover OOB bytes too, so you can't really guess the number of steps with a simple page_size / step_size division. I think it's safer to store the number of steps and step_size directly in the conf and let the engine fill those. > +} > + > /** > * nanddev_get_ecc_requirements() - Extract the ECC requirements from a NAND > * device ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures 2021-01-20 10:17 [PATCH v2 0/2] Fix OMAP2 ECC/OOB layout logic Miquel Raynal 2021-01-20 10:17 ` [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps Miquel Raynal @ 2021-01-20 10:17 ` Miquel Raynal 2021-01-20 10:36 ` Boris Brezillon 1 sibling, 1 reply; 5+ messages in thread From: Miquel Raynal @ 2021-01-20 10:17 UTC (permalink / raw) To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd Cc: Boris Brezillon, Adam Ford, ladis, Miquel Raynal The OMAP driver may leverage software BCH logic to locate errors while using its own hardware to detect the presence of errors. This is achieved with a "mixed" mode which initializes manually the software BCH internal logic while providing its own OOB layout. The issue here comes from the fact that the BCH driver has been updated to only use generic NAND objects, and no longer depend on raw NAND structures as it is usable from SPI-NAND as well. However, at the end of the BCH context initialization, the driver checks the validity of the OOB layout. At this stage, the raw NAND fields have not been populated yet while being used by the layout helpers, leading to an invalid layout. The solution here is to use the fields from the generic ECC structures which have already been updated and will always be valid instead of the raw NAND ones. Note: I don't know which commit exactly triggered the error, but the entire migration to a generic BCH driver got merged in one go, so this should not be a problem for stable backports. Reported-by: Adam Ford <aford173@gmail.com> Fixes: 80fe603160a4 ("mtd: nand: ecc-bch: Stop using raw NAND structures") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- drivers/mtd/nand/raw/omap2.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c index fbb9955f2467..fd09b2a30abb 100644 --- a/drivers/mtd/nand/raw/omap2.c +++ b/drivers/mtd/nand/raw/omap2.c @@ -1866,18 +1866,20 @@ static const struct mtd_ooblayout_ops omap_ooblayout_ops = { static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section, struct mtd_oob_region *oobregion) { - struct nand_chip *chip = mtd_to_nand(mtd); + struct nand_device *nand = mtd_to_nanddev(mtd); + unsigned int nsteps = nanddev_get_ecc_nsteps(nand); + unsigned int ecc_bytes = nand->ecc.ctx.total / nsteps; int off = BADBLOCK_MARKER_LENGTH; - if (section >= chip->ecc.steps) + if (section >= nsteps) return -ERANGE; /* * When SW correction is employed, one OMAP specific marker byte is * reserved after each ECC step. */ - oobregion->offset = off + (section * (chip->ecc.bytes + 1)); - oobregion->length = chip->ecc.bytes; + oobregion->offset = off + (section * (ecc_bytes + 1)); + oobregion->length = ecc_bytes; return 0; } @@ -1885,7 +1887,9 @@ static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section, static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section, struct mtd_oob_region *oobregion) { - struct nand_chip *chip = mtd_to_nand(mtd); + struct nand_device *nand = mtd_to_nanddev(mtd); + unsigned int nsteps = nanddev_get_ecc_nsteps(nand); + unsigned int ecc_bytes = nand->ecc.ctx.total / nsteps; int off = BADBLOCK_MARKER_LENGTH; if (section) @@ -1895,7 +1899,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section, * When SW correction is employed, one OMAP specific marker byte is * reserved after each ECC step. */ - off += ((chip->ecc.bytes + 1) * chip->ecc.steps); + off += ((ecc_bytes + 1) * nsteps); if (off >= mtd->oobsize) return -ERANGE; -- 2.20.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures 2021-01-20 10:17 ` [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures Miquel Raynal @ 2021-01-20 10:36 ` Boris Brezillon 0 siblings, 0 replies; 5+ messages in thread From: Boris Brezillon @ 2021-01-20 10:36 UTC (permalink / raw) To: Miquel Raynal Cc: Vignesh Raghavendra, Tudor Ambarus, Richard Weinberger, ladis, linux-mtd, Adam Ford On Wed, 20 Jan 2021 11:17:50 +0100 Miquel Raynal <miquel.raynal@bootlin.com> wrote: > The OMAP driver may leverage software BCH logic to locate errors while > using its own hardware to detect the presence of errors. This is > achieved with a "mixed" mode which initializes manually the software > BCH internal logic while providing its own OOB layout. > > The issue here comes from the fact that the BCH driver has been > updated to only use generic NAND objects, and no longer depend on raw > NAND structures as it is usable from SPI-NAND as well. However, at the > end of the BCH context initialization, the driver checks the validity > of the OOB layout. At this stage, the raw NAND fields have not been > populated yet while being used by the layout helpers, leading to an > invalid layout. > > The solution here is to use the fields from the generic ECC structures > which have already been updated and will always be valid instead of > the raw NAND ones. > > Note: I don't know which commit exactly triggered the error, but the > entire migration to a generic BCH driver got merged in one go, so this > should not be a problem for stable backports. > > Reported-by: Adam Ford <aford173@gmail.com> > Fixes: 80fe603160a4 ("mtd: nand: ecc-bch: Stop using raw NAND structures") > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > --- > drivers/mtd/nand/raw/omap2.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c > index fbb9955f2467..fd09b2a30abb 100644 > --- a/drivers/mtd/nand/raw/omap2.c > +++ b/drivers/mtd/nand/raw/omap2.c > @@ -1866,18 +1866,20 @@ static const struct mtd_ooblayout_ops omap_ooblayout_ops = { > static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section, > struct mtd_oob_region *oobregion) > { > - struct nand_chip *chip = mtd_to_nand(mtd); > + struct nand_device *nand = mtd_to_nanddev(mtd); > + unsigned int nsteps = nanddev_get_ecc_nsteps(nand); > + unsigned int ecc_bytes = nand->ecc.ctx.total / nsteps; I'd recommend adding a helper for that one too (nanddev_ecc_bytes_per_step()?). This being said, I think you're better off applying v1 (which is self-contained) and keeping this refactor for the next release. > int off = BADBLOCK_MARKER_LENGTH; > > - if (section >= chip->ecc.steps) > + if (section >= nsteps) > return -ERANGE; > > /* > * When SW correction is employed, one OMAP specific marker byte is > * reserved after each ECC step. > */ > - oobregion->offset = off + (section * (chip->ecc.bytes + 1)); > - oobregion->length = chip->ecc.bytes; > + oobregion->offset = off + (section * (ecc_bytes + 1)); > + oobregion->length = ecc_bytes; > > return 0; > } > @@ -1885,7 +1887,9 @@ static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section, > static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section, > struct mtd_oob_region *oobregion) > { > - struct nand_chip *chip = mtd_to_nand(mtd); > + struct nand_device *nand = mtd_to_nanddev(mtd); > + unsigned int nsteps = nanddev_get_ecc_nsteps(nand); > + unsigned int ecc_bytes = nand->ecc.ctx.total / nsteps; > int off = BADBLOCK_MARKER_LENGTH; > > if (section) > @@ -1895,7 +1899,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section, > * When SW correction is employed, one OMAP specific marker byte is > * reserved after each ECC step. > */ > - off += ((chip->ecc.bytes + 1) * chip->ecc.steps); > + off += ((ecc_bytes + 1) * nsteps); > if (off >= mtd->oobsize) > return -ERANGE; > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-20 10:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-01-20 10:17 [PATCH v2 0/2] Fix OMAP2 ECC/OOB layout logic Miquel Raynal 2021-01-20 10:17 ` [PATCH v2 1/2] mtd: nand: Add a helper to retrieve the number of ECC steps Miquel Raynal 2021-01-20 10:30 ` Boris Brezillon 2021-01-20 10:17 ` [PATCH v2 2/2] mtd: rawnand: omap: Use ECC information from the generic structures Miquel Raynal 2021-01-20 10:36 ` Boris Brezillon
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).