* [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-09-30 7:53 ` Thomas Petazzoni
2020-10-30 17:30 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 02/20] mtd: nand: ecc-bch: Move BCH code to the generic NAND layer Miquel Raynal
` (18 subsequent siblings)
19 siblings, 2 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Currently, BCH and Hamming engine are sharing the same
tweaking/restoring I/O mechanism: they need the I/O request to fully
cover the main/OOB area. Let's make this code generic as sharing the
code between two drivers is already a win. Maybe other ECC engine
drivers will need it too.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 106 +++++++++++++++++++++++++++++++++++++++
include/linux/mtd/nand.h | 32 ++++++++++++
2 files changed, 138 insertions(+)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 4a56e6c0da67..86bbc4ecc58a 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -95,6 +95,7 @@
#include <linux/module.h>
#include <linux/mtd/nand.h>
+#include <linux/slab.h>
/**
* nand_ecc_init_ctx - Init the ECC engine context
@@ -479,6 +480,111 @@ bool nand_ecc_is_strong_enough(struct nand_device *nand)
}
EXPORT_SYMBOL(nand_ecc_is_strong_enough);
+/* ECC engine driver internal helpers */
+int nand_ecc_init_req_tweaking(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_device *nand)
+{
+ unsigned int total_buffer_size;
+
+ ctx->nand = nand;
+
+ /* Let the user decide the exact length of each buffer */
+ if (!ctx->page_buffer_size)
+ ctx->page_buffer_size = nanddev_page_size(nand);
+ if (!ctx->oob_buffer_size)
+ ctx->oob_buffer_size = nanddev_per_page_oobsize(nand);
+
+ total_buffer_size = ctx->page_buffer_size + ctx->oob_buffer_size;
+
+ ctx->spare_databuf = kzalloc(total_buffer_size, GFP_KERNEL);
+ if (!ctx->spare_databuf)
+ return -ENOMEM;
+
+ ctx->spare_oobbuf = ctx->spare_databuf + ctx->page_buffer_size;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nand_ecc_init_req_tweaking);
+
+void nand_ecc_cleanup_req_tweaking(struct nand_ecc_req_tweak_ctx *ctx)
+{
+ kfree(ctx->spare_databuf);
+}
+EXPORT_SYMBOL_GPL(nand_ecc_cleanup_req_tweaking);
+
+/*
+ * Ensure data and OOB area is fully read/written otherwise the correction might
+ * not work as expected.
+ */
+void nand_ecc_tweak_req(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_page_io_req *req)
+{
+ struct nand_device *nand = ctx->nand;
+ struct nand_page_io_req *orig, *tweak;
+
+ /* Save the original request */
+ ctx->orig_req = *req;
+ ctx->bounce_data = false;
+ ctx->bounce_oob = false;
+ orig = &ctx->orig_req;
+ tweak = req;
+
+ /* Ensure the request covers the entire page */
+ if (true) {//todo (orig->datalen < nanddev_page_size(nand)) {
+ ctx->bounce_data = true;
+ tweak->dataoffs = 0;
+ tweak->datalen = nanddev_page_size(nand);
+ tweak->databuf.in = ctx->spare_databuf;
+ memset(tweak->databuf.in, 0xFF, ctx->page_buffer_size);
+ }
+
+ if (true) {//todo (orig->ooblen < nanddev_per_page_oobsize(nand)) {
+ ctx->bounce_oob = true;
+ tweak->ooboffs = 0;
+ tweak->ooblen = nanddev_per_page_oobsize(nand);
+ tweak->oobbuf.in = ctx->spare_oobbuf;
+ memset(tweak->oobbuf.in, 0xFF, ctx->oob_buffer_size);
+ }
+
+ /* Copy the data that must be writen in the bounce buffers, if needed */
+ if (orig->type == NAND_PAGE_WRITE) {
+ if (ctx->bounce_data)
+ memcpy((void *)tweak->databuf.out + orig->dataoffs,
+ orig->databuf.out, orig->datalen);
+
+ if (ctx->bounce_oob)
+ memcpy((void *)tweak->oobbuf.out + orig->ooboffs,
+ orig->oobbuf.out, orig->ooblen);
+ }
+}
+EXPORT_SYMBOL_GPL(nand_ecc_tweak_req);
+
+void nand_ecc_restore_req(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_page_io_req *req)
+{
+ struct nand_page_io_req *orig, *tweak;
+
+ orig = &ctx->orig_req;
+ tweak = req;
+
+ /* Restore the data read from the bounce buffers, if needed */
+ if (orig->type == NAND_PAGE_READ) {
+ if (ctx->bounce_data)
+ memcpy(orig->databuf.in,
+ tweak->databuf.in + orig->dataoffs,
+ orig->datalen);
+
+ if (ctx->bounce_oob)
+ memcpy(orig->oobbuf.in,
+ tweak->oobbuf.in + orig->ooboffs,
+ orig->ooblen);
+ }
+
+ /* Ensure the original request is restored */
+ *req = *orig;
+}
+EXPORT_SYMBOL_GPL(nand_ecc_restore_req);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 697ea2474a7c..36e4fe08d0ea 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -278,6 +278,38 @@ int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
bool nand_ecc_is_strong_enough(struct nand_device *nand);
+/**
+ * struct nand_ecc_req_tweak_ctx - Help for automatically tweaking requests
+ * @orig_req: Pointer to the original IO request
+ * @nand: Related NAND device, to have access to its memory organization
+ * @page_buffer_size: Real size of the page buffer to use (can be set by the
+ * user before the tweaking mechanism initialization)
+ * @oob_buffer_size: Real size of the OOB buffer to use (can be set by the
+ * user before the tweaking mechanism initialization)
+ * @spare_databuf: Data bounce buffer
+ * @spare_oobbuf: OOB bounce buffer
+ * @bounce_data: Flag indicating a data bounce buffer is used
+ * @bounce_oob: Flag indicating an OOB bounce buffer is used
+ */
+struct nand_ecc_req_tweak_ctx {
+ struct nand_page_io_req orig_req;
+ struct nand_device *nand;
+ unsigned int page_buffer_size;
+ unsigned int oob_buffer_size;
+ void *spare_databuf;
+ void *spare_oobbuf;
+ bool bounce_data;
+ bool bounce_oob;
+};
+
+int nand_ecc_init_req_tweaking(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_device *nand);
+void nand_ecc_cleanup_req_tweaking(struct nand_ecc_req_tweak_ctx *ctx);
+void nand_ecc_tweak_req(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_page_io_req *req);
+void nand_ecc_restore_req(struct nand_ecc_req_tweak_ctx *ctx,
+ struct nand_page_io_req *req);
+
/**
* struct nand_ecc - Information relative to the ECC
* @defaults: Default values, depend on the underlying subsystem
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism
2020-09-29 23:01 ` [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism Miquel Raynal
@ 2020-09-30 7:53 ` Thomas Petazzoni
2020-09-30 8:16 ` Miquel Raynal
2020-10-30 17:30 ` Miquel Raynal
1 sibling, 1 reply; 69+ messages in thread
From: Thomas Petazzoni @ 2020-09-30 7:53 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd
Hello,
On Wed, 30 Sep 2020 01:01:05 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> + /* Ensure the request covers the entire page */
> + if (true) {//todo (orig->datalen < nanddev_page_size(nand)) {
This TODO and "if (true)" looks odd.
> + ctx->bounce_data = true;
> + tweak->dataoffs = 0;
> + tweak->datalen = nanddev_page_size(nand);
> + tweak->databuf.in = ctx->spare_databuf;
> + memset(tweak->databuf.in, 0xFF, ctx->page_buffer_size);
> + }
> +
> + if (true) {//todo (orig->ooblen < nanddev_per_page_oobsize(nand)) {
Ditto.
Also, I find the wording "tweak" a bit vague, "tweak" really means
nothing specific. What about prepare/unprepare instead of tweak/restore ?
Also, shouldn't nand_ecc_init_req_tweaking() also allocate the struct
nand_ecc_req_tweak_ctx so that this structure remains internal ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism
2020-09-30 7:53 ` Thomas Petazzoni
@ 2020-09-30 8:16 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-09-30 8:16 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote on Wed, 30 Sep
2020 09:53:08 +0200:
> Hello,
>
> On Wed, 30 Sep 2020 01:01:05 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > + /* Ensure the request covers the entire page */
> > + if (true) {//todo (orig->datalen < nanddev_page_size(nand)) {
>
> This TODO and "if (true)" looks odd.
Oops, this is a debugging leftover; I don't remember getting a
checkpatch error for that. Surely it did though.
>
> > + ctx->bounce_data = true;
> > + tweak->dataoffs = 0;
> > + tweak->datalen = nanddev_page_size(nand);
> > + tweak->databuf.in = ctx->spare_databuf;
> > + memset(tweak->databuf.in, 0xFF, ctx->page_buffer_size);
> > + }
> > +
> > + if (true) {//todo (orig->ooblen < nanddev_per_page_oobsize(nand)) {
>
> Ditto.
>
> Also, I find the wording "tweak" a bit vague, "tweak" really means
> nothing specific. What about prepare/unprepare instead of tweak/restore ?
I understand that "tweaking" might be a bit too vague, but
we already have a ->prepare_io_req() hook, from which we call
nand_ecc_tweark_req(). So this really is a helper that is being called
to hide the real user request (maybe a few bytes), in favor of a
'bigger' one (full page).
What about nand_ecc_extend/restore_req()? Other ideas welcome!
>
> Also, shouldn't nand_ecc_init_req_tweaking() also allocate the struct
> nand_ecc_req_tweak_ctx so that this structure remains internal ?
This mechanism is part of the ECC engine logic, so if the structure is
allocated by nand_ecc_init_req_tweaking(), it means that the function
must return a pointer to the allocated structure, which should be saved
by the ECC engine driver. Instead, I decided to declare the "request
tweaking context" within the ECC engine configuration (which makes
sense IMHO). This is more or less the same, it just prevents an
extra (useless?) allocation. I guess both would work pretty much the
same.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism
2020-09-29 23:01 ` [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism Miquel Raynal
2020-09-30 7:53 ` Thomas Petazzoni
@ 2020-10-30 17:30 ` Miquel Raynal
1 sibling, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:30 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:05 UTC, Miquel Raynal wrote:
> Currently, BCH and Hamming engine are sharing the same
> tweaking/restoring I/O mechanism: they need the I/O request to fully
> cover the main/OOB area. Let's make this code generic as sharing the
> code between two drivers is already a win. Maybe other ECC engine
> drivers will need it too.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 02/20] mtd: nand: ecc-bch: Move BCH code to the generic NAND layer
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
2020-09-29 23:01 ` [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:30 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 03/20] mtd: nand: ecc-bch: Cleanup and style fixes Miquel Raynal
` (17 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
BCH ECC code might be later re-used by the SPI NAND layer.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/Kconfig | 11 +++++++++++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/{raw/nand_bch.c => ecc-sw-bch.c} | 2 +-
drivers/mtd/nand/raw/Kconfig | 10 ----------
drivers/mtd/nand/raw/Makefile | 1 -
drivers/mtd/nand/raw/nand_base.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 2 +-
drivers/mtd/nand/raw/omap2.c | 2 +-
include/linux/mtd/{nand_bch.h => nand-ecc-sw-bch.h} | 6 +++---
9 files changed, 19 insertions(+), 18 deletions(-)
rename drivers/mtd/nand/{raw/nand_bch.c => ecc-sw-bch.c} (99%)
rename include/linux/mtd/{nand_bch.h => nand-ecc-sw-bch.h} (92%)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4a9aed4f0104..55c17fb0dee1 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -15,6 +15,17 @@ config MTD_NAND_ECC
bool
depends on MTD_NAND_CORE
+config MTD_NAND_ECC_SW_BCH
+ bool "Software BCH ECC engine"
+ select BCH
+ select MTD_NAND_ECC
+ default n
+ help
+ This enables support for software BCH error correction. Binary BCH
+ codes are more powerful and cpu intensive than traditional Hamming
+ ECC codes. They are used with NAND devices requiring more than 1 bit
+ of error correction.
+
endmenu
endmenu
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 981372953b56..c7179ff23753 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -8,3 +8,4 @@ obj-y += raw/
obj-y += spi/
nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
+nandcore-$(CONFIG_MTD_NAND_ECC_SW_BCH) += ecc-sw-bch.o
diff --git a/drivers/mtd/nand/raw/nand_bch.c b/drivers/mtd/nand/ecc-sw-bch.c
similarity index 99%
rename from drivers/mtd/nand/raw/nand_bch.c
rename to drivers/mtd/nand/ecc-sw-bch.c
index d5af8c5fd02f..d0dc84cfdbdc 100644
--- a/drivers/mtd/nand/raw/nand_bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -13,7 +13,7 @@
#include <linux/bitops.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_bch.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/bch.h>
/**
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 6c46f25b57e2..b73860aa77c6 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -22,16 +22,6 @@ menuconfig MTD_RAW_NAND
if MTD_RAW_NAND
-config MTD_NAND_ECC_SW_BCH
- bool "Support software BCH ECC"
- select BCH
- default n
- help
- This enables support for software BCH error correction. Binary BCH
- codes are more powerful and cpu intensive than traditional Hamming
- ECC codes. They are used with NAND devices requiring more than 1 bit
- of error correction.
-
comment "Raw/parallel NAND flash controllers"
config MTD_NAND_DENALI
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 2930f5b9015d..76904305d091 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -2,7 +2,6 @@
obj-$(CONFIG_MTD_RAW_NAND) += nand.o
obj-$(CONFIG_MTD_NAND_ECC_SW_HAMMING) += nand_ecc.o
-nand-$(CONFIG_MTD_NAND_ECC_SW_BCH) += nand_bch.o
obj-$(CONFIG_MTD_SM_COMMON) += sm_common.o
obj-$(CONFIG_MTD_NAND_CAFE) += cafe_nand.o
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0b8f4e41bc9b..189d3a301a38 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -36,7 +36,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/nand_ecc.h>
-#include <linux/mtd/nand_bch.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/interrupt.h>
#include <linux/bitops.h>
#include <linux/io.h>
diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
index a8048cb8d220..9c940ead66fd 100644
--- a/drivers/mtd/nand/raw/nandsim.c
+++ b/drivers/mtd/nand/raw/nandsim.c
@@ -23,7 +23,7 @@
#include <linux/string.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_bch.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/mtd/partitions.h>
#include <linux/delay.h>
#include <linux/list.h>
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index 512f60780a50..0ef209e1cd87 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -23,7 +23,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/mtd/nand_bch.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/platform_data/elm.h>
#include <linux/omap-gpmc.h>
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
similarity index 92%
rename from include/linux/mtd/nand_bch.h
rename to include/linux/mtd/nand-ecc-sw-bch.h
index d5956cc48ba9..1e1ee3af82b1 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -5,8 +5,8 @@
* This file is the header for the NAND BCH ECC implementation.
*/
-#ifndef __MTD_NAND_BCH_H__
-#define __MTD_NAND_BCH_H__
+#ifndef __MTD_NAND_ECC_SW_BCH_H__
+#define __MTD_NAND_ECC_SW_BCH_H__
struct mtd_info;
struct nand_chip;
@@ -63,4 +63,4 @@ static inline void nand_bch_free(struct nand_bch_control *nbc) {}
#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
-#endif /* __MTD_NAND_BCH_H__ */
+#endif /* __MTD_NAND_ECC_SW_BCH_H__ */
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 03/20] mtd: nand: ecc-bch: Cleanup and style fixes
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
2020-09-29 23:01 ` [PATCH 01/20] mtd: nand: ecc: Add an I/O request tweaking mechanism Miquel Raynal
2020-09-29 23:01 ` [PATCH 02/20] mtd: nand: ecc-bch: Move BCH code to the generic NAND layer Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:30 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure Miquel Raynal
` (16 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Fix function headers, capitals and reword a little bit the comments
to make this driver more readable.
There is not functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-bch.c | 55 ++++++++++++++++++-----------------
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index d0dc84cfdbdc..fe080a0837d8 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -29,10 +29,10 @@ struct nand_bch_control {
};
/**
- * nand_bch_calculate_ecc - [NAND Interface] Calculate ECC for data block
- * @chip: NAND chip object
- * @buf: input buffer with raw data
- * @code: output buffer with ECC
+ * nand_bch_calcuate_ecc - Calculate the ECC corresponding to a data block
+ * @chip: NAND chip object
+ * @buf: Input buffer with raw data
+ * @code: Output buffer with ECC
*/
int nand_bch_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
unsigned char *code)
@@ -52,13 +52,13 @@ int nand_bch_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
EXPORT_SYMBOL(nand_bch_calculate_ecc);
/**
- * nand_bch_correct_data - [NAND Interface] Detect and correct bit error(s)
- * @chip: NAND chip object
- * @buf: raw data read from the chip
- * @read_ecc: ECC from the chip
- * @calc_ecc: the ECC calculated from raw data
+ * nand_bch_correct_data - Detect, correct and report bit error(s)
+ * @chip: NAND chip object
+ * @buf: Raw data read from the chip
+ * @read_ecc: ECC bytes from the chip
+ * @calc_ecc: ECC calculated from the raw data
*
- * Detect and correct bit errors for a data byte block
+ * Detect and correct bit errors for a data block.
*/
int nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc)
@@ -71,37 +71,39 @@ int nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
NULL, errloc);
if (count > 0) {
for (i = 0; i < count; i++) {
- if (errloc[i] < (chip->ecc.size*8))
- /* error is located in data, correct it */
+ if (errloc[i] < (chip->ecc.size * 8))
+ /* The error is in the data area: correct it */
buf[errloc[i] >> 3] ^= (1 << (errloc[i] & 7));
- /* else error in ecc, no action needed */
+ /* Otherwise the error is in the ECC area: nothing to do */
pr_debug("%s: corrected bitflip %u\n", __func__,
- errloc[i]);
+ errloc[i]);
}
} else if (count < 0) {
- pr_err("ecc unrecoverable error\n");
+ pr_err("ECC unrecoverable error\n");
count = -EBADMSG;
}
+
return count;
}
EXPORT_SYMBOL(nand_bch_correct_data);
/**
- * nand_bch_init - [NAND Interface] Initialize NAND BCH error correction
- * @mtd: MTD block structure
+ * nand_bch_init - Initialize software BCH ECC engine
+ * @mtd: MTD device
*
- * Returns:
- * a pointer to a new NAND BCH control structure, or NULL upon failure
+ * Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
*
* Initialize NAND BCH error correction. Parameters @eccsize and @eccbytes
- * are used to compute BCH parameters m (Galois field order) and t (error
- * correction capability). @eccbytes should be equal to the number of bytes
- * required to store m*t bits, where m is such that 2^m-1 > @eccsize*8.
+ * are used to compute the following BCH parameters:
+ * m, the Galois field order
+ * t, the error correction capability
+ * @eccbytes should be equal to the number of bytes required to store m * t
+ * bits, where m is such that 2^m - 1 > step_size * 8.
*
* Example: to configure 4 bit correction per 512 bytes, you should pass
- * @eccsize = 512 (thus, m=13 is the smallest integer such that 2^m-1 > 512*8)
- * @eccbytes = 7 (7 bytes are required to store m*t = 13*4 = 52 bits)
+ * @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
+ * @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
*/
struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
{
@@ -174,6 +176,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
nbc->errloc = kmalloc_array(t, sizeof(*nbc->errloc), GFP_KERNEL);
if (!nbc->eccmask || !nbc->errloc)
goto fail;
+
/*
* compute and store the inverted ecc of an erased ecc block
*/
@@ -199,8 +202,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
EXPORT_SYMBOL(nand_bch_init);
/**
- * nand_bch_free - [NAND Interface] Release NAND BCH ECC resources
- * @nbc: NAND BCH control structure
+ * nand_bch_free - Release NAND BCH ECC resources
+ * @nbc: NAND BCH control structure
*/
void nand_bch_free(struct nand_bch_control *nbc)
{
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 03/20] mtd: nand: ecc-bch: Cleanup and style fixes
2020-09-29 23:01 ` [PATCH 03/20] mtd: nand: ecc-bch: Cleanup and style fixes Miquel Raynal
@ 2020-10-30 17:30 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:30 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:07 UTC, Miquel Raynal wrote:
> Fix function headers, capitals and reword a little bit the comments
> to make this driver more readable.
>
> There is not functional change.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (2 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 03/20] mtd: nand: ecc-bch: Cleanup and style fixes Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2021-01-09 14:46 ` Adam Ford
2020-09-29 23:01 ` [PATCH 05/20] mtd: nand: ecc-bch: Return only valid error codes Miquel Raynal
` (15 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
The NAND BCH control structure has nothing to do outside of this
driver, all users of the nand_bch_init/free() functions just save it
to chip->ecc.priv so do it in this driver directly and return a
regular error code instead.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-bch.c | 36 ++++++++++++++++-------------
drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
drivers/mtd/nand/raw/nand_base.c | 12 ++++++----
drivers/mtd/nand/raw/omap2.c | 16 ++++++-------
include/linux/mtd/nand-ecc-sw-bch.h | 11 ++++-----
5 files changed, 41 insertions(+), 36 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index fe080a0837d8..97221ec3876e 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -90,7 +90,7 @@ EXPORT_SYMBOL(nand_bch_correct_data);
/**
* nand_bch_init - Initialize software BCH ECC engine
- * @mtd: MTD device
+ * @chip: NAND chip object
*
* Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
*
@@ -105,24 +105,24 @@ EXPORT_SYMBOL(nand_bch_correct_data);
* @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
* @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
*/
-struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
+int nand_bch_init(struct nand_chip *chip)
{
- struct nand_chip *nand = mtd_to_nand(mtd);
+ struct mtd_info *mtd = nand_to_mtd(chip);
unsigned int m, t, eccsteps, i;
struct nand_bch_control *nbc = NULL;
unsigned char *erased_page;
- unsigned int eccsize = nand->ecc.size;
- unsigned int eccbytes = nand->ecc.bytes;
- unsigned int eccstrength = nand->ecc.strength;
+ unsigned int eccsize = chip->ecc.size;
+ unsigned int eccbytes = chip->ecc.bytes;
+ unsigned int eccstrength = chip->ecc.strength;
if (!eccbytes && eccstrength) {
eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
- nand->ecc.bytes = eccbytes;
+ chip->ecc.bytes = eccbytes;
}
if (!eccsize || !eccbytes) {
pr_warn("ecc parameters not supplied\n");
- goto fail;
+ return -EINVAL;
}
m = fls(1+8*eccsize);
@@ -130,7 +130,9 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
nbc = kzalloc(sizeof(*nbc), GFP_KERNEL);
if (!nbc)
- goto fail;
+ return -ENOMEM;
+
+ chip->ecc.priv = nbc;
nbc->bch = bch_init(m, t, 0, false);
if (!nbc->bch)
@@ -165,8 +167,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
* FIXME: we should probably rework the sequencing in nand_scan_tail()
* to avoid setting those fields twice.
*/
- nand->ecc.steps = eccsteps;
- nand->ecc.total = eccsteps * eccbytes;
+ chip->ecc.steps = eccsteps;
+ chip->ecc.total = eccsteps * eccbytes;
if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
pr_warn("invalid ecc layout\n");
goto fail;
@@ -192,12 +194,12 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
nbc->eccmask[i] ^= 0xff;
if (!eccstrength)
- nand->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
+ chip->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
- return nbc;
+ return 0;
fail:
- nand_bch_free(nbc);
- return NULL;
+ nand_bch_free(chip);
+ return -EINVAL;
}
EXPORT_SYMBOL(nand_bch_init);
@@ -205,8 +207,10 @@ EXPORT_SYMBOL(nand_bch_init);
* nand_bch_free - Release NAND BCH ECC resources
* @nbc: NAND BCH control structure
*/
-void nand_bch_free(struct nand_bch_control *nbc)
+void nand_bch_free(struct nand_chip *chip)
{
+ struct nand_bch_control *nbc = chip->ecc.priv;
+
if (nbc) {
bch_free(nbc->bch);
kfree(nbc->errloc);
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index 4191831df182..1bc2462efeab 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -927,7 +927,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
/*
* Don't set layout for BCH4 SW ECC. This will be
- * generated later in nand_bch_init() later.
+ * generated later during BCH initialization.
*/
if (nand->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_HOST) {
switch (mtd->oobsize) {
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 189d3a301a38..c47441ddc5cf 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5208,6 +5208,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
struct mtd_info *mtd = nand_to_mtd(chip);
struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
+ int ret;
if (WARN_ON(ecc->engine_type != NAND_ECC_ENGINE_TYPE_SOFT))
return -EINVAL;
@@ -5294,13 +5295,14 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
ecc->strength = bytes * 8 / fls(8 * ecc->size);
}
- /* See nand_bch_init() for details. */
+ /* See the software BCH ECC initialization for details */
ecc->bytes = 0;
- ecc->priv = nand_bch_init(mtd);
- if (!ecc->priv) {
+ ret = nand_bch_init(chip);
+ if (ret) {
WARN(1, "BCH ECC initialization failed!\n");
- return -EINVAL;
+ return ret;
}
+
return 0;
default:
WARN(1, "Unsupported ECC algorithm!\n");
@@ -5960,7 +5962,7 @@ void nand_cleanup(struct nand_chip *chip)
{
if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
chip->ecc.algo == NAND_ECC_ALGO_BCH)
- nand_bch_free((struct nand_bch_control *)chip->ecc.priv);
+ nand_bch_free(chip);
nanddev_cleanup(&chip->base);
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index 0ef209e1cd87..6aab57336690 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -2047,10 +2047,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
/* Reserve one byte for the OMAP marker */
oobbytes_per_step = chip->ecc.bytes + 1;
/* Software BCH library is used for locating errors */
- chip->ecc.priv = nand_bch_init(mtd);
- if (!chip->ecc.priv) {
+ err = nand_bch_init(chip);
+ if (err) {
dev_err(dev, "Unable to use BCH library\n");
- return -EINVAL;
+ return err;
}
break;
@@ -2089,10 +2089,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
/* Reserve one byte for the OMAP marker */
oobbytes_per_step = chip->ecc.bytes + 1;
/* Software BCH library is used for locating errors */
- chip->ecc.priv = nand_bch_init(mtd);
- if (!chip->ecc.priv) {
+ err = nand_bch_init(chip);
+ if (err) {
dev_err(dev, "unable to use BCH library\n");
- return -EINVAL;
+ return err;
}
break;
@@ -2272,7 +2272,7 @@ static int omap_nand_probe(struct platform_device *pdev)
if (!IS_ERR_OR_NULL(info->dma))
dma_release_channel(info->dma);
if (nand_chip->ecc.priv) {
- nand_bch_free(nand_chip->ecc.priv);
+ nand_bch_free(nand_chip);
nand_chip->ecc.priv = NULL;
}
return err;
@@ -2286,7 +2286,7 @@ static int omap_nand_remove(struct platform_device *pdev)
int ret;
if (nand_chip->ecc.priv) {
- nand_bch_free(nand_chip->ecc.priv);
+ nand_bch_free(nand_chip);
nand_chip->ecc.priv = NULL;
}
if (info->dma)
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index 1e1ee3af82b1..b62b8bd4669f 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -10,7 +10,6 @@
struct mtd_info;
struct nand_chip;
-struct nand_bch_control;
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
@@ -30,11 +29,11 @@ int nand_bch_correct_data(struct nand_chip *chip, u_char *dat,
/*
* Initialize BCH encoder/decoder
*/
-struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
+int nand_bch_init(struct nand_chip *chip);
/*
* Release BCH encoder/decoder resources
*/
-void nand_bch_free(struct nand_bch_control *nbc);
+void nand_bch_free(struct nand_chip *chip);
#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
@@ -54,12 +53,12 @@ nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
return -ENOTSUPP;
}
-static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
+static inline int nand_bch_init(struct nand_chip *chip)
{
- return NULL;
+ return -ENOTSUPP;
}
-static inline void nand_bch_free(struct nand_bch_control *nbc) {}
+static inline void nand_bch_free(struct nand_chip *chip) {}
#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2020-09-29 23:01 ` [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure Miquel Raynal
@ 2021-01-09 14:46 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-09 14:46 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> The NAND BCH control structure has nothing to do outside of this
> driver, all users of the nand_bch_init/free() functions just save it
> to chip->ecc.priv so do it in this driver directly and return a
> regular error code instead.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
Starting with this commit: 3c0fe36abebe, the kernel either doesn't
build or returns errors on some omap2plus devices with the following
error:
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
nand: Micron MT29F4G16ABBDA3W
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
Invalid ECC layout
omap2-nand 30000000.nand: unable to use BCH library
omap2-nand: probe of 30000000.nand failed with error -22
8<--- cut here ---
There are few commits using git bisect that have build errors, so it
wasn't possible for me to determine the exact commit that broke the
ECC. If the build failed, I marked it as 'bad' to git bisect.
Newer commits have remedied the build issue, but the Invalid ECC
layout error still exists as of 5.11-RC2.
Do you have any suggestions on what I can do to remedy this? I am
willing to try and test.
> drivers/mtd/nand/ecc-sw-bch.c | 36 ++++++++++++++++-------------
> drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
> drivers/mtd/nand/raw/nand_base.c | 12 ++++++----
> drivers/mtd/nand/raw/omap2.c | 16 ++++++-------
> include/linux/mtd/nand-ecc-sw-bch.h | 11 ++++-----
> 5 files changed, 41 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
> index fe080a0837d8..97221ec3876e 100644
> --- a/drivers/mtd/nand/ecc-sw-bch.c
> +++ b/drivers/mtd/nand/ecc-sw-bch.c
> @@ -90,7 +90,7 @@ EXPORT_SYMBOL(nand_bch_correct_data);
>
> /**
> * nand_bch_init - Initialize software BCH ECC engine
> - * @mtd: MTD device
> + * @chip: NAND chip object
> *
> * Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
> *
> @@ -105,24 +105,24 @@ EXPORT_SYMBOL(nand_bch_correct_data);
> * @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
> * @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
> */
> -struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> +int nand_bch_init(struct nand_chip *chip)
> {
> - struct nand_chip *nand = mtd_to_nand(mtd);
> + struct mtd_info *mtd = nand_to_mtd(chip);
> unsigned int m, t, eccsteps, i;
> struct nand_bch_control *nbc = NULL;
> unsigned char *erased_page;
> - unsigned int eccsize = nand->ecc.size;
> - unsigned int eccbytes = nand->ecc.bytes;
> - unsigned int eccstrength = nand->ecc.strength;
> + unsigned int eccsize = chip->ecc.size;
> + unsigned int eccbytes = chip->ecc.bytes;
> + unsigned int eccstrength = chip->ecc.strength;
>
> if (!eccbytes && eccstrength) {
> eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
> - nand->ecc.bytes = eccbytes;
> + chip->ecc.bytes = eccbytes;
> }
>
> if (!eccsize || !eccbytes) {
> pr_warn("ecc parameters not supplied\n");
> - goto fail;
> + return -EINVAL;
> }
>
> m = fls(1+8*eccsize);
> @@ -130,7 +130,9 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>
> nbc = kzalloc(sizeof(*nbc), GFP_KERNEL);
> if (!nbc)
> - goto fail;
> + return -ENOMEM;
> +
> + chip->ecc.priv = nbc;
>
> nbc->bch = bch_init(m, t, 0, false);
> if (!nbc->bch)
> @@ -165,8 +167,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> * FIXME: we should probably rework the sequencing in nand_scan_tail()
> * to avoid setting those fields twice.
> */
> - nand->ecc.steps = eccsteps;
> - nand->ecc.total = eccsteps * eccbytes;
> + chip->ecc.steps = eccsteps;
> + chip->ecc.total = eccsteps * eccbytes;
> if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
> pr_warn("invalid ecc layout\n");
> goto fail;
> @@ -192,12 +194,12 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> nbc->eccmask[i] ^= 0xff;
>
> if (!eccstrength)
> - nand->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
> + chip->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
>
> - return nbc;
> + return 0;
> fail:
> - nand_bch_free(nbc);
> - return NULL;
> + nand_bch_free(chip);
> + return -EINVAL;
> }
> EXPORT_SYMBOL(nand_bch_init);
>
> @@ -205,8 +207,10 @@ EXPORT_SYMBOL(nand_bch_init);
> * nand_bch_free - Release NAND BCH ECC resources
> * @nbc: NAND BCH control structure
> */
> -void nand_bch_free(struct nand_bch_control *nbc)
> +void nand_bch_free(struct nand_chip *chip)
> {
> + struct nand_bch_control *nbc = chip->ecc.priv;
> +
> if (nbc) {
> bch_free(nbc->bch);
> kfree(nbc->errloc);
> diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
> index 4191831df182..1bc2462efeab 100644
> --- a/drivers/mtd/nand/raw/fsmc_nand.c
> +++ b/drivers/mtd/nand/raw/fsmc_nand.c
> @@ -927,7 +927,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
>
> /*
> * Don't set layout for BCH4 SW ECC. This will be
> - * generated later in nand_bch_init() later.
> + * generated later during BCH initialization.
> */
> if (nand->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_HOST) {
> switch (mtd->oobsize) {
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 189d3a301a38..c47441ddc5cf 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5208,6 +5208,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct nand_device *nanddev = mtd_to_nanddev(mtd);
> struct nand_ecc_ctrl *ecc = &chip->ecc;
> + int ret;
>
> if (WARN_ON(ecc->engine_type != NAND_ECC_ENGINE_TYPE_SOFT))
> return -EINVAL;
> @@ -5294,13 +5295,14 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> ecc->strength = bytes * 8 / fls(8 * ecc->size);
> }
>
> - /* See nand_bch_init() for details. */
> + /* See the software BCH ECC initialization for details */
> ecc->bytes = 0;
> - ecc->priv = nand_bch_init(mtd);
> - if (!ecc->priv) {
> + ret = nand_bch_init(chip);
> + if (ret) {
> WARN(1, "BCH ECC initialization failed!\n");
> - return -EINVAL;
> + return ret;
> }
> +
> return 0;
> default:
> WARN(1, "Unsupported ECC algorithm!\n");
> @@ -5960,7 +5962,7 @@ void nand_cleanup(struct nand_chip *chip)
> {
> if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
> chip->ecc.algo == NAND_ECC_ALGO_BCH)
> - nand_bch_free((struct nand_bch_control *)chip->ecc.priv);
> + nand_bch_free(chip);
>
> nanddev_cleanup(&chip->base);
>
> diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
> index 0ef209e1cd87..6aab57336690 100644
> --- a/drivers/mtd/nand/raw/omap2.c
> +++ b/drivers/mtd/nand/raw/omap2.c
> @@ -2047,10 +2047,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
> /* Reserve one byte for the OMAP marker */
> oobbytes_per_step = chip->ecc.bytes + 1;
> /* Software BCH library is used for locating errors */
> - chip->ecc.priv = nand_bch_init(mtd);
> - if (!chip->ecc.priv) {
> + err = nand_bch_init(chip);
> + if (err) {
> dev_err(dev, "Unable to use BCH library\n");
> - return -EINVAL;
> + return err;
> }
> break;
>
> @@ -2089,10 +2089,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
> /* Reserve one byte for the OMAP marker */
> oobbytes_per_step = chip->ecc.bytes + 1;
> /* Software BCH library is used for locating errors */
> - chip->ecc.priv = nand_bch_init(mtd);
> - if (!chip->ecc.priv) {
> + err = nand_bch_init(chip);
> + if (err) {
> dev_err(dev, "unable to use BCH library\n");
> - return -EINVAL;
> + return err;
> }
> break;
>
> @@ -2272,7 +2272,7 @@ static int omap_nand_probe(struct platform_device *pdev)
> if (!IS_ERR_OR_NULL(info->dma))
> dma_release_channel(info->dma);
> if (nand_chip->ecc.priv) {
> - nand_bch_free(nand_chip->ecc.priv);
> + nand_bch_free(nand_chip);
> nand_chip->ecc.priv = NULL;
> }
> return err;
> @@ -2286,7 +2286,7 @@ static int omap_nand_remove(struct platform_device *pdev)
> int ret;
>
> if (nand_chip->ecc.priv) {
> - nand_bch_free(nand_chip->ecc.priv);
> + nand_bch_free(nand_chip);
> nand_chip->ecc.priv = NULL;
> }
> if (info->dma)
> diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
> index 1e1ee3af82b1..b62b8bd4669f 100644
> --- a/include/linux/mtd/nand-ecc-sw-bch.h
> +++ b/include/linux/mtd/nand-ecc-sw-bch.h
> @@ -10,7 +10,6 @@
>
> struct mtd_info;
> struct nand_chip;
> -struct nand_bch_control;
>
> #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
>
> @@ -30,11 +29,11 @@ int nand_bch_correct_data(struct nand_chip *chip, u_char *dat,
> /*
> * Initialize BCH encoder/decoder
> */
> -struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> +int nand_bch_init(struct nand_chip *chip);
> /*
> * Release BCH encoder/decoder resources
> */
> -void nand_bch_free(struct nand_bch_control *nbc);
> +void nand_bch_free(struct nand_chip *chip);
>
> #else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>
> @@ -54,12 +53,12 @@ nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
> return -ENOTSUPP;
> }
>
> -static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> +static inline int nand_bch_init(struct nand_chip *chip)
> {
> - return NULL;
> + return -ENOTSUPP;
> }
>
> -static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> +static inline void nand_bch_free(struct nand_chip *chip) {}
>
> #endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>
> --
> 2.20.1
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-09 14:46 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-09 14:46 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> The NAND BCH control structure has nothing to do outside of this
> driver, all users of the nand_bch_init/free() functions just save it
> to chip->ecc.priv so do it in this driver directly and return a
> regular error code instead.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
Starting with this commit: 3c0fe36abebe, the kernel either doesn't
build or returns errors on some omap2plus devices with the following
error:
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
nand: Micron MT29F4G16ABBDA3W
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
Invalid ECC layout
omap2-nand 30000000.nand: unable to use BCH library
omap2-nand: probe of 30000000.nand failed with error -22
8<--- cut here ---
There are few commits using git bisect that have build errors, so it
wasn't possible for me to determine the exact commit that broke the
ECC. If the build failed, I marked it as 'bad' to git bisect.
Newer commits have remedied the build issue, but the Invalid ECC
layout error still exists as of 5.11-RC2.
Do you have any suggestions on what I can do to remedy this? I am
willing to try and test.
> drivers/mtd/nand/ecc-sw-bch.c | 36 ++++++++++++++++-------------
> drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
> drivers/mtd/nand/raw/nand_base.c | 12 ++++++----
> drivers/mtd/nand/raw/omap2.c | 16 ++++++-------
> include/linux/mtd/nand-ecc-sw-bch.h | 11 ++++-----
> 5 files changed, 41 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
> index fe080a0837d8..97221ec3876e 100644
> --- a/drivers/mtd/nand/ecc-sw-bch.c
> +++ b/drivers/mtd/nand/ecc-sw-bch.c
> @@ -90,7 +90,7 @@ EXPORT_SYMBOL(nand_bch_correct_data);
>
> /**
> * nand_bch_init - Initialize software BCH ECC engine
> - * @mtd: MTD device
> + * @chip: NAND chip object
> *
> * Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
> *
> @@ -105,24 +105,24 @@ EXPORT_SYMBOL(nand_bch_correct_data);
> * @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
> * @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
> */
> -struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> +int nand_bch_init(struct nand_chip *chip)
> {
> - struct nand_chip *nand = mtd_to_nand(mtd);
> + struct mtd_info *mtd = nand_to_mtd(chip);
> unsigned int m, t, eccsteps, i;
> struct nand_bch_control *nbc = NULL;
> unsigned char *erased_page;
> - unsigned int eccsize = nand->ecc.size;
> - unsigned int eccbytes = nand->ecc.bytes;
> - unsigned int eccstrength = nand->ecc.strength;
> + unsigned int eccsize = chip->ecc.size;
> + unsigned int eccbytes = chip->ecc.bytes;
> + unsigned int eccstrength = chip->ecc.strength;
>
> if (!eccbytes && eccstrength) {
> eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
> - nand->ecc.bytes = eccbytes;
> + chip->ecc.bytes = eccbytes;
> }
>
> if (!eccsize || !eccbytes) {
> pr_warn("ecc parameters not supplied\n");
> - goto fail;
> + return -EINVAL;
> }
>
> m = fls(1+8*eccsize);
> @@ -130,7 +130,9 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>
> nbc = kzalloc(sizeof(*nbc), GFP_KERNEL);
> if (!nbc)
> - goto fail;
> + return -ENOMEM;
> +
> + chip->ecc.priv = nbc;
>
> nbc->bch = bch_init(m, t, 0, false);
> if (!nbc->bch)
> @@ -165,8 +167,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> * FIXME: we should probably rework the sequencing in nand_scan_tail()
> * to avoid setting those fields twice.
> */
> - nand->ecc.steps = eccsteps;
> - nand->ecc.total = eccsteps * eccbytes;
> + chip->ecc.steps = eccsteps;
> + chip->ecc.total = eccsteps * eccbytes;
> if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
> pr_warn("invalid ecc layout\n");
> goto fail;
> @@ -192,12 +194,12 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> nbc->eccmask[i] ^= 0xff;
>
> if (!eccstrength)
> - nand->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
> + chip->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
>
> - return nbc;
> + return 0;
> fail:
> - nand_bch_free(nbc);
> - return NULL;
> + nand_bch_free(chip);
> + return -EINVAL;
> }
> EXPORT_SYMBOL(nand_bch_init);
>
> @@ -205,8 +207,10 @@ EXPORT_SYMBOL(nand_bch_init);
> * nand_bch_free - Release NAND BCH ECC resources
> * @nbc: NAND BCH control structure
> */
> -void nand_bch_free(struct nand_bch_control *nbc)
> +void nand_bch_free(struct nand_chip *chip)
> {
> + struct nand_bch_control *nbc = chip->ecc.priv;
> +
> if (nbc) {
> bch_free(nbc->bch);
> kfree(nbc->errloc);
> diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
> index 4191831df182..1bc2462efeab 100644
> --- a/drivers/mtd/nand/raw/fsmc_nand.c
> +++ b/drivers/mtd/nand/raw/fsmc_nand.c
> @@ -927,7 +927,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
>
> /*
> * Don't set layout for BCH4 SW ECC. This will be
> - * generated later in nand_bch_init() later.
> + * generated later during BCH initialization.
> */
> if (nand->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_HOST) {
> switch (mtd->oobsize) {
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 189d3a301a38..c47441ddc5cf 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5208,6 +5208,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct nand_device *nanddev = mtd_to_nanddev(mtd);
> struct nand_ecc_ctrl *ecc = &chip->ecc;
> + int ret;
>
> if (WARN_ON(ecc->engine_type != NAND_ECC_ENGINE_TYPE_SOFT))
> return -EINVAL;
> @@ -5294,13 +5295,14 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
> ecc->strength = bytes * 8 / fls(8 * ecc->size);
> }
>
> - /* See nand_bch_init() for details. */
> + /* See the software BCH ECC initialization for details */
> ecc->bytes = 0;
> - ecc->priv = nand_bch_init(mtd);
> - if (!ecc->priv) {
> + ret = nand_bch_init(chip);
> + if (ret) {
> WARN(1, "BCH ECC initialization failed!\n");
> - return -EINVAL;
> + return ret;
> }
> +
> return 0;
> default:
> WARN(1, "Unsupported ECC algorithm!\n");
> @@ -5960,7 +5962,7 @@ void nand_cleanup(struct nand_chip *chip)
> {
> if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
> chip->ecc.algo == NAND_ECC_ALGO_BCH)
> - nand_bch_free((struct nand_bch_control *)chip->ecc.priv);
> + nand_bch_free(chip);
>
> nanddev_cleanup(&chip->base);
>
> diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
> index 0ef209e1cd87..6aab57336690 100644
> --- a/drivers/mtd/nand/raw/omap2.c
> +++ b/drivers/mtd/nand/raw/omap2.c
> @@ -2047,10 +2047,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
> /* Reserve one byte for the OMAP marker */
> oobbytes_per_step = chip->ecc.bytes + 1;
> /* Software BCH library is used for locating errors */
> - chip->ecc.priv = nand_bch_init(mtd);
> - if (!chip->ecc.priv) {
> + err = nand_bch_init(chip);
> + if (err) {
> dev_err(dev, "Unable to use BCH library\n");
> - return -EINVAL;
> + return err;
> }
> break;
>
> @@ -2089,10 +2089,10 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
> /* Reserve one byte for the OMAP marker */
> oobbytes_per_step = chip->ecc.bytes + 1;
> /* Software BCH library is used for locating errors */
> - chip->ecc.priv = nand_bch_init(mtd);
> - if (!chip->ecc.priv) {
> + err = nand_bch_init(chip);
> + if (err) {
> dev_err(dev, "unable to use BCH library\n");
> - return -EINVAL;
> + return err;
> }
> break;
>
> @@ -2272,7 +2272,7 @@ static int omap_nand_probe(struct platform_device *pdev)
> if (!IS_ERR_OR_NULL(info->dma))
> dma_release_channel(info->dma);
> if (nand_chip->ecc.priv) {
> - nand_bch_free(nand_chip->ecc.priv);
> + nand_bch_free(nand_chip);
> nand_chip->ecc.priv = NULL;
> }
> return err;
> @@ -2286,7 +2286,7 @@ static int omap_nand_remove(struct platform_device *pdev)
> int ret;
>
> if (nand_chip->ecc.priv) {
> - nand_bch_free(nand_chip->ecc.priv);
> + nand_bch_free(nand_chip);
> nand_chip->ecc.priv = NULL;
> }
> if (info->dma)
> diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
> index 1e1ee3af82b1..b62b8bd4669f 100644
> --- a/include/linux/mtd/nand-ecc-sw-bch.h
> +++ b/include/linux/mtd/nand-ecc-sw-bch.h
> @@ -10,7 +10,6 @@
>
> struct mtd_info;
> struct nand_chip;
> -struct nand_bch_control;
>
> #if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
>
> @@ -30,11 +29,11 @@ int nand_bch_correct_data(struct nand_chip *chip, u_char *dat,
> /*
> * Initialize BCH encoder/decoder
> */
> -struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> +int nand_bch_init(struct nand_chip *chip);
> /*
> * Release BCH encoder/decoder resources
> */
> -void nand_bch_free(struct nand_bch_control *nbc);
> +void nand_bch_free(struct nand_chip *chip);
>
> #else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>
> @@ -54,12 +53,12 @@ nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
> return -ENOTSUPP;
> }
>
> -static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> +static inline int nand_bch_init(struct nand_chip *chip)
> {
> - return NULL;
> + return -ENOTSUPP;
> }
>
> -static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> +static inline void nand_bch_free(struct nand_chip *chip) {}
>
> #endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>
> --
> 2.20.1
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-09 14:46 ` Adam Ford
@ 2021-01-11 10:20 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-11 10:20 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > The NAND BCH control structure has nothing to do outside of this
> > driver, all users of the nand_bch_init/free() functions just save it
> > to chip->ecc.priv so do it in this driver directly and return a
> > regular error code instead.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
>
> Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> build or returns errors on some omap2plus devices with the following
> error:
>
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> nand: Micron MT29F4G16ABBDA3W
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> Invalid ECC layout
> omap2-nand 30000000.nand: unable to use BCH library
> omap2-nand: probe of 30000000.nand failed with error -22
> 8<--- cut here ---
>
> There are few commits using git bisect that have build errors, so it
> wasn't possible for me to determine the exact commit that broke the
> ECC. If the build failed, I marked it as 'bad' to git bisect.
I am sorry to hear that, I regularly rebase with a make run between each
pick and push my branches to a 0-day repository to have robots check
for such errors, but sometimes I fail.
> Newer commits have remedied the build issue, but the Invalid ECC
> layout error still exists as of 5.11-RC2.
Ok so let's focus on these.
> Do you have any suggestions on what I can do to remedy this? I am
> willing to try and test.
Glad to hear that.
Can you share the NAND controller DT node you are using?
Also, can you please add a few printk's like below and give me the
output?
---8<---
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index 0a0ac11d5725..0d3e948d02e9 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -205,6 +205,7 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
}
nsteps = mtd->writesize / conf->step_size;
+ printk("writesize %d, step_size %d, nsteps %d\n", mtd->writesize, conf->step_size, nsteps);
/* Maximize */
if (nand->ecc.user_conf.flags & NAND_ECC_MAXIMIZE_STRENGTH) {
@@ -213,11 +214,14 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
/* Reserve 2 bytes for the BBM */
code_size = (mtd->oobsize - 2) / nsteps;
conf->strength = code_size * 8 / fls(8 * conf->step_size);
+ printk("Maximize => nsteps %d, code_size %d\n", nsteps, code_size);
}
- if (!code_size)
+ if (!code_size) {
code_size = DIV_ROUND_UP(conf->strength *
fls(8 * conf->step_size), 8);
+ printk("strength %d, step size %d, code_size %d\n", conf->strength, conf->step_size, code_size);
+ }
if (!conf->strength)
conf->strength = (code_size * 8) / fls(8 * conf->step_size);
@@ -252,6 +256,7 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
goto free_bufs;
/* Verify the layout validity */
+ printk("count eccbytes %d\n", mtd_ooblayout_count_eccbytes(mtd));
if (mtd_ooblayout_count_eccbytes(mtd) !=
engine_conf->nsteps * engine_conf->code_size) {
pr_err("Invalid ECC layout\n");
--->8---
Thanks,
Miquèl
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-11 10:20 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-11 10:20 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > The NAND BCH control structure has nothing to do outside of this
> > driver, all users of the nand_bch_init/free() functions just save it
> > to chip->ecc.priv so do it in this driver directly and return a
> > regular error code instead.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
>
> Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> build or returns errors on some omap2plus devices with the following
> error:
>
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> nand: Micron MT29F4G16ABBDA3W
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> Invalid ECC layout
> omap2-nand 30000000.nand: unable to use BCH library
> omap2-nand: probe of 30000000.nand failed with error -22
> 8<--- cut here ---
>
> There are few commits using git bisect that have build errors, so it
> wasn't possible for me to determine the exact commit that broke the
> ECC. If the build failed, I marked it as 'bad' to git bisect.
I am sorry to hear that, I regularly rebase with a make run between each
pick and push my branches to a 0-day repository to have robots check
for such errors, but sometimes I fail.
> Newer commits have remedied the build issue, but the Invalid ECC
> layout error still exists as of 5.11-RC2.
Ok so let's focus on these.
> Do you have any suggestions on what I can do to remedy this? I am
> willing to try and test.
Glad to hear that.
Can you share the NAND controller DT node you are using?
Also, can you please add a few printk's like below and give me the
output?
---8<---
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index 0a0ac11d5725..0d3e948d02e9 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -205,6 +205,7 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
}
nsteps = mtd->writesize / conf->step_size;
+ printk("writesize %d, step_size %d, nsteps %d\n", mtd->writesize, conf->step_size, nsteps);
/* Maximize */
if (nand->ecc.user_conf.flags & NAND_ECC_MAXIMIZE_STRENGTH) {
@@ -213,11 +214,14 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
/* Reserve 2 bytes for the BBM */
code_size = (mtd->oobsize - 2) / nsteps;
conf->strength = code_size * 8 / fls(8 * conf->step_size);
+ printk("Maximize => nsteps %d, code_size %d\n", nsteps, code_size);
}
- if (!code_size)
+ if (!code_size) {
code_size = DIV_ROUND_UP(conf->strength *
fls(8 * conf->step_size), 8);
+ printk("strength %d, step size %d, code_size %d\n", conf->strength, conf->step_size, code_size);
+ }
if (!conf->strength)
conf->strength = (code_size * 8) / fls(8 * conf->step_size);
@@ -252,6 +256,7 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
goto free_bufs;
/* Verify the layout validity */
+ printk("count eccbytes %d\n", mtd_ooblayout_count_eccbytes(mtd));
if (mtd_ooblayout_count_eccbytes(mtd) !=
engine_conf->nsteps * engine_conf->code_size) {
pr_err("Invalid ECC layout\n");
--->8---
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-11 10:20 ` Miquel Raynal
@ 2021-01-12 14:35 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-12 14:35 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
11:20:27 +0100:
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
>
> > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > The NAND BCH control structure has nothing to do outside of this
> > > driver, all users of the nand_bch_init/free() functions just save it
> > > to chip->ecc.priv so do it in this driver directly and return a
> > > regular error code instead.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> >
> > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > build or returns errors on some omap2plus devices with the following
> > error:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > nand: Micron MT29F4G16ABBDA3W
> > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > Invalid ECC layout
> > omap2-nand 30000000.nand: unable to use BCH library
> > omap2-nand: probe of 30000000.nand failed with error -22
> > 8<--- cut here ---
> >
> > There are few commits using git bisect that have build errors, so it
> > wasn't possible for me to determine the exact commit that broke the
> > ECC. If the build failed, I marked it as 'bad' to git bisect.
>
> I am sorry to hear that, I regularly rebase with a make run between each
> pick and push my branches to a 0-day repository to have robots check
> for such errors, but sometimes I fail.
>
> > Newer commits have remedied the build issue, but the Invalid ECC
> > layout error still exists as of 5.11-RC2.
>
> Ok so let's focus on these.
>
> > Do you have any suggestions on what I can do to remedy this? I am
> > willing to try and test.
>
> Glad to hear that.
>
> Can you share the NAND controller DT node you are using?
>
> Also, can you please add a few printk's like below and give me the
> output?
Will you have the time to check these soon? I am ready to help and
would like to fix it asap.
Cheers,
Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-12 14:35 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-12 14:35 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
11:20:27 +0100:
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
>
> > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > The NAND BCH control structure has nothing to do outside of this
> > > driver, all users of the nand_bch_init/free() functions just save it
> > > to chip->ecc.priv so do it in this driver directly and return a
> > > regular error code instead.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> >
> > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > build or returns errors on some omap2plus devices with the following
> > error:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > nand: Micron MT29F4G16ABBDA3W
> > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > Invalid ECC layout
> > omap2-nand 30000000.nand: unable to use BCH library
> > omap2-nand: probe of 30000000.nand failed with error -22
> > 8<--- cut here ---
> >
> > There are few commits using git bisect that have build errors, so it
> > wasn't possible for me to determine the exact commit that broke the
> > ECC. If the build failed, I marked it as 'bad' to git bisect.
>
> I am sorry to hear that, I regularly rebase with a make run between each
> pick and push my branches to a 0-day repository to have robots check
> for such errors, but sometimes I fail.
>
> > Newer commits have remedied the build issue, but the Invalid ECC
> > layout error still exists as of 5.11-RC2.
>
> Ok so let's focus on these.
>
> > Do you have any suggestions on what I can do to remedy this? I am
> > willing to try and test.
>
> Glad to hear that.
>
> Can you share the NAND controller DT node you are using?
>
> Also, can you please add a few printk's like below and give me the
> output?
Will you have the time to check these soon? I am ready to help and
would like to fix it asap.
Cheers,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-12 14:35 ` Miquel Raynal
@ 2021-01-12 16:01 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-12 16:01 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> 11:20:27 +0100:
>
> > Hi Adam,
> >
> > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> >
> > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > The NAND BCH control structure has nothing to do outside of this
> > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > regular error code instead.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > >
> > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > build or returns errors on some omap2plus devices with the following
> > > error:
> > >
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > nand: Micron MT29F4G16ABBDA3W
> > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > Invalid ECC layout
> > > omap2-nand 30000000.nand: unable to use BCH library
> > > omap2-nand: probe of 30000000.nand failed with error -22
> > > 8<--- cut here ---
> > >
> > > There are few commits using git bisect that have build errors, so it
> > > wasn't possible for me to determine the exact commit that broke the
> > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> >
> > I am sorry to hear that, I regularly rebase with a make run between each
> > pick and push my branches to a 0-day repository to have robots check
> > for such errors, but sometimes I fail.
> >
> > > Newer commits have remedied the build issue, but the Invalid ECC
> > > layout error still exists as of 5.11-RC2.
> >
> > Ok so let's focus on these.
> >
> > > Do you have any suggestions on what I can do to remedy this? I am
> > > willing to try and test.
> >
> > Glad to hear that.
> >
> > Can you share the NAND controller DT node you are using?
> >
> > Also, can you please add a few printk's like below and give me the
> > output?
>
> Will you have the time to check these soon? I am ready to help and
> would like to fix it asap.
Sorry for the delay, I have to split my time with 3 different
projects. I am hoping to get you data later today.
adam
>
> Cheers,
> Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-12 16:01 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-12 16:01 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> 11:20:27 +0100:
>
> > Hi Adam,
> >
> > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> >
> > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > The NAND BCH control structure has nothing to do outside of this
> > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > regular error code instead.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > >
> > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > build or returns errors on some omap2plus devices with the following
> > > error:
> > >
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > nand: Micron MT29F4G16ABBDA3W
> > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > Invalid ECC layout
> > > omap2-nand 30000000.nand: unable to use BCH library
> > > omap2-nand: probe of 30000000.nand failed with error -22
> > > 8<--- cut here ---
> > >
> > > There are few commits using git bisect that have build errors, so it
> > > wasn't possible for me to determine the exact commit that broke the
> > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> >
> > I am sorry to hear that, I regularly rebase with a make run between each
> > pick and push my branches to a 0-day repository to have robots check
> > for such errors, but sometimes I fail.
> >
> > > Newer commits have remedied the build issue, but the Invalid ECC
> > > layout error still exists as of 5.11-RC2.
> >
> > Ok so let's focus on these.
> >
> > > Do you have any suggestions on what I can do to remedy this? I am
> > > willing to try and test.
> >
> > Glad to hear that.
> >
> > Can you share the NAND controller DT node you are using?
> >
> > Also, can you please add a few printk's like below and give me the
> > output?
>
> Will you have the time to check these soon? I am ready to help and
> would like to fix it asap.
Sorry for the delay, I have to split my time with 3 different
projects. I am hoping to get you data later today.
adam
>
> Cheers,
> Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-12 16:01 ` Adam Ford
@ 2021-01-12 17:20 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-12 17:20 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > 11:20:27 +0100:
> >
> > > Hi Adam,
> > >
> > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > >
> > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > regular error code instead.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > >
> > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > build or returns errors on some omap2plus devices with the following
> > > > error:
> > > >
> > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > nand: Micron MT29F4G16ABBDA3W
> > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > Invalid ECC layout
> > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > 8<--- cut here ---
> > > >
> > > > There are few commits using git bisect that have build errors, so it
> > > > wasn't possible for me to determine the exact commit that broke the
> > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > >
> > > I am sorry to hear that, I regularly rebase with a make run between each
> > > pick and push my branches to a 0-day repository to have robots check
> > > for such errors, but sometimes I fail.
> > >
> > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > layout error still exists as of 5.11-RC2.
> > >
> > > Ok so let's focus on these.
> > >
> > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > willing to try and test.
> > >
> > > Glad to hear that.
> > >
> > > Can you share the NAND controller DT node you are using?
> > >
> > > Also, can you please add a few printk's like below and give me the
> > > output?
> >
> > Will you have the time to check these soon? I am ready to help and
> > would like to fix it asap.
>
> Sorry for the delay, I have to split my time with 3 different
> projects. I am hoping to get you data later today.
>
Miquel,
Here is the dump from my boot sequence:
[ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
[ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.666900] nand: Micron MT29F4G16ABBDA3W
[ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
[ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684234] writesize 2048, step_size 512, nsteps 4
[ 2.689300] strength 8, step size 512, code_size 13
[ 2.696807] count eccbytes 0
[ 2.699707] Invalid ECC layout
[ 2.702789] omap2-nand 30000000.nand: unable to use BCH library
[ 2.709014] omap2-nand: probe of 30000000.nand failed with error -22
[ 2.722656] 8<--- cut here ---
Let me know if/what else you want me to try.
adam
> adam
> >
> > Cheers,
> > Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-12 17:20 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-12 17:20 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > 11:20:27 +0100:
> >
> > > Hi Adam,
> > >
> > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > >
> > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > regular error code instead.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > ---
> > > >
> > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > build or returns errors on some omap2plus devices with the following
> > > > error:
> > > >
> > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > nand: Micron MT29F4G16ABBDA3W
> > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > Invalid ECC layout
> > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > 8<--- cut here ---
> > > >
> > > > There are few commits using git bisect that have build errors, so it
> > > > wasn't possible for me to determine the exact commit that broke the
> > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > >
> > > I am sorry to hear that, I regularly rebase with a make run between each
> > > pick and push my branches to a 0-day repository to have robots check
> > > for such errors, but sometimes I fail.
> > >
> > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > layout error still exists as of 5.11-RC2.
> > >
> > > Ok so let's focus on these.
> > >
> > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > willing to try and test.
> > >
> > > Glad to hear that.
> > >
> > > Can you share the NAND controller DT node you are using?
> > >
> > > Also, can you please add a few printk's like below and give me the
> > > output?
> >
> > Will you have the time to check these soon? I am ready to help and
> > would like to fix it asap.
>
> Sorry for the delay, I have to split my time with 3 different
> projects. I am hoping to get you data later today.
>
Miquel,
Here is the dump from my boot sequence:
[ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
[ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.666900] nand: Micron MT29F4G16ABBDA3W
[ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
[ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684234] writesize 2048, step_size 512, nsteps 4
[ 2.689300] strength 8, step size 512, code_size 13
[ 2.696807] count eccbytes 0
[ 2.699707] Invalid ECC layout
[ 2.702789] omap2-nand 30000000.nand: unable to use BCH library
[ 2.709014] omap2-nand: probe of 30000000.nand failed with error -22
[ 2.722656] 8<--- cut here ---
Let me know if/what else you want me to try.
adam
> adam
> >
> > Cheers,
> > Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-12 17:20 ` Adam Ford
@ 2021-01-14 15:42 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-14 15:42 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > 11:20:27 +0100:
> > >
> > > > Hi Adam,
> > > >
> > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > >
> > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > regular error code instead.
> > > > > >
> > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > ---
> > > > >
> > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > build or returns errors on some omap2plus devices with the following
> > > > > error:
> > > > >
> > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > Invalid ECC layout
> > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > 8<--- cut here ---
> > > > >
> > > > > There are few commits using git bisect that have build errors, so it
> > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > >
> > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > pick and push my branches to a 0-day repository to have robots check
> > > > for such errors, but sometimes I fail.
> > > >
> > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > layout error still exists as of 5.11-RC2.
> > > >
> > > > Ok so let's focus on these.
> > > >
> > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > willing to try and test.
> > > >
> > > > Glad to hear that.
> > > >
> > > > Can you share the NAND controller DT node you are using?
> > > >
> > > > Also, can you please add a few printk's like below and give me the
> > > > output?
> > >
> > > Will you have the time to check these soon? I am ready to help and
> > > would like to fix it asap.
> >
> > Sorry for the delay, I have to split my time with 3 different
> > projects. I am hoping to get you data later today.
> >
> Miquel,
>
> Here is the dump from my boot sequence:
>
> [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> [ 2.684234] writesize 2048, step_size 512, nsteps 4
> [ 2.689300] strength 8, step size 512, code_size 13
Until here, everything looks fine.
> [ 2.696807] count eccbytes 0
This is the cause of the error, the MTD OOB layout reports not ECC byte.
Can you please check that we effectively call the large page helpers
(in particular nand_ooblayout_ecc_lp()) . I bet this function returns
-ERANGE on its first call, which reduces the eccbytes variable above to
zero.
What is strange is that, the only reason this would happen (to my eyes)
is nand->ecc.ctx.total being 0. Can you please check its effective
value?
I do not see the immediate reason because nand->ecc.ctx.total is set to
nsteps (4) * code_size (13) right before calling
mtd_ooblayout_count_eccbytes().
Can you please verify my sayings and perhaps tackle the root cause of
this issue? Please do not hesitate to ask questions, I'll do my best to
help because this is a critical section that is not only breaking
OMAP boards, unfortunately.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-14 15:42 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-14 15:42 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > 11:20:27 +0100:
> > >
> > > > Hi Adam,
> > > >
> > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > >
> > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > regular error code instead.
> > > > > >
> > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > ---
> > > > >
> > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > build or returns errors on some omap2plus devices with the following
> > > > > error:
> > > > >
> > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > Invalid ECC layout
> > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > 8<--- cut here ---
> > > > >
> > > > > There are few commits using git bisect that have build errors, so it
> > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > >
> > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > pick and push my branches to a 0-day repository to have robots check
> > > > for such errors, but sometimes I fail.
> > > >
> > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > layout error still exists as of 5.11-RC2.
> > > >
> > > > Ok so let's focus on these.
> > > >
> > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > willing to try and test.
> > > >
> > > > Glad to hear that.
> > > >
> > > > Can you share the NAND controller DT node you are using?
> > > >
> > > > Also, can you please add a few printk's like below and give me the
> > > > output?
> > >
> > > Will you have the time to check these soon? I am ready to help and
> > > would like to fix it asap.
> >
> > Sorry for the delay, I have to split my time with 3 different
> > projects. I am hoping to get you data later today.
> >
> Miquel,
>
> Here is the dump from my boot sequence:
>
> [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> [ 2.684234] writesize 2048, step_size 512, nsteps 4
> [ 2.689300] strength 8, step size 512, code_size 13
Until here, everything looks fine.
> [ 2.696807] count eccbytes 0
This is the cause of the error, the MTD OOB layout reports not ECC byte.
Can you please check that we effectively call the large page helpers
(in particular nand_ooblayout_ecc_lp()) . I bet this function returns
-ERANGE on its first call, which reduces the eccbytes variable above to
zero.
What is strange is that, the only reason this would happen (to my eyes)
is nand->ecc.ctx.total being 0. Can you please check its effective
value?
I do not see the immediate reason because nand->ecc.ctx.total is set to
nsteps (4) * code_size (13) right before calling
mtd_ooblayout_count_eccbytes().
Can you please verify my sayings and perhaps tackle the root cause of
this issue? Please do not hesitate to ask questions, I'll do my best to
help because this is a critical section that is not only breaking
OMAP boards, unfortunately.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-14 15:42 ` Miquel Raynal
@ 2021-01-15 12:23 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 12:23 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
>
> > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > 11:20:27 +0100:
> > > >
> > > > > Hi Adam,
> > > > >
> > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > >
> > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > regular error code instead.
> > > > > > >
> > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > ---
> > > > > >
> > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > error:
> > > > > >
> > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > Invalid ECC layout
> > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > 8<--- cut here ---
> > > > > >
> > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > >
> > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > for such errors, but sometimes I fail.
> > > > >
> > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > layout error still exists as of 5.11-RC2.
> > > > >
> > > > > Ok so let's focus on these.
> > > > >
> > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > willing to try and test.
> > > > >
> > > > > Glad to hear that.
> > > > >
> > > > > Can you share the NAND controller DT node you are using?
> > > > >
> > > > > Also, can you please add a few printk's like below and give me the
> > > > > output?
> > > >
> > > > Will you have the time to check these soon? I am ready to help and
> > > > would like to fix it asap.
> > >
> > > Sorry for the delay, I have to split my time with 3 different
> > > projects. I am hoping to get you data later today.
> > >
> > Miquel,
> >
> > Here is the dump from my boot sequence:
> >
> > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > [ 2.689300] strength 8, step size 512, code_size 13
>
> Until here, everything looks fine.
>
> > [ 2.696807] count eccbytes 0
>
> This is the cause of the error, the MTD OOB layout reports not ECC byte.
>
> Can you please check that we effectively call the large page helpers
> (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> -ERANGE on its first call, which reduces the eccbytes variable above to
> zero.
I will do what I can, but I am out of my element with this mtd and nand stuff.
I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
called.
I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
what's being defined for section and ecc.steps.
[ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
[ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.667510] nand: Micron MT29F4G16ABBDA3W
[ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684844] writesize 2048, step_size 512, nsteps 4
[ 2.689910] strength 8, step size 512, code_size 13
[ 2.694824] nand->ecc.ctx.total = 52
[ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
which appears to be the case here.
Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
[ 2.707031] count eccbytes 0
[ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
[ 2.715820] Invalid ECC layout
[ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
[ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
[ 2.738983] 8<--- cut here ---
>
> What is strange is that, the only reason this would happen (to my eyes)
> is nand->ecc.ctx.total being 0. Can you please check its effective
> value?
[ 2.694824] nand->ecc.ctx.total = 52
>
> I do not see the immediate reason because nand->ecc.ctx.total is set to
> nsteps (4) * code_size (13) right before calling
> mtd_ooblayout_count_eccbytes().
>
> Can you please verify my sayings and perhaps tackle the root cause of
> this issue? Please do not hesitate to ask questions, I'll do my best to
> help because this is a critical section that is not only breaking
> OMAP boards, unfortunately.
>
> Thanks,
> Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-15 12:23 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 12:23 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
>
> > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > 11:20:27 +0100:
> > > >
> > > > > Hi Adam,
> > > > >
> > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > >
> > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > regular error code instead.
> > > > > > >
> > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > ---
> > > > > >
> > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > error:
> > > > > >
> > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > Invalid ECC layout
> > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > 8<--- cut here ---
> > > > > >
> > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > >
> > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > for such errors, but sometimes I fail.
> > > > >
> > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > layout error still exists as of 5.11-RC2.
> > > > >
> > > > > Ok so let's focus on these.
> > > > >
> > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > willing to try and test.
> > > > >
> > > > > Glad to hear that.
> > > > >
> > > > > Can you share the NAND controller DT node you are using?
> > > > >
> > > > > Also, can you please add a few printk's like below and give me the
> > > > > output?
> > > >
> > > > Will you have the time to check these soon? I am ready to help and
> > > > would like to fix it asap.
> > >
> > > Sorry for the delay, I have to split my time with 3 different
> > > projects. I am hoping to get you data later today.
> > >
> > Miquel,
> >
> > Here is the dump from my boot sequence:
> >
> > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > [ 2.689300] strength 8, step size 512, code_size 13
>
> Until here, everything looks fine.
>
> > [ 2.696807] count eccbytes 0
>
> This is the cause of the error, the MTD OOB layout reports not ECC byte.
>
> Can you please check that we effectively call the large page helpers
> (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> -ERANGE on its first call, which reduces the eccbytes variable above to
> zero.
I will do what I can, but I am out of my element with this mtd and nand stuff.
I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
called.
I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
what's being defined for section and ecc.steps.
[ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
[ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.667510] nand: Micron MT29F4G16ABBDA3W
[ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684844] writesize 2048, step_size 512, nsteps 4
[ 2.689910] strength 8, step size 512, code_size 13
[ 2.694824] nand->ecc.ctx.total = 52
[ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
which appears to be the case here.
Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
[ 2.707031] count eccbytes 0
[ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
[ 2.715820] Invalid ECC layout
[ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
[ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
[ 2.738983] 8<--- cut here ---
>
> What is strange is that, the only reason this would happen (to my eyes)
> is nand->ecc.ctx.total being 0. Can you please check its effective
> value?
[ 2.694824] nand->ecc.ctx.total = 52
>
> I do not see the immediate reason because nand->ecc.ctx.total is set to
> nsteps (4) * code_size (13) right before calling
> mtd_ooblayout_count_eccbytes().
>
> Can you please verify my sayings and perhaps tackle the root cause of
> this issue? Please do not hesitate to ask questions, I'll do my best to
> help because this is a critical section that is not only breaking
> OMAP boards, unfortunately.
>
> Thanks,
> Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-15 12:23 ` Adam Ford
@ 2021-01-15 16:06 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 16:06 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> >
> > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Adam,
> > > > >
> > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > 11:20:27 +0100:
> > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > >
> > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > >
> > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > regular error code instead.
> > > > > > > >
> > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > ---
> > > > > > >
> > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > error:
> > > > > > >
> > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > Invalid ECC layout
> > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > 8<--- cut here ---
> > > > > > >
> > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > >
> > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > for such errors, but sometimes I fail.
> > > > > >
> > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > layout error still exists as of 5.11-RC2.
> > > > > >
> > > > > > Ok so let's focus on these.
> > > > > >
> > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > willing to try and test.
> > > > > >
> > > > > > Glad to hear that.
> > > > > >
> > > > > > Can you share the NAND controller DT node you are using?
> > > > > >
> > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > output?
> > > > >
> > > > > Will you have the time to check these soon? I am ready to help and
> > > > > would like to fix it asap.
> > > >
> > > > Sorry for the delay, I have to split my time with 3 different
> > > > projects. I am hoping to get you data later today.
> > > >
> > > Miquel,
> > >
> > > Here is the dump from my boot sequence:
> > >
> > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > [ 2.689300] strength 8, step size 512, code_size 13
> >
> > Until here, everything looks fine.
> >
> > > [ 2.696807] count eccbytes 0
> >
> > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> >
> > Can you please check that we effectively call the large page helpers
> > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > -ERANGE on its first call, which reduces the eccbytes variable above to
> > zero.
>
> I will do what I can, but I am out of my element with this mtd and nand stuff.
>
> I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> called.
>
> I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> what's being defined for section and ecc.steps.
>
> [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> [ 2.684844] writesize 2048, step_size 512, nsteps 4
> [ 2.689910] strength 8, step size 512, code_size 13
> [ 2.694824] nand->ecc.ctx.total = 52
> [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
>
> omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> which appears to be the case here.
>
> Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
>
> [ 2.707031] count eccbytes 0
> [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> [ 2.715820] Invalid ECC layout
> [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> [ 2.738983] 8<--- cut here ---
>
> >
> > What is strange is that, the only reason this would happen (to my eyes)
> > is nand->ecc.ctx.total being 0. Can you please check its effective
> > value?
>
> [ 2.694824] nand->ecc.ctx.total = 52
>
> >
> > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > nsteps (4) * code_size (13) right before calling
> > mtd_ooblayout_count_eccbytes().
> >
> > Can you please verify my sayings and perhaps tackle the root cause of
> > this issue? Please do not hesitate to ask questions, I'll do my best to
> > help because this is a critical section that is not only breaking
> > OMAP boards, unfortunately.
I appear to have the NAND flash working with the following patch:
@@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
nand->ecc.ctx.priv = engine_conf;
nand->ecc.ctx.total = nsteps * code_size;
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ chip->ecc.steps = nsteps;
+ chip->ecc.size = conf->step_size;
I am guessing it's not exactly what you want, but appears that the
ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
when omap_sw_ooblayout_ecc() was called, those fields were blank.
If you have a suggestion on how you want this implemented, I can push a patch.
adam
> >
> > Thanks,
> > Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-15 16:06 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 16:06 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> >
> > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Adam,
> > > > >
> > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > 11:20:27 +0100:
> > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > >
> > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > >
> > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > regular error code instead.
> > > > > > > >
> > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > ---
> > > > > > >
> > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > error:
> > > > > > >
> > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > Invalid ECC layout
> > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > 8<--- cut here ---
> > > > > > >
> > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > >
> > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > for such errors, but sometimes I fail.
> > > > > >
> > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > layout error still exists as of 5.11-RC2.
> > > > > >
> > > > > > Ok so let's focus on these.
> > > > > >
> > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > willing to try and test.
> > > > > >
> > > > > > Glad to hear that.
> > > > > >
> > > > > > Can you share the NAND controller DT node you are using?
> > > > > >
> > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > output?
> > > > >
> > > > > Will you have the time to check these soon? I am ready to help and
> > > > > would like to fix it asap.
> > > >
> > > > Sorry for the delay, I have to split my time with 3 different
> > > > projects. I am hoping to get you data later today.
> > > >
> > > Miquel,
> > >
> > > Here is the dump from my boot sequence:
> > >
> > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > [ 2.689300] strength 8, step size 512, code_size 13
> >
> > Until here, everything looks fine.
> >
> > > [ 2.696807] count eccbytes 0
> >
> > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> >
> > Can you please check that we effectively call the large page helpers
> > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > -ERANGE on its first call, which reduces the eccbytes variable above to
> > zero.
>
> I will do what I can, but I am out of my element with this mtd and nand stuff.
>
> I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> called.
>
> I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> what's being defined for section and ecc.steps.
>
> [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> [ 2.684844] writesize 2048, step_size 512, nsteps 4
> [ 2.689910] strength 8, step size 512, code_size 13
> [ 2.694824] nand->ecc.ctx.total = 52
> [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
>
> omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> which appears to be the case here.
>
> Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
>
> [ 2.707031] count eccbytes 0
> [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> [ 2.715820] Invalid ECC layout
> [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> [ 2.738983] 8<--- cut here ---
>
> >
> > What is strange is that, the only reason this would happen (to my eyes)
> > is nand->ecc.ctx.total being 0. Can you please check its effective
> > value?
>
> [ 2.694824] nand->ecc.ctx.total = 52
>
> >
> > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > nsteps (4) * code_size (13) right before calling
> > mtd_ooblayout_count_eccbytes().
> >
> > Can you please verify my sayings and perhaps tackle the root cause of
> > this issue? Please do not hesitate to ask questions, I'll do my best to
> > help because this is a critical section that is not only breaking
> > OMAP boards, unfortunately.
I appear to have the NAND flash working with the following patch:
@@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
nand->ecc.ctx.priv = engine_conf;
nand->ecc.ctx.total = nsteps * code_size;
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ chip->ecc.steps = nsteps;
+ chip->ecc.size = conf->step_size;
I am guessing it's not exactly what you want, but appears that the
ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
when omap_sw_ooblayout_ecc() was called, those fields were blank.
If you have a suggestion on how you want this implemented, I can push a patch.
adam
> >
> > Thanks,
> > Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-15 16:06 ` Adam Ford
@ 2021-01-15 16:17 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-15 16:17 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Fri, 15 Jan 2021 10:06:14 -0600:
> On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> > >
> > > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > > 11:20:27 +0100:
> > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > > >
> > > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > > >
> > > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > > regular error code instead.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > > ---
> > > > > > > >
> > > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > > error:
> > > > > > > >
> > > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > > Invalid ECC layout
> > > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > > 8<--- cut here ---
> > > > > > > >
> > > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > > >
> > > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > > for such errors, but sometimes I fail.
> > > > > > >
> > > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > > layout error still exists as of 5.11-RC2.
> > > > > > >
> > > > > > > Ok so let's focus on these.
> > > > > > >
> > > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > > willing to try and test.
> > > > > > >
> > > > > > > Glad to hear that.
> > > > > > >
> > > > > > > Can you share the NAND controller DT node you are using?
> > > > > > >
> > > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > > output?
> > > > > >
> > > > > > Will you have the time to check these soon? I am ready to help and
> > > > > > would like to fix it asap.
> > > > >
> > > > > Sorry for the delay, I have to split my time with 3 different
> > > > > projects. I am hoping to get you data later today.
> > > > >
> > > > Miquel,
> > > >
> > > > Here is the dump from my boot sequence:
> > > >
> > > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > > [ 2.689300] strength 8, step size 512, code_size 13
> > >
> > > Until here, everything looks fine.
> > >
> > > > [ 2.696807] count eccbytes 0
> > >
> > > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> > >
> > > Can you please check that we effectively call the large page helpers
> > > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > > -ERANGE on its first call, which reduces the eccbytes variable above to
> > > zero.
> >
> > I will do what I can, but I am out of my element with this mtd and nand stuff.
> >
> > I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> > not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> > called.
> >
> > I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> > what's being defined for section and ecc.steps.
> >
> > [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> > [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> > node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> > [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> > [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> > 2048, OOB size: 64
> > [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > [ 2.684844] writesize 2048, step_size 512, nsteps 4
> > [ 2.689910] strength 8, step size 512, code_size 13
> > [ 2.694824] nand->ecc.ctx.total = 52
> > [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> >
> > omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> > which appears to be the case here.
> >
> > Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
> >
> > [ 2.707031] count eccbytes 0
> > [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > [ 2.715820] Invalid ECC layout
> > [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> > [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> > [ 2.738983] 8<--- cut here ---
> >
> > >
> > > What is strange is that, the only reason this would happen (to my eyes)
> > > is nand->ecc.ctx.total being 0. Can you please check its effective
> > > value?
> >
> > [ 2.694824] nand->ecc.ctx.total = 52
> >
> > >
> > > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > > nsteps (4) * code_size (13) right before calling
> > > mtd_ooblayout_count_eccbytes().
> > >
> > > Can you please verify my sayings and perhaps tackle the root cause of
> > > this issue? Please do not hesitate to ask questions, I'll do my best to
> > > help because this is a critical section that is not only breaking
> > > OMAP boards, unfortunately.
>
> I appear to have the NAND flash working with the following patch:
>
> @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> nand->ecc.ctx.priv = engine_conf;
> nand->ecc.ctx.total = nsteps * code_size;
>
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + chip->ecc.steps = nsteps;
> + chip->ecc.size = conf->step_size;
>
> I am guessing it's not exactly what you want, but appears that the
> ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
> when omap_sw_ooblayout_ecc() was called, those fields were blank.
>
> If you have a suggestion on how you want this implemented, I can push a patch.
Great, I'll check more deeply why is this happening and get back to you
early next week.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-15 16:17 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-15 16:17 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Fri, 15 Jan 2021 10:06:14 -0600:
> On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> > >
> > > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > > 11:20:27 +0100:
> > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > > >
> > > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > > >
> > > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > > regular error code instead.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > > ---
> > > > > > > >
> > > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > > error:
> > > > > > > >
> > > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > > Invalid ECC layout
> > > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > > 8<--- cut here ---
> > > > > > > >
> > > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > > >
> > > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > > for such errors, but sometimes I fail.
> > > > > > >
> > > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > > layout error still exists as of 5.11-RC2.
> > > > > > >
> > > > > > > Ok so let's focus on these.
> > > > > > >
> > > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > > willing to try and test.
> > > > > > >
> > > > > > > Glad to hear that.
> > > > > > >
> > > > > > > Can you share the NAND controller DT node you are using?
> > > > > > >
> > > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > > output?
> > > > > >
> > > > > > Will you have the time to check these soon? I am ready to help and
> > > > > > would like to fix it asap.
> > > > >
> > > > > Sorry for the delay, I have to split my time with 3 different
> > > > > projects. I am hoping to get you data later today.
> > > > >
> > > > Miquel,
> > > >
> > > > Here is the dump from my boot sequence:
> > > >
> > > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > > [ 2.689300] strength 8, step size 512, code_size 13
> > >
> > > Until here, everything looks fine.
> > >
> > > > [ 2.696807] count eccbytes 0
> > >
> > > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> > >
> > > Can you please check that we effectively call the large page helpers
> > > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > > -ERANGE on its first call, which reduces the eccbytes variable above to
> > > zero.
> >
> > I will do what I can, but I am out of my element with this mtd and nand stuff.
> >
> > I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> > not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> > called.
> >
> > I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> > what's being defined for section and ecc.steps.
> >
> > [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> > [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> > node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> > [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> > [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> > 2048, OOB size: 64
> > [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > [ 2.684844] writesize 2048, step_size 512, nsteps 4
> > [ 2.689910] strength 8, step size 512, code_size 13
> > [ 2.694824] nand->ecc.ctx.total = 52
> > [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> >
> > omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> > which appears to be the case here.
> >
> > Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
> >
> > [ 2.707031] count eccbytes 0
> > [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > [ 2.715820] Invalid ECC layout
> > [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> > [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> > [ 2.738983] 8<--- cut here ---
> >
> > >
> > > What is strange is that, the only reason this would happen (to my eyes)
> > > is nand->ecc.ctx.total being 0. Can you please check its effective
> > > value?
> >
> > [ 2.694824] nand->ecc.ctx.total = 52
> >
> > >
> > > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > > nsteps (4) * code_size (13) right before calling
> > > mtd_ooblayout_count_eccbytes().
> > >
> > > Can you please verify my sayings and perhaps tackle the root cause of
> > > this issue? Please do not hesitate to ask questions, I'll do my best to
> > > help because this is a critical section that is not only breaking
> > > OMAP boards, unfortunately.
>
> I appear to have the NAND flash working with the following patch:
>
> @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> nand->ecc.ctx.priv = engine_conf;
> nand->ecc.ctx.total = nsteps * code_size;
>
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + chip->ecc.steps = nsteps;
> + chip->ecc.size = conf->step_size;
>
> I am guessing it's not exactly what you want, but appears that the
> ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
> when omap_sw_ooblayout_ecc() was called, those fields were blank.
>
> If you have a suggestion on how you want this implemented, I can push a patch.
Great, I'll check more deeply why is this happening and get back to you
early next week.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-15 16:17 ` Miquel Raynal
@ 2021-01-15 16:28 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 16:28 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Fri, Jan 15, 2021 at 10:17 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Fri, 15 Jan 2021 10:06:14 -0600:
>
> > On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> > > >
> > > > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > > > 11:20:27 +0100:
> > > > > > >
> > > > > > > > Hi Adam,
> > > > > > > >
> > > > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > > > >
> > > > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > > > >
> > > > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > > > regular error code instead.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > > > error:
> > > > > > > > >
> > > > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > > > Invalid ECC layout
> > > > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > > > 8<--- cut here ---
> > > > > > > > >
> > > > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > > > >
> > > > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > > > for such errors, but sometimes I fail.
> > > > > > > >
> > > > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > > > layout error still exists as of 5.11-RC2.
> > > > > > > >
> > > > > > > > Ok so let's focus on these.
> > > > > > > >
> > > > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > > > willing to try and test.
> > > > > > > >
> > > > > > > > Glad to hear that.
> > > > > > > >
> > > > > > > > Can you share the NAND controller DT node you are using?
> > > > > > > >
> > > > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > > > output?
> > > > > > >
> > > > > > > Will you have the time to check these soon? I am ready to help and
> > > > > > > would like to fix it asap.
> > > > > >
> > > > > > Sorry for the delay, I have to split my time with 3 different
> > > > > > projects. I am hoping to get you data later today.
> > > > > >
> > > > > Miquel,
> > > > >
> > > > > Here is the dump from my boot sequence:
> > > > >
> > > > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > > > [ 2.689300] strength 8, step size 512, code_size 13
> > > >
> > > > Until here, everything looks fine.
> > > >
> > > > > [ 2.696807] count eccbytes 0
> > > >
> > > > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> > > >
> > > > Can you please check that we effectively call the large page helpers
> > > > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > > > -ERANGE on its first call, which reduces the eccbytes variable above to
> > > > zero.
> > >
> > > I will do what I can, but I am out of my element with this mtd and nand stuff.
> > >
> > > I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> > > not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> > > called.
> > >
> > > I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> > > what's being defined for section and ecc.steps.
> > >
> > > [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> > > [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> > > node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > > [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> > > [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> > > [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> > > 2048, OOB size: 64
> > > [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > [ 2.684844] writesize 2048, step_size 512, nsteps 4
> > > [ 2.689910] strength 8, step size 512, code_size 13
> > > [ 2.694824] nand->ecc.ctx.total = 52
> > > [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > >
> > > omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> > > which appears to be the case here.
> > >
> > > Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
> > >
> > > [ 2.707031] count eccbytes 0
> > > [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > > [ 2.715820] Invalid ECC layout
> > > [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> > > [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> > > [ 2.738983] 8<--- cut here ---
> > >
> > > >
> > > > What is strange is that, the only reason this would happen (to my eyes)
> > > > is nand->ecc.ctx.total being 0. Can you please check its effective
> > > > value?
> > >
> > > [ 2.694824] nand->ecc.ctx.total = 52
> > >
> > > >
> > > > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > > > nsteps (4) * code_size (13) right before calling
> > > > mtd_ooblayout_count_eccbytes().
> > > >
> > > > Can you please verify my sayings and perhaps tackle the root cause of
> > > > this issue? Please do not hesitate to ask questions, I'll do my best to
> > > > help because this is a critical section that is not only breaking
> > > > OMAP boards, unfortunately.
> >
> > I appear to have the NAND flash working with the following patch:
> >
> > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > nand->ecc.ctx.priv = engine_conf;
> > nand->ecc.ctx.total = nsteps * code_size;
> >
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + chip->ecc.steps = nsteps;
> > + chip->ecc.size = conf->step_size;
> >
> > I am guessing it's not exactly what you want, but appears that the
> > ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
> > when omap_sw_ooblayout_ecc() was called, those fields were blank.
> >
> > If you have a suggestion on how you want this implemented, I can push a patch.
>
> Great, I'll check more deeply why is this happening and get back to you
> early next week.
Sounds great.
FYI, with my hack, this is my boot log:
[ 2.622100] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.629821] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635986] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642883] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
[ 2.654632] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.661071] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.667633] nand: Micron MT29F4G16ABBDA3W
[ 2.671691] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 2.679443] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684967] writesize 2048, step_size 512, nsteps 4
[ 2.690032] strength 8, step size 512, code_size 13
[ 2.700775] nand->ecc.ctx.total = 52
[ 2.712646] count eccbytes 52
[ 2.715698] mtd->ecc_step_size = 512
[ 2.719482] nand_base: steps = 4, ecc->bytes = 13, ecc->total = 52
[ 2.725769] 6 cmdlinepart partitions found on MTD device omap2-nand.0
[ 2.732391] Creating 6 MTD partitions on "omap2-nand.0":
...
I have not verified being able to read/write and or check data
integrity, but with my hack, it no longer causes a panic on boot.
adam
>
> Thanks,
> Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-15 16:28 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-15 16:28 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Fri, Jan 15, 2021 at 10:17 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Adam Ford <aford173@gmail.com> wrote on Fri, 15 Jan 2021 10:06:14 -0600:
>
> > On Fri, Jan 15, 2021 at 6:23 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Thu, Jan 14, 2021 at 9:42 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > Adam Ford <aford173@gmail.com> wrote on Tue, 12 Jan 2021 11:20:24 -0600:
> > > >
> > > > > On Tue, Jan 12, 2021 at 10:01 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, Jan 12, 2021 at 8:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > Miquel Raynal <miquel.raynal@bootlin.com> wrote on Mon, 11 Jan 2021
> > > > > > > 11:20:27 +0100:
> > > > > > >
> > > > > > > > Hi Adam,
> > > > > > > >
> > > > > > > > Adam Ford <aford173@gmail.com> wrote on Sat, 9 Jan 2021 08:46:44 -0600:
> > > > > > > >
> > > > > > > > > On Tue, Sep 29, 2020 at 6:09 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > > > >
> > > > > > > > > > The NAND BCH control structure has nothing to do outside of this
> > > > > > > > > > driver, all users of the nand_bch_init/free() functions just save it
> > > > > > > > > > to chip->ecc.priv so do it in this driver directly and return a
> > > > > > > > > > regular error code instead.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Starting with this commit: 3c0fe36abebe, the kernel either doesn't
> > > > > > > > > build or returns errors on some omap2plus devices with the following
> > > > > > > > > error:
> > > > > > > > >
> > > > > > > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > > > > > nand: Micron MT29F4G16ABBDA3W
> > > > > > > > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > > > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > > > > > Invalid ECC layout
> > > > > > > > > omap2-nand 30000000.nand: unable to use BCH library
> > > > > > > > > omap2-nand: probe of 30000000.nand failed with error -22
> > > > > > > > > 8<--- cut here ---
> > > > > > > > >
> > > > > > > > > There are few commits using git bisect that have build errors, so it
> > > > > > > > > wasn't possible for me to determine the exact commit that broke the
> > > > > > > > > ECC. If the build failed, I marked it as 'bad' to git bisect.
> > > > > > > >
> > > > > > > > I am sorry to hear that, I regularly rebase with a make run between each
> > > > > > > > pick and push my branches to a 0-day repository to have robots check
> > > > > > > > for such errors, but sometimes I fail.
> > > > > > > >
> > > > > > > > > Newer commits have remedied the build issue, but the Invalid ECC
> > > > > > > > > layout error still exists as of 5.11-RC2.
> > > > > > > >
> > > > > > > > Ok so let's focus on these.
> > > > > > > >
> > > > > > > > > Do you have any suggestions on what I can do to remedy this? I am
> > > > > > > > > willing to try and test.
> > > > > > > >
> > > > > > > > Glad to hear that.
> > > > > > > >
> > > > > > > > Can you share the NAND controller DT node you are using?
> > > > > > > >
> > > > > > > > Also, can you please add a few printk's like below and give me the
> > > > > > > > output?
> > > > > > >
> > > > > > > Will you have the time to check these soon? I am ready to help and
> > > > > > > would like to fix it asap.
> > > > > >
> > > > > > Sorry for the delay, I have to split my time with 3 different
> > > > > > projects. I am hoping to get you data later today.
> > > > > >
> > > > > Miquel,
> > > > >
> > > > > Here is the dump from my boot sequence:
> > > > >
> > > > > [ 2.629089] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > > > [ 2.635253] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > > > [ 2.642150] of_get_named_gpiod_flags: parsed 'rb-gpios' property of node '/o)
> > > > > [ 2.653900] gpio gpiochip6: Persistence not supported for GPIO 0
> > > > > [ 2.660339] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > > > [ 2.666900] nand: Micron MT29F4G16ABBDA3W
> > > > > [ 2.670959] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB si4
> > > > > [ 2.678710] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > > > [ 2.684234] writesize 2048, step_size 512, nsteps 4
> > > > > [ 2.689300] strength 8, step size 512, code_size 13
> > > >
> > > > Until here, everything looks fine.
> > > >
> > > > > [ 2.696807] count eccbytes 0
> > > >
> > > > This is the cause of the error, the MTD OOB layout reports not ECC byte.
> > > >
> > > > Can you please check that we effectively call the large page helpers
> > > > (in particular nand_ooblayout_ecc_lp()) . I bet this function returns
> > > > -ERANGE on its first call, which reduces the eccbytes variable above to
> > > > zero.
> > >
> > > I will do what I can, but I am out of my element with this mtd and nand stuff.
> > >
> > > I added a printk to the beginning of nand_ooblayout_ecc_lp() and it's
> > > not appearing, so I wonder if nand_ooblayout_ecc_lp() is not getting
> > > called.
> > >
> > > I also added some printk's to the drivers/mtd/nand/raw/omap2.c to see
> > > what's being defined for section and ecc.steps.
> > >
> > > [ 2.621978] mtdoops: mtd device (mtddev=name/number) must be supplied
> > > [ 2.629699] omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > [ 2.635864] omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > [ 2.642761] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
> > > node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > > [ 2.654510] gpio gpiochip6: Persistence not supported for GPIO 0
> > > [ 2.660949] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > [ 2.667510] nand: Micron MT29F4G16ABBDA3W
> > > [ 2.671569] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
> > > 2048, OOB size: 64
> > > [ 2.679321] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > [ 2.684844] writesize 2048, step_size 512, nsteps 4
> > > [ 2.689910] strength 8, step size 512, code_size 13
> > > [ 2.694824] nand->ecc.ctx.total = 52
> > > [ 2.700988] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > >
> > > omap_sw_ooblayout_ecc() returns -ERANGE if section => chip->ecc.steps
> > > which appears to be the case here.
> > >
> > > Is it safe to assume that ecc.steps should be 4 if nsteps is 4?
> > >
> > > [ 2.707031] count eccbytes 0
> > > [ 2.709930] omap_sw_ooblayout_ecc section 0, chip->ecc.steps 0
> > > [ 2.715820] Invalid ECC layout
> > > [ 2.719055] omap2-nand 30000000.nand: unable to use BCH library
> > > [ 2.725067] omap2-nand: probe of 30000000.nand failed with error -22
> > > [ 2.738983] 8<--- cut here ---
> > >
> > > >
> > > > What is strange is that, the only reason this would happen (to my eyes)
> > > > is nand->ecc.ctx.total being 0. Can you please check its effective
> > > > value?
> > >
> > > [ 2.694824] nand->ecc.ctx.total = 52
> > >
> > > >
> > > > I do not see the immediate reason because nand->ecc.ctx.total is set to
> > > > nsteps (4) * code_size (13) right before calling
> > > > mtd_ooblayout_count_eccbytes().
> > > >
> > > > Can you please verify my sayings and perhaps tackle the root cause of
> > > > this issue? Please do not hesitate to ask questions, I'll do my best to
> > > > help because this is a critical section that is not only breaking
> > > > OMAP boards, unfortunately.
> >
> > I appear to have the NAND flash working with the following patch:
> >
> > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > nand->ecc.ctx.priv = engine_conf;
> > nand->ecc.ctx.total = nsteps * code_size;
> >
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + chip->ecc.steps = nsteps;
> > + chip->ecc.size = conf->step_size;
> >
> > I am guessing it's not exactly what you want, but appears that the
> > ecc.steps and ecc.size wasn't getting propagated to the mtd layer, so
> > when omap_sw_ooblayout_ecc() was called, those fields were blank.
> >
> > If you have a suggestion on how you want this implemented, I can push a patch.
>
> Great, I'll check more deeply why is this happening and get back to you
> early next week.
Sounds great.
FYI, with my hack, this is my boot log:
[ 2.622100] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 2.629821] omap2-nand 30000000.nand: GPIO lookup for consumer rb
[ 2.635986] omap2-nand 30000000.nand: using device tree for GPIO lookup
[ 2.642883] of_get_named_gpiod_flags: parsed 'rb-gpios' property of
node '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
[ 2.654632] gpio gpiochip6: Persistence not supported for GPIO 0
[ 2.661071] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
[ 2.667633] nand: Micron MT29F4G16ABBDA3W
[ 2.671691] nand: 512 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 2.679443] nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
[ 2.684967] writesize 2048, step_size 512, nsteps 4
[ 2.690032] strength 8, step size 512, code_size 13
[ 2.700775] nand->ecc.ctx.total = 52
[ 2.712646] count eccbytes 52
[ 2.715698] mtd->ecc_step_size = 512
[ 2.719482] nand_base: steps = 4, ecc->bytes = 13, ecc->total = 52
[ 2.725769] 6 cmdlinepart partitions found on MTD device omap2-nand.0
[ 2.732391] Creating 6 MTD partitions on "omap2-nand.0":
...
I have not verified being able to read/write and or check data
integrity, but with my hack, it no longer causes a panic on boot.
adam
>
> Thanks,
> Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-15 16:28 ` Adam Ford
@ 2021-01-19 11:56 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 11:56 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Thank you very much for troubleshooting this, here is my proposal.
> > > I appear to have the NAND flash working with the following patch:
> > >
> > > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > > nand->ecc.ctx.priv = engine_conf;
> > > nand->ecc.ctx.total = nsteps * code_size;
> > >
> > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > + chip->ecc.steps = nsteps;
> > > + chip->ecc.size = conf->step_size;
I was fearing that many boards would be affected by this issue but it
appears that the problem will only show up here because the OMAP driver
makes a strange use of the BCH library: it initializes it itself
because it only needs it for a single operation while usually, the core
is in charge of doing that. During the initialization, the OOB layout
is verified. Usually, the BCH driver is used with one of the generic OOB
layouts, while here the OMAP driver uses its own, which reads raw NAND
chip entries.
I recently moved the BCH driver to only use "generic" NAND bits, which
produced the bug because the entries derived by the layout helpers
have not been updated yet.
So using raw NAND bits in the BCH driver is not an option here.
Instead, I think the best way to address this is to export the
declaration of the BCH internal configuration structure to the OMAP
driver and use the right values, recently derived by the driver:
---8<---
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Tue Jan 19 12:27:07 2021 +0100
wip: fix omap
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index fbb9955f2467..2c3e65cb68f3 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -15,6 +15,7 @@
#include <linux/jiffies.h>
#include <linux/sched.h>
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/omap-dma.h>
@@ -1866,18 +1867,19 @@ 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);
+ const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
int off = BADBLOCK_MARKER_LENGTH;
- if (section >= chip->ecc.steps)
+ if (section >= engine_conf->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 * (engine_conf->code_size + 1));
+ oobregion->length = engine_conf->code_size;
return 0;
}
@@ -1885,7 +1887,8 @@ 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);
+ const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
int off = BADBLOCK_MARKER_LENGTH;
if (section)
@@ -1895,7 +1898,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 += ((engine_conf->code_size + 1) * engine_conf->nsteps);
if (off >= mtd->oobsize)
return -ERANGE;
--->8---
Can you please try this patch and compare the values between your hack
and mine of:
- chip->ecc.bytes vs. engine_conf->code_size
- chip->ecc.steps vs. engine_conf->nsteps
The values should be the same, but I prefer to be sure.
Thanks,
Miquèl
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-19 11:56 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 11:56 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Thank you very much for troubleshooting this, here is my proposal.
> > > I appear to have the NAND flash working with the following patch:
> > >
> > > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > > nand->ecc.ctx.priv = engine_conf;
> > > nand->ecc.ctx.total = nsteps * code_size;
> > >
> > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > + chip->ecc.steps = nsteps;
> > > + chip->ecc.size = conf->step_size;
I was fearing that many boards would be affected by this issue but it
appears that the problem will only show up here because the OMAP driver
makes a strange use of the BCH library: it initializes it itself
because it only needs it for a single operation while usually, the core
is in charge of doing that. During the initialization, the OOB layout
is verified. Usually, the BCH driver is used with one of the generic OOB
layouts, while here the OMAP driver uses its own, which reads raw NAND
chip entries.
I recently moved the BCH driver to only use "generic" NAND bits, which
produced the bug because the entries derived by the layout helpers
have not been updated yet.
So using raw NAND bits in the BCH driver is not an option here.
Instead, I think the best way to address this is to export the
declaration of the BCH internal configuration structure to the OMAP
driver and use the right values, recently derived by the driver:
---8<---
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Tue Jan 19 12:27:07 2021 +0100
wip: fix omap
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index fbb9955f2467..2c3e65cb68f3 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -15,6 +15,7 @@
#include <linux/jiffies.h>
#include <linux/sched.h>
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/omap-dma.h>
@@ -1866,18 +1867,19 @@ 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);
+ const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
int off = BADBLOCK_MARKER_LENGTH;
- if (section >= chip->ecc.steps)
+ if (section >= engine_conf->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 * (engine_conf->code_size + 1));
+ oobregion->length = engine_conf->code_size;
return 0;
}
@@ -1885,7 +1887,8 @@ 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);
+ const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
int off = BADBLOCK_MARKER_LENGTH;
if (section)
@@ -1895,7 +1898,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 += ((engine_conf->code_size + 1) * engine_conf->nsteps);
if (off >= mtd->oobsize)
return -ERANGE;
--->8---
Can you please try this patch and compare the values between your hack
and mine of:
- chip->ecc.bytes vs. engine_conf->code_size
- chip->ecc.steps vs. engine_conf->nsteps
The values should be the same, but I prefer to be sure.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-19 11:56 ` Miquel Raynal
@ 2021-01-19 14:21 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-19 14:21 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Tue, Jan 19, 2021 at 5:56 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Thank you very much for troubleshooting this, here is my proposal.
>
> > > > I appear to have the NAND flash working with the following patch:
> > > >
> > > > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > > > nand->ecc.ctx.priv = engine_conf;
> > > > nand->ecc.ctx.total = nsteps * code_size;
> > > >
> > > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > > + chip->ecc.steps = nsteps;
> > > > + chip->ecc.size = conf->step_size;
>
> I was fearing that many boards would be affected by this issue but it
> appears that the problem will only show up here because the OMAP driver
> makes a strange use of the BCH library: it initializes it itself
> because it only needs it for a single operation while usually, the core
> is in charge of doing that. During the initialization, the OOB layout
> is verified. Usually, the BCH driver is used with one of the generic OOB
> layouts, while here the OMAP driver uses its own, which reads raw NAND
> chip entries.
>
> I recently moved the BCH driver to only use "generic" NAND bits, which
> produced the bug because the entries derived by the layout helpers
> have not been updated yet.
>
> So using raw NAND bits in the BCH driver is not an option here.
> Instead, I think the best way to address this is to export the
> declaration of the BCH internal configuration structure to the OMAP
> driver and use the right values, recently derived by the driver:
>
> ---8<---
>
> Author: Miquel Raynal <miquel.raynal@bootlin.com>
> Date: Tue Jan 19 12:27:07 2021 +0100
>
> wip: fix omap
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
Thanks for fixing this.
I tested your patch, and I no longer get a Panic and the MTD device
appears to appear correctly:
mtdoops: mtd device (mtddev=name/number) must be supplied
omap2-nand 30000000.nand: GPIO lookup for consumer rb
omap2-nand 30000000.nand: using device tree for GPIO lookup
of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
'/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
gpio gpiochip6: Persistence not supported for GPIO 0
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
nand: Micron MT29F4G16ABBDA3W
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
6 cmdlinepart partitions found on MTD device omap2-nand.0
Creating 6 MTD partitions on "omap2-nand.0":
...
When you submit a formal patch, CC me on the patch, and I'll respond
with a 'tested-by'
adam
> diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
> index fbb9955f2467..2c3e65cb68f3 100644
> --- a/drivers/mtd/nand/raw/omap2.c
> +++ b/drivers/mtd/nand/raw/omap2.c
> @@ -15,6 +15,7 @@
> #include <linux/jiffies.h>
> #include <linux/sched.h>
> #include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand-ecc-sw-bch.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> #include <linux/omap-dma.h>
> @@ -1866,18 +1867,19 @@ 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);
> + const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
> int off = BADBLOCK_MARKER_LENGTH;
>
> - if (section >= chip->ecc.steps)
> + if (section >= engine_conf->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 * (engine_conf->code_size + 1));
> + oobregion->length = engine_conf->code_size;
>
> return 0;
> }
> @@ -1885,7 +1887,8 @@ 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);
> + const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
> int off = BADBLOCK_MARKER_LENGTH;
>
> if (section)
> @@ -1895,7 +1898,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 += ((engine_conf->code_size + 1) * engine_conf->nsteps);
> if (off >= mtd->oobsize)
> return -ERANGE;
>
> --->8---
>
> Can you please try this patch and compare the values between your hack
> and mine of:
> - chip->ecc.bytes vs. engine_conf->code_size
> - chip->ecc.steps vs. engine_conf->nsteps
> The values should be the same, but I prefer to be sure.
>
> Thanks,
> Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-19 14:21 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-19 14:21 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Tue, Jan 19, 2021 at 5:56 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> Thank you very much for troubleshooting this, here is my proposal.
>
> > > > I appear to have the NAND flash working with the following patch:
> > > >
> > > > @@ -247,11 +253,21 @@ int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
> > > > nand->ecc.ctx.priv = engine_conf;
> > > > nand->ecc.ctx.total = nsteps * code_size;
> > > >
> > > > + struct nand_chip *chip = mtd_to_nand(mtd);
> > > > + chip->ecc.steps = nsteps;
> > > > + chip->ecc.size = conf->step_size;
>
> I was fearing that many boards would be affected by this issue but it
> appears that the problem will only show up here because the OMAP driver
> makes a strange use of the BCH library: it initializes it itself
> because it only needs it for a single operation while usually, the core
> is in charge of doing that. During the initialization, the OOB layout
> is verified. Usually, the BCH driver is used with one of the generic OOB
> layouts, while here the OMAP driver uses its own, which reads raw NAND
> chip entries.
>
> I recently moved the BCH driver to only use "generic" NAND bits, which
> produced the bug because the entries derived by the layout helpers
> have not been updated yet.
>
> So using raw NAND bits in the BCH driver is not an option here.
> Instead, I think the best way to address this is to export the
> declaration of the BCH internal configuration structure to the OMAP
> driver and use the right values, recently derived by the driver:
>
> ---8<---
>
> Author: Miquel Raynal <miquel.raynal@bootlin.com>
> Date: Tue Jan 19 12:27:07 2021 +0100
>
> wip: fix omap
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
Thanks for fixing this.
I tested your patch, and I no longer get a Panic and the MTD device
appears to appear correctly:
mtdoops: mtd device (mtddev=name/number) must be supplied
omap2-nand 30000000.nand: GPIO lookup for consumer rb
omap2-nand 30000000.nand: using device tree for GPIO lookup
of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
'/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
gpio gpiochip6: Persistence not supported for GPIO 0
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
nand: Micron MT29F4G16ABBDA3W
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
6 cmdlinepart partitions found on MTD device omap2-nand.0
Creating 6 MTD partitions on "omap2-nand.0":
...
When you submit a formal patch, CC me on the patch, and I'll respond
with a 'tested-by'
adam
> diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
> index fbb9955f2467..2c3e65cb68f3 100644
> --- a/drivers/mtd/nand/raw/omap2.c
> +++ b/drivers/mtd/nand/raw/omap2.c
> @@ -15,6 +15,7 @@
> #include <linux/jiffies.h>
> #include <linux/sched.h>
> #include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand-ecc-sw-bch.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> #include <linux/omap-dma.h>
> @@ -1866,18 +1867,19 @@ 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);
> + const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
> int off = BADBLOCK_MARKER_LENGTH;
>
> - if (section >= chip->ecc.steps)
> + if (section >= engine_conf->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 * (engine_conf->code_size + 1));
> + oobregion->length = engine_conf->code_size;
>
> return 0;
> }
> @@ -1885,7 +1887,8 @@ 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);
> + const struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
> int off = BADBLOCK_MARKER_LENGTH;
>
> if (section)
> @@ -1895,7 +1898,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 += ((engine_conf->code_size + 1) * engine_conf->nsteps);
> if (off >= mtd->oobsize)
> return -ERANGE;
>
> --->8---
>
> Can you please try this patch and compare the values between your hack
> and mine of:
> - chip->ecc.bytes vs. engine_conf->code_size
> - chip->ecc.steps vs. engine_conf->nsteps
> The values should be the same, but I prefer to be sure.
>
> Thanks,
> Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-19 14:21 ` Adam Ford
@ 2021-01-19 14:36 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 14:36 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
> > ---8<---
> >
> > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > Date: Tue Jan 19 12:27:07 2021 +0100
> >
> > wip: fix omap
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >
> Thanks for fixing this.
>
> I tested your patch, and I no longer get a Panic and the MTD device
> appears to appear correctly:
>
> mtdoops: mtd device (mtddev=name/number) must be supplied
> omap2-nand 30000000.nand: GPIO lookup for consumer rb
> omap2-nand 30000000.nand: using device tree for GPIO lookup
> of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> gpio gpiochip6: Persistence not supported for GPIO 0
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> nand: Micron MT29F4G16ABBDA3W
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> 6 cmdlinepart partitions found on MTD device omap2-nand.0
> Creating 6 MTD partitions on "omap2-nand.0":
> ...
Good to know. Can you just tell me if the values of
- chip->ecc.bytes vs. engine_conf->code_size
- chip->ecc.steps vs. engine_conf->nsteps
are the same in both cases (your patch and mine)? Otherwise your data
might appear corrupted somehow.
>
> When you submit a formal patch, CC me on the patch, and I'll respond
> with a 'tested-by'
Of course, I'll also add a Reported-by.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-19 14:36 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 14:36 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
> > ---8<---
> >
> > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > Date: Tue Jan 19 12:27:07 2021 +0100
> >
> > wip: fix omap
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >
> Thanks for fixing this.
>
> I tested your patch, and I no longer get a Panic and the MTD device
> appears to appear correctly:
>
> mtdoops: mtd device (mtddev=name/number) must be supplied
> omap2-nand 30000000.nand: GPIO lookup for consumer rb
> omap2-nand 30000000.nand: using device tree for GPIO lookup
> of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> gpio gpiochip6: Persistence not supported for GPIO 0
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> nand: Micron MT29F4G16ABBDA3W
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> 6 cmdlinepart partitions found on MTD device omap2-nand.0
> Creating 6 MTD partitions on "omap2-nand.0":
> ...
Good to know. Can you just tell me if the values of
- chip->ecc.bytes vs. engine_conf->code_size
- chip->ecc.steps vs. engine_conf->nsteps
are the same in both cases (your patch and mine)? Otherwise your data
might appear corrupted somehow.
>
> When you submit a formal patch, CC me on the patch, and I'll respond
> with a 'tested-by'
Of course, I'll also add a Reported-by.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-19 14:36 ` Miquel Raynal
@ 2021-01-19 15:49 ` Adam Ford
-1 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-19 15:49 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
On Tue, Jan 19, 2021 at 8:36 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> > > ---8<---
> > >
> > > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > > Date: Tue Jan 19 12:27:07 2021 +0100
> > >
> > > wip: fix omap
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > >
> > Thanks for fixing this.
> >
> > I tested your patch, and I no longer get a Panic and the MTD device
> > appears to appear correctly:
> >
> > mtdoops: mtd device (mtddev=name/number) must be supplied
> > omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > omap2-nand 30000000.nand: using device tree for GPIO lookup
> > of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> > '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > gpio gpiochip6: Persistence not supported for GPIO 0
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > nand: Micron MT29F4G16ABBDA3W
> > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > 6 cmdlinepart partitions found on MTD device omap2-nand.0
> > Creating 6 MTD partitions on "omap2-nand.0":
> > ...
>
> Good to know. Can you just tell me if the values of
> - chip->ecc.bytes vs. engine_conf->code_size
> - chip->ecc.steps vs. engine_conf->nsteps
> are the same in both cases (your patch and mine)? Otherwise your data
> might appear corrupted somehow.
I didn't fully vet my hack, beyond eliminating the Kernel panic, so I
felt more comfortable comparing the values to a stable release.
I compared the values in 5.10 to 5.11-rc4 + your patch, and the number
of steps and oobregion->length are identical between them.
5.10.5:
chip->ecc.steps = 4
oobregion->length = d
5.11-rc4 + patch:
engine_conf->nsteps = 4
oobregion->length = d
adam
>
> >
> > When you submit a formal patch, CC me on the patch, and I'll respond
> > with a 'tested-by'
>
> Of course, I'll also add a Reported-by.
>
> Thanks,
> Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-19 15:49 ` Adam Ford
0 siblings, 0 replies; 69+ messages in thread
From: Adam Ford @ 2021-01-19 15:49 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
On Tue, Jan 19, 2021 at 8:36 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Adam,
>
> > > ---8<---
> > >
> > > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > > Date: Tue Jan 19 12:27:07 2021 +0100
> > >
> > > wip: fix omap
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > >
> > Thanks for fixing this.
> >
> > I tested your patch, and I no longer get a Panic and the MTD device
> > appears to appear correctly:
> >
> > mtdoops: mtd device (mtddev=name/number) must be supplied
> > omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > omap2-nand 30000000.nand: using device tree for GPIO lookup
> > of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> > '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > gpio gpiochip6: Persistence not supported for GPIO 0
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > nand: Micron MT29F4G16ABBDA3W
> > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > 6 cmdlinepart partitions found on MTD device omap2-nand.0
> > Creating 6 MTD partitions on "omap2-nand.0":
> > ...
>
> Good to know. Can you just tell me if the values of
> - chip->ecc.bytes vs. engine_conf->code_size
> - chip->ecc.steps vs. engine_conf->nsteps
> are the same in both cases (your patch and mine)? Otherwise your data
> might appear corrupted somehow.
I didn't fully vet my hack, beyond eliminating the Kernel panic, so I
felt more comfortable comparing the values to a stable release.
I compared the values in 5.10 to 5.11-rc4 + your patch, and the number
of steps and oobregion->length are identical between them.
5.10.5:
chip->ecc.steps = 4
oobregion->length = d
5.11-rc4 + patch:
engine_conf->nsteps = 4
oobregion->length = d
adam
>
> >
> > When you submit a formal patch, CC me on the patch, and I'll respond
> > with a 'tested-by'
>
> Of course, I'll also add a Reported-by.
>
> Thanks,
> Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
2021-01-19 15:49 ` Adam Ford
@ 2021-01-19 15:53 ` Miquel Raynal
-1 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 15:53 UTC (permalink / raw)
To: Adam Ford
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus,
linux-mtd, Julien Su, ycllin, Thomas Petazzoni, Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Tue, 19 Jan 2021 09:49:36 -0600:
> On Tue, Jan 19, 2021 at 8:36 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > > > ---8<---
> > > >
> > > > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > Date: Tue Jan 19 12:27:07 2021 +0100
> > > >
> > > > wip: fix omap
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > >
> > > Thanks for fixing this.
> > >
> > > I tested your patch, and I no longer get a Panic and the MTD device
> > > appears to appear correctly:
> > >
> > > mtdoops: mtd device (mtddev=name/number) must be supplied
> > > omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> > > '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > > gpio gpiochip6: Persistence not supported for GPIO 0
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > nand: Micron MT29F4G16ABBDA3W
> > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > 6 cmdlinepart partitions found on MTD device omap2-nand.0
> > > Creating 6 MTD partitions on "omap2-nand.0":
> > > ...
> >
> > Good to know. Can you just tell me if the values of
> > - chip->ecc.bytes vs. engine_conf->code_size
> > - chip->ecc.steps vs. engine_conf->nsteps
> > are the same in both cases (your patch and mine)? Otherwise your data
> > might appear corrupted somehow.
>
> I didn't fully vet my hack, beyond eliminating the Kernel panic, so I
> felt more comfortable comparing the values to a stable release.
> I compared the values in 5.10 to 5.11-rc4 + your patch, and the number
> of steps and oobregion->length are identical between them.
>
> 5.10.5:
> chip->ecc.steps = 4
> oobregion->length = d
>
> 5.11-rc4 + patch:
> engine_conf->nsteps = 4
> oobregion->length = d
Great, thanks for checking.
I'll send the formal patch then.
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure
@ 2021-01-19 15:53 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2021-01-19 15:53 UTC (permalink / raw)
To: Adam Ford
Cc: Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, ycllin, linux-mtd, Thomas Petazzoni,
Linux-OMAP
Hi Adam,
Adam Ford <aford173@gmail.com> wrote on Tue, 19 Jan 2021 09:49:36 -0600:
> On Tue, Jan 19, 2021 at 8:36 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Adam,
> >
> > > > ---8<---
> > > >
> > > > Author: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > Date: Tue Jan 19 12:27:07 2021 +0100
> > > >
> > > > wip: fix omap
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > >
> > > Thanks for fixing this.
> > >
> > > I tested your patch, and I no longer get a Panic and the MTD device
> > > appears to appear correctly:
> > >
> > > mtdoops: mtd device (mtddev=name/number) must be supplied
> > > omap2-nand 30000000.nand: GPIO lookup for consumer rb
> > > omap2-nand 30000000.nand: using device tree for GPIO lookup
> > > of_get_named_gpiod_flags: parsed 'rb-gpios' property of node
> > > '/ocp@68000000/gpmc@6e000000/nand@0,0[0]' - status (0)
> > > gpio gpiochip6: Persistence not supported for GPIO 0
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
> > > nand: Micron MT29F4G16ABBDA3W
> > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > nand: using OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > > 6 cmdlinepart partitions found on MTD device omap2-nand.0
> > > Creating 6 MTD partitions on "omap2-nand.0":
> > > ...
> >
> > Good to know. Can you just tell me if the values of
> > - chip->ecc.bytes vs. engine_conf->code_size
> > - chip->ecc.steps vs. engine_conf->nsteps
> > are the same in both cases (your patch and mine)? Otherwise your data
> > might appear corrupted somehow.
>
> I didn't fully vet my hack, beyond eliminating the Kernel panic, so I
> felt more comfortable comparing the values to a stable release.
> I compared the values in 5.10 to 5.11-rc4 + your patch, and the number
> of steps and oobregion->length are identical between them.
>
> 5.10.5:
> chip->ecc.steps = 4
> oobregion->length = d
>
> 5.11-rc4 + patch:
> engine_conf->nsteps = 4
> oobregion->length = d
Great, thanks for checking.
I'll send the formal patch then.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 05/20] mtd: nand: ecc-bch: Return only valid error codes
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (3 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 04/20] mtd: nand: ecc-bch: Stop exporting the private structure Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 06/20] mtd: nand: ecc-bch: Drop mtd_nand_has_bch() Miquel Raynal
` (14 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
When a function is not available, returning -ENOTSUPP makes much more
sense than returning -1.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
include/linux/mtd/nand-ecc-sw-bch.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index b62b8bd4669f..d92d2abcfcef 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -43,7 +43,7 @@ static inline int
nand_bch_calculate_ecc(struct nand_chip *chip, const u_char *dat,
u_char *ecc_code)
{
- return -1;
+ return -ENOTSUPP;
}
static inline int
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 05/20] mtd: nand: ecc-bch: Return only valid error codes
2020-09-29 23:01 ` [PATCH 05/20] mtd: nand: ecc-bch: Return only valid error codes Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:09 UTC, Miquel Raynal wrote:
> When a function is not available, returning -ENOTSUPP makes much more
> sense than returning -1.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 06/20] mtd: nand: ecc-bch: Drop mtd_nand_has_bch()
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (4 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 05/20] mtd: nand: ecc-bch: Return only valid error codes Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 07/20] mtd: nand: ecc-bch: Update the prototypes to be more generic Miquel Raynal
` (13 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Like for any other compilation option, use the IS_ENABLED() macro
instead of hardcoding it.
By droping this helper we can get rid of the BCH header in nandsim.c.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/nand_base.c | 2 +-
drivers/mtd/nand/raw/nandsim.c | 3 +--
include/linux/mtd/nand-ecc-sw-bch.h | 4 ----
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index c47441ddc5cf..a6b6ab26a22a 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5236,7 +5236,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
return 0;
case NAND_ECC_ALGO_BCH:
- if (!mtd_nand_has_bch()) {
+ if (!IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)) {
WARN(1, "CONFIG_MTD_NAND_ECC_SW_BCH not enabled\n");
return -EINVAL;
}
diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
index 9c940ead66fd..f2b9250c0ea8 100644
--- a/drivers/mtd/nand/raw/nandsim.c
+++ b/drivers/mtd/nand/raw/nandsim.c
@@ -23,7 +23,6 @@
#include <linux/string.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/mtd/partitions.h>
#include <linux/delay.h>
#include <linux/list.h>
@@ -2214,7 +2213,7 @@ static int ns_attach_chip(struct nand_chip *chip)
if (!bch)
return 0;
- if (!mtd_nand_has_bch()) {
+ if (!IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)) {
NS_ERR("BCH ECC support is disabled\n");
return -EINVAL;
}
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index d92d2abcfcef..7b62996d9e01 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -13,8 +13,6 @@ struct nand_chip;
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
-static inline int mtd_nand_has_bch(void) { return 1; }
-
/*
* Calculate BCH ecc code
*/
@@ -37,8 +35,6 @@ void nand_bch_free(struct nand_chip *chip);
#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
-static inline int mtd_nand_has_bch(void) { return 0; }
-
static inline int
nand_bch_calculate_ecc(struct nand_chip *chip, const u_char *dat,
u_char *ecc_code)
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 06/20] mtd: nand: ecc-bch: Drop mtd_nand_has_bch()
2020-09-29 23:01 ` [PATCH 06/20] mtd: nand: ecc-bch: Drop mtd_nand_has_bch() Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:10 UTC, Miquel Raynal wrote:
> Like for any other compilation option, use the IS_ENABLED() macro
> instead of hardcoding it.
>
> By droping this helper we can get rid of the BCH header in nandsim.c.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 07/20] mtd: nand: ecc-bch: Update the prototypes to be more generic
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (5 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 06/20] mtd: nand: ecc-bch: Drop mtd_nand_has_bch() Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 08/20] mtd: nand: ecc-bch: Stop using raw NAND structures Miquel Raynal
` (12 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
These functions must be usable by the main NAND core, so their names
must be technology-agnostic as well as the parameters. Hence, we pass
a generic nand_device instead of a raw nand_chip structure.
As it seems that changing the raw NAND functions to always pass a
generic NAND device is a lost of time, we prefer to create dedicated
raw NAND wrappers that will be useful in the near future to do the
translation.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-bch.c | 47 +++++++++++++++++------------
drivers/mtd/nand/raw/nand_base.c | 44 ++++++++++++++++++++++++---
drivers/mtd/nand/raw/omap2.c | 23 ++++++--------
include/linux/mtd/nand-ecc-sw-bch.h | 45 ++++++++++-----------------
include/linux/mtd/rawnand.h | 5 +++
5 files changed, 97 insertions(+), 67 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index 97221ec3876e..b9bdfcf46c6d 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -13,6 +13,7 @@
#include <linux/bitops.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/bch.h>
@@ -29,14 +30,15 @@ struct nand_bch_control {
};
/**
- * nand_bch_calcuate_ecc - Calculate the ECC corresponding to a data block
- * @chip: NAND chip object
+ * nand_ecc_sw_bch_calculate - Calculate the ECC corresponding to a data block
+ * @nand: NAND device
* @buf: Input buffer with raw data
* @code: Output buffer with ECC
*/
-int nand_bch_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
- unsigned char *code)
+int nand_ecc_sw_bch_calculate(struct nand_device *nand,
+ const unsigned char *buf, unsigned char *code)
{
+ struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
struct nand_bch_control *nbc = chip->ecc.priv;
unsigned int i;
@@ -49,20 +51,21 @@ int nand_bch_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
return 0;
}
-EXPORT_SYMBOL(nand_bch_calculate_ecc);
+EXPORT_SYMBOL(nand_ecc_sw_bch_calculate);
/**
- * nand_bch_correct_data - Detect, correct and report bit error(s)
- * @chip: NAND chip object
+ * nand_ecc_sw_bch_correct - Detect, correct and report bit error(s)
+ * @nand: NAND device
* @buf: Raw data read from the chip
* @read_ecc: ECC bytes from the chip
* @calc_ecc: ECC calculated from the raw data
*
* Detect and correct bit errors for a data block.
*/
-int nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
- unsigned char *read_ecc, unsigned char *calc_ecc)
+int nand_ecc_sw_bch_correct(struct nand_device *nand, unsigned char *buf,
+ unsigned char *read_ecc, unsigned char *calc_ecc)
{
+ struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
struct nand_bch_control *nbc = chip->ecc.priv;
unsigned int *errloc = nbc->errloc;
int i, count;
@@ -86,11 +89,11 @@ int nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
return count;
}
-EXPORT_SYMBOL(nand_bch_correct_data);
+EXPORT_SYMBOL(nand_ecc_sw_bch_correct);
/**
- * nand_bch_init - Initialize software BCH ECC engine
- * @chip: NAND chip object
+ * nand_ecc_sw_bch_init - Initialize software BCH ECC engine
+ * @nand: NAND device
*
* Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
*
@@ -105,9 +108,10 @@ EXPORT_SYMBOL(nand_bch_correct_data);
* @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
* @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
*/
-int nand_bch_init(struct nand_chip *chip)
+int nand_ecc_sw_bch_init(struct nand_device *nand)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ struct nand_chip *chip = mtd_to_nand(mtd);
unsigned int m, t, eccsteps, i;
struct nand_bch_control *nbc = NULL;
unsigned char *erased_page;
@@ -197,18 +201,21 @@ int nand_bch_init(struct nand_chip *chip)
chip->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
return 0;
+
fail:
- nand_bch_free(chip);
+ nand_ecc_sw_bch_cleanup(nand);
+
return -EINVAL;
}
-EXPORT_SYMBOL(nand_bch_init);
+EXPORT_SYMBOL(nand_ecc_sw_bch_init);
/**
- * nand_bch_free - Release NAND BCH ECC resources
- * @nbc: NAND BCH control structure
+ * nand_ecc_sw_bch_cleanup - Cleanup software BCH ECC resources
+ * @nand: NAND device
*/
-void nand_bch_free(struct nand_chip *chip)
+void nand_ecc_sw_bch_cleanup(struct nand_device *nand)
{
+ struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
struct nand_bch_control *nbc = chip->ecc.priv;
if (nbc) {
@@ -218,7 +225,7 @@ void nand_bch_free(struct nand_chip *chip)
kfree(nbc);
}
}
-EXPORT_SYMBOL(nand_bch_free);
+EXPORT_SYMBOL(nand_ecc_sw_bch_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Ivan Djelic <ivan.djelic@parrot.com>");
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index a6b6ab26a22a..69bdbb1c3b60 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5144,6 +5144,42 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
kfree(chip->parameters.onfi);
}
+int rawnand_sw_bch_init(struct nand_chip *chip)
+{
+ struct nand_device *base = &chip->base;
+
+ return nand_ecc_sw_bch_init(base);
+}
+EXPORT_SYMBOL(rawnand_sw_bch_init);
+
+static int rawnand_sw_bch_calculate(struct nand_chip *chip,
+ const unsigned char *buf,
+ unsigned char *code)
+{
+ struct nand_device *base = &chip->base;
+
+ return nand_ecc_sw_bch_calculate(base, buf, code);
+}
+
+int rawnand_sw_bch_correct(struct nand_chip *chip, unsigned char *buf,
+ unsigned char *read_ecc, unsigned char *calc_ecc)
+{
+ struct nand_device *base = &chip->base;
+
+ return nand_ecc_sw_bch_correct(base, buf, read_ecc, calc_ecc);
+}
+EXPORT_SYMBOL(rawnand_sw_bch_correct);
+
+void rawnand_sw_bch_cleanup(struct nand_chip *chip)
+{
+ struct nand_device *base = &chip->base;
+
+ nand_ecc_sw_bch_cleanup(base);
+
+ chip->ecc.priv = NULL;
+}
+EXPORT_SYMBOL(rawnand_sw_bch_cleanup);
+
static int nand_set_ecc_on_host_ops(struct nand_chip *chip)
{
struct nand_ecc_ctrl *ecc = &chip->ecc;
@@ -5240,8 +5276,8 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
WARN(1, "CONFIG_MTD_NAND_ECC_SW_BCH not enabled\n");
return -EINVAL;
}
- ecc->calculate = nand_bch_calculate_ecc;
- ecc->correct = nand_bch_correct_data;
+ ecc->calculate = rawnand_sw_bch_calculate;
+ ecc->correct = rawnand_sw_bch_correct;
ecc->read_page = nand_read_page_swecc;
ecc->read_subpage = nand_read_subpage;
ecc->write_page = nand_write_page_swecc;
@@ -5297,7 +5333,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
/* See the software BCH ECC initialization for details */
ecc->bytes = 0;
- ret = nand_bch_init(chip);
+ ret = rawnand_sw_bch_init(chip);
if (ret) {
WARN(1, "BCH ECC initialization failed!\n");
return ret;
@@ -5962,7 +5998,7 @@ void nand_cleanup(struct nand_chip *chip)
{
if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
chip->ecc.algo == NAND_ECC_ALGO_BCH)
- nand_bch_free(chip);
+ rawnand_sw_bch_cleanup(chip);
nanddev_cleanup(&chip->base);
diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c
index 6aab57336690..4cc47ab7f01a 100644
--- a/drivers/mtd/nand/raw/omap2.c
+++ b/drivers/mtd/nand/raw/omap2.c
@@ -23,7 +23,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/platform_data/elm.h>
#include <linux/omap-gpmc.h>
@@ -2041,13 +2040,13 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
chip->ecc.bytes = 7;
chip->ecc.strength = 4;
chip->ecc.hwctl = omap_enable_hwecc_bch;
- chip->ecc.correct = nand_bch_correct_data;
+ chip->ecc.correct = rawnand_sw_bch_correct;
chip->ecc.calculate = omap_calculate_ecc_bch_sw;
mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
/* Reserve one byte for the OMAP marker */
oobbytes_per_step = chip->ecc.bytes + 1;
/* Software BCH library is used for locating errors */
- err = nand_bch_init(chip);
+ err = rawnand_sw_bch_init(chip);
if (err) {
dev_err(dev, "Unable to use BCH library\n");
return err;
@@ -2083,13 +2082,13 @@ static int omap_nand_attach_chip(struct nand_chip *chip)
chip->ecc.bytes = 13;
chip->ecc.strength = 8;
chip->ecc.hwctl = omap_enable_hwecc_bch;
- chip->ecc.correct = nand_bch_correct_data;
+ chip->ecc.correct = rawnand_sw_bch_correct;
chip->ecc.calculate = omap_calculate_ecc_bch_sw;
mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
/* Reserve one byte for the OMAP marker */
oobbytes_per_step = chip->ecc.bytes + 1;
/* Software BCH library is used for locating errors */
- err = nand_bch_init(chip);
+ err = rawnand_sw_bch_init(chip);
if (err) {
dev_err(dev, "unable to use BCH library\n");
return err;
@@ -2195,7 +2194,6 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip = &info->nand;
mtd = nand_to_mtd(nand_chip);
mtd->dev.parent = &pdev->dev;
- nand_chip->ecc.priv = NULL;
nand_set_flash_node(nand_chip, dev->of_node);
if (!mtd->name) {
@@ -2271,10 +2269,9 @@ static int omap_nand_probe(struct platform_device *pdev)
return_error:
if (!IS_ERR_OR_NULL(info->dma))
dma_release_channel(info->dma);
- if (nand_chip->ecc.priv) {
- nand_bch_free(nand_chip);
- nand_chip->ecc.priv = NULL;
- }
+
+ rawnand_sw_bch_cleanup(nand_chip);
+
return err;
}
@@ -2285,10 +2282,8 @@ static int omap_nand_remove(struct platform_device *pdev)
struct omap_nand_info *info = mtd_to_omap(mtd);
int ret;
- if (nand_chip->ecc.priv) {
- nand_bch_free(nand_chip);
- nand_chip->ecc.priv = NULL;
- }
+ rawnand_sw_bch_cleanup(nand_chip);
+
if (info->dma)
dma_release_channel(info->dma);
ret = mtd_device_unregister(mtd);
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index 7b62996d9e01..f0caee3b03d0 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -8,53 +8,40 @@
#ifndef __MTD_NAND_ECC_SW_BCH_H__
#define __MTD_NAND_ECC_SW_BCH_H__
-struct mtd_info;
-struct nand_chip;
+#include <linux/mtd/nand.h>
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
-/*
- * Calculate BCH ecc code
- */
-int nand_bch_calculate_ecc(struct nand_chip *chip, const u_char *dat,
- u_char *ecc_code);
-
-/*
- * Detect and correct bit errors
- */
-int nand_bch_correct_data(struct nand_chip *chip, u_char *dat,
- u_char *read_ecc, u_char *calc_ecc);
-/*
- * Initialize BCH encoder/decoder
- */
-int nand_bch_init(struct nand_chip *chip);
-/*
- * Release BCH encoder/decoder resources
- */
-void nand_bch_free(struct nand_chip *chip);
+int nand_ecc_sw_bch_calculate(struct nand_device *nand,
+ const unsigned char *buf, unsigned char *code);
+int nand_ecc_sw_bch_correct(struct nand_device *nand, unsigned char *buf,
+ unsigned char *read_ecc, unsigned char *calc_ecc);
+int nand_ecc_sw_bch_init(struct nand_device *nand);
+void nand_ecc_sw_bch_cleanup(struct nand_device *nand);
#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
-static inline int
-nand_bch_calculate_ecc(struct nand_chip *chip, const u_char *dat,
- u_char *ecc_code)
+static inline int nand_ecc_sw_bch_calculate(struct nand_device *nand,
+ const unsigned char *buf,
+ unsigned char *code)
{
return -ENOTSUPP;
}
-static inline int
-nand_bch_correct_data(struct nand_chip *chip, unsigned char *buf,
- unsigned char *read_ecc, unsigned char *calc_ecc)
+static inline int nand_ecc_sw_bch_correct(struct nand_device *nand,
+ unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc)
{
return -ENOTSUPP;
}
-static inline int nand_bch_init(struct nand_chip *chip)
+static inline int nand_ecc_sw_bch_init(struct nand_device *nand)
{
return -ENOTSUPP;
}
-static inline void nand_bch_free(struct nand_chip *chip) {}
+static inline void nand_ecc_sw_bch_cleanup(struct nand_device *nand) {}
#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index aac07940de09..23623beaad1d 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1303,6 +1303,11 @@ static inline int nand_opcode_8bits(unsigned int command)
return 0;
}
+int rawnand_sw_bch_init(struct nand_chip *chip);
+int rawnand_sw_bch_correct(struct nand_chip *chip, unsigned char *buf,
+ unsigned char *read_ecc, unsigned char *calc_ecc);
+void rawnand_sw_bch_cleanup(struct nand_chip *chip);
+
int nand_check_erased_ecc_chunk(void *data, int datalen,
void *ecc, int ecclen,
void *extraoob, int extraooblen,
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 07/20] mtd: nand: ecc-bch: Update the prototypes to be more generic
2020-09-29 23:01 ` [PATCH 07/20] mtd: nand: ecc-bch: Update the prototypes to be more generic Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:11 UTC, Miquel Raynal wrote:
> These functions must be usable by the main NAND core, so their names
> must be technology-agnostic as well as the parameters. Hence, we pass
> a generic nand_device instead of a raw nand_chip structure.
>
> As it seems that changing the raw NAND functions to always pass a
> generic NAND device is a lost of time, we prefer to create dedicated
> raw NAND wrappers that will be useful in the near future to do the
> translation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 08/20] mtd: nand: ecc-bch: Stop using raw NAND structures
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (6 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 07/20] mtd: nand: ecc-bch: Update the prototypes to be more generic Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 09/20] mtd: nand: ecc-bch: Create the software BCH engine Miquel Raynal
` (11 subsequent siblings)
19 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
This code is meant to be reused by the SPI-NAND core. Now that the
driver has been cleaned and reorganized, use a generic ECC engine
object to store the driver's data instead of accessing members of the
nand_chip structure.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-bch.c | 111 ++++++++++------------------
drivers/mtd/nand/raw/nand_base.c | 38 ++++++++--
include/linux/mtd/nand-ecc-sw-bch.h | 25 +++++++
3 files changed, 97 insertions(+), 77 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index b9bdfcf46c6d..16a54bd2ca31 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -11,23 +11,8 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/bitops.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/rawnand.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/nand-ecc-sw-bch.h>
-#include <linux/bch.h>
-
-/**
- * struct nand_bch_control - private NAND BCH control structure
- * @bch: BCH control structure
- * @errloc: error location array
- * @eccmask: XOR ecc mask, allows erased pages to be decoded as valid
- */
-struct nand_bch_control {
- struct bch_control *bch;
- unsigned int *errloc;
- unsigned char *eccmask;
-};
/**
* nand_ecc_sw_bch_calculate - Calculate the ECC corresponding to a data block
@@ -38,16 +23,15 @@ struct nand_bch_control {
int nand_ecc_sw_bch_calculate(struct nand_device *nand,
const unsigned char *buf, unsigned char *code)
{
- struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
- struct nand_bch_control *nbc = chip->ecc.priv;
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
unsigned int i;
- memset(code, 0, chip->ecc.bytes);
- bch_encode(nbc->bch, buf, chip->ecc.size, code);
+ memset(code, 0, engine_conf->code_size);
+ bch_encode(engine_conf->bch, buf, nand->ecc.ctx.conf.step_size, code);
/* apply mask so that an erased page is a valid codeword */
- for (i = 0; i < chip->ecc.bytes; i++)
- code[i] ^= nbc->eccmask[i];
+ for (i = 0; i < engine_conf->code_size; i++)
+ code[i] ^= engine_conf->eccmask[i];
return 0;
}
@@ -65,16 +49,16 @@ EXPORT_SYMBOL(nand_ecc_sw_bch_calculate);
int nand_ecc_sw_bch_correct(struct nand_device *nand, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc)
{
- struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
- struct nand_bch_control *nbc = chip->ecc.priv;
- unsigned int *errloc = nbc->errloc;
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
+ unsigned int step_size = nand->ecc.ctx.conf.step_size;
+ unsigned int *errloc = engine_conf->errloc;
int i, count;
- count = bch_decode(nbc->bch, NULL, chip->ecc.size, read_ecc, calc_ecc,
- NULL, errloc);
+ count = bch_decode(engine_conf->bch, NULL, step_size, read_ecc,
+ calc_ecc, NULL, errloc);
if (count > 0) {
for (i = 0; i < count; i++) {
- if (errloc[i] < (chip->ecc.size * 8))
+ if (errloc[i] < (step_size * 8))
/* The error is in the data area: correct it */
buf[errloc[i] >> 3] ^= (1 << (errloc[i] & 7));
@@ -97,31 +81,30 @@ EXPORT_SYMBOL(nand_ecc_sw_bch_correct);
*
* Returns: a pointer to a new NAND BCH control structure, or NULL upon failure
*
- * Initialize NAND BCH error correction. Parameters @eccsize and @eccbytes
- * are used to compute the following BCH parameters:
+ * Initialize NAND BCH error correction. @nand.ecc parameters 'step_size' and
+ * 'bytes' are used to compute the following BCH parameters:
* m, the Galois field order
* t, the error correction capability
- * @eccbytes should be equal to the number of bytes required to store m * t
+ * 'bytes' should be equal to the number of bytes required to store m * t
* bits, where m is such that 2^m - 1 > step_size * 8.
*
* Example: to configure 4 bit correction per 512 bytes, you should pass
- * @eccsize = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
- * @eccbytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
+ * step_size = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
+ * bytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
*/
int nand_ecc_sw_bch_init(struct nand_device *nand)
{
struct mtd_info *mtd = nanddev_to_mtd(nand);
- struct nand_chip *chip = mtd_to_nand(mtd);
unsigned int m, t, eccsteps, i;
- struct nand_bch_control *nbc = NULL;
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
unsigned char *erased_page;
- unsigned int eccsize = chip->ecc.size;
- unsigned int eccbytes = chip->ecc.bytes;
- unsigned int eccstrength = chip->ecc.strength;
+ unsigned int eccsize = nand->ecc.ctx.conf.step_size;
+ unsigned int eccbytes = engine_conf->code_size;
+ unsigned int eccstrength = nand->ecc.ctx.conf.strength;
if (!eccbytes && eccstrength) {
eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
- chip->ecc.bytes = eccbytes;
+ engine_conf->code_size = eccbytes;
}
if (!eccsize || !eccbytes) {
@@ -132,20 +115,14 @@ int nand_ecc_sw_bch_init(struct nand_device *nand)
m = fls(1+8*eccsize);
t = (eccbytes*8)/m;
- nbc = kzalloc(sizeof(*nbc), GFP_KERNEL);
- if (!nbc)
- return -ENOMEM;
-
- chip->ecc.priv = nbc;
-
- nbc->bch = bch_init(m, t, 0, false);
- if (!nbc->bch)
- goto fail;
+ engine_conf->bch = bch_init(m, t, 0, false);
+ if (!engine_conf->bch)
+ return -EINVAL;
/* verify that eccbytes has the expected value */
- if (nbc->bch->ecc_bytes != eccbytes) {
+ if (engine_conf->bch->ecc_bytes != eccbytes) {
pr_warn("invalid eccbytes %u, should be %u\n",
- eccbytes, nbc->bch->ecc_bytes);
+ eccbytes, engine_conf->bch->ecc_bytes);
goto fail;
}
@@ -163,24 +140,15 @@ int nand_ecc_sw_bch_init(struct nand_device *nand)
goto fail;
}
- /*
- * ecc->steps and ecc->total might be used by mtd->ooblayout->ecc(),
- * which is called by mtd_ooblayout_count_eccbytes().
- * Make sure they are properly initialized before calling
- * mtd_ooblayout_count_eccbytes().
- * FIXME: we should probably rework the sequencing in nand_scan_tail()
- * to avoid setting those fields twice.
- */
- chip->ecc.steps = eccsteps;
- chip->ecc.total = eccsteps * eccbytes;
if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
pr_warn("invalid ecc layout\n");
goto fail;
}
- nbc->eccmask = kzalloc(eccbytes, GFP_KERNEL);
- nbc->errloc = kmalloc_array(t, sizeof(*nbc->errloc), GFP_KERNEL);
- if (!nbc->eccmask || !nbc->errloc)
+ engine_conf->eccmask = kzalloc(eccbytes, GFP_KERNEL);
+ engine_conf->errloc = kmalloc_array(t, sizeof(*engine_conf->errloc),
+ GFP_KERNEL);
+ if (!engine_conf->eccmask || !engine_conf->errloc)
goto fail;
/*
@@ -191,14 +159,15 @@ int nand_ecc_sw_bch_init(struct nand_device *nand)
goto fail;
memset(erased_page, 0xff, eccsize);
- bch_encode(nbc->bch, erased_page, eccsize, nbc->eccmask);
+ bch_encode(engine_conf->bch, erased_page, eccsize,
+ engine_conf->eccmask);
kfree(erased_page);
for (i = 0; i < eccbytes; i++)
- nbc->eccmask[i] ^= 0xff;
+ engine_conf->eccmask[i] ^= 0xff;
if (!eccstrength)
- chip->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
+ nand->ecc.ctx.conf.strength = (eccbytes * 8) / fls(8 * eccsize);
return 0;
@@ -215,14 +184,12 @@ EXPORT_SYMBOL(nand_ecc_sw_bch_init);
*/
void nand_ecc_sw_bch_cleanup(struct nand_device *nand)
{
- struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
- struct nand_bch_control *nbc = chip->ecc.priv;
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
- if (nbc) {
- bch_free(nbc->bch);
- kfree(nbc->errloc);
- kfree(nbc->eccmask);
- kfree(nbc);
+ if (engine_conf) {
+ bch_free(engine_conf->bch);
+ kfree(engine_conf->errloc);
+ kfree(engine_conf->eccmask);
}
}
EXPORT_SYMBOL(nand_ecc_sw_bch_cleanup);
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 69bdbb1c3b60..6317bb656fbf 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5147,8 +5147,33 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
int rawnand_sw_bch_init(struct nand_chip *chip)
{
struct nand_device *base = &chip->base;
+ struct nand_ecc_sw_bch_conf *engine_conf;
+ int ret;
- return nand_ecc_sw_bch_init(base);
+ base->ecc.user_conf.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+ base->ecc.user_conf.algo = NAND_ECC_ALGO_BCH;
+ base->ecc.user_conf.step_size = chip->ecc.size;
+ base->ecc.user_conf.strength = chip->ecc.strength;
+
+ engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
+ if (!engine_conf)
+ return -ENOMEM;
+
+ engine_conf->code_size = chip->ecc.bytes;
+
+ base->ecc.ctx.priv = engine_conf;
+
+ ret = nand_ecc_sw_bch_init(base);
+ if (ret)
+ kfree(base->ecc.ctx.priv);
+
+ chip->ecc.size = base->ecc.ctx.conf.step_size;
+ chip->ecc.strength = base->ecc.ctx.conf.strength;
+ chip->ecc.total = base->ecc.ctx.total;
+ chip->ecc.steps = engine_conf->nsteps;
+ chip->ecc.bytes = engine_conf->code_size;
+
+ return ret;
}
EXPORT_SYMBOL(rawnand_sw_bch_init);
@@ -5176,7 +5201,7 @@ void rawnand_sw_bch_cleanup(struct nand_chip *chip)
nand_ecc_sw_bch_cleanup(base);
- chip->ecc.priv = NULL;
+ kfree(base->ecc.ctx.priv);
}
EXPORT_SYMBOL(rawnand_sw_bch_cleanup);
@@ -5799,15 +5824,18 @@ static int nand_scan_tail(struct nand_chip *chip)
* Set the number of read / write steps for one page depending on ECC
* mode.
*/
- ecc->steps = mtd->writesize / ecc->size;
+ if (!ecc->steps)
+ ecc->steps = mtd->writesize / ecc->size;
if (ecc->steps * ecc->size != mtd->writesize) {
WARN(1, "Invalid ECC parameters\n");
ret = -EINVAL;
goto err_nand_manuf_cleanup;
}
- ecc->total = ecc->steps * ecc->bytes;
- chip->base.ecc.ctx.total = ecc->total;
+ if (!ecc->total) {
+ ecc->total = ecc->steps * ecc->bytes;
+ chip->base.ecc.ctx.total = ecc->total;
+ }
if (ecc->total > mtd->oobsize) {
WARN(1, "Total number of ECC bytes exceeded oobsize\n");
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index f0caee3b03d0..ce005528e55f 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -9,6 +9,31 @@
#define __MTD_NAND_ECC_SW_BCH_H__
#include <linux/mtd/nand.h>
+#include <linux/bch.h>
+
+/**
+ * struct nand_ecc_sw_bch_conf - private software BCH ECC engine structure
+ * @reqooblen: Save the actual user OOB length requested before overwriting it
+ * @spare_oobbuf: Spare OOB buffer if none is provided
+ * @code_size: Number of bytes needed to store a code (one code per step)
+ * @nsteps: Number of steps
+ * @calc_buf: Buffer to use when calculating ECC bytes
+ * @code_buf: Buffer to use when reading (raw) ECC bytes from the chip
+ * @bch: BCH control structure
+ * @errloc: error location array
+ * @eccmask: XOR ecc mask, allows erased pages to be decoded as valid
+ */
+struct nand_ecc_sw_bch_conf {
+ unsigned int reqooblen;
+ void *spare_oobbuf;
+ unsigned int code_size;
+ unsigned int nsteps;
+ u8 *calc_buf;
+ u8 *code_buf;
+ struct bch_control *bch;
+ unsigned int *errloc;
+ unsigned char *eccmask;
+};
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 09/20] mtd: nand: ecc-bch: Create the software BCH engine
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (7 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 08/20] mtd: nand: ecc-bch: Stop using raw NAND structures Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 10/20] mtd: rawnand: Get rid of chip->ecc.priv Miquel Raynal
` (10 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Let's continue introducing the generic ECC engine abstraction in the
NAND subsystem by instantiating a first ECC engine: the software
BCH one.
While at it, make a very tidy ecc_sw_bch_init() function and move all
the sanity checks and user input management in
nand_ecc_sw_bch_init_ctx(). This second helper will be called from the
raw RAND core.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-bch.c | 333 ++++++++++++++++++++++------
drivers/mtd/nand/raw/nand_base.c | 62 +-----
include/linux/mtd/nand-ecc-sw-bch.h | 16 +-
include/linux/mtd/nand.h | 9 +
4 files changed, 295 insertions(+), 125 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-bch.c b/drivers/mtd/nand/ecc-sw-bch.c
index 16a54bd2ca31..76416b241f84 100644
--- a/drivers/mtd/nand/ecc-sw-bch.c
+++ b/drivers/mtd/nand/ecc-sw-bch.c
@@ -75,6 +75,19 @@ int nand_ecc_sw_bch_correct(struct nand_device *nand, unsigned char *buf,
}
EXPORT_SYMBOL(nand_ecc_sw_bch_correct);
+/**
+ * nand_ecc_sw_bch_cleanup - Cleanup software BCH ECC resources
+ * @nand: NAND device
+ */
+static void nand_ecc_sw_bch_cleanup(struct nand_device *nand)
+{
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
+
+ bch_free(engine_conf->bch);
+ kfree(engine_conf->errloc);
+ kfree(engine_conf->eccmask);
+}
+
/**
* nand_ecc_sw_bch_init - Initialize software BCH ECC engine
* @nand: NAND device
@@ -92,71 +105,36 @@ EXPORT_SYMBOL(nand_ecc_sw_bch_correct);
* step_size = 512 (thus, m = 13 is the smallest integer such that 2^m - 1 > 512 * 8)
* bytes = 7 (7 bytes are required to store m * t = 13 * 4 = 52 bits)
*/
-int nand_ecc_sw_bch_init(struct nand_device *nand)
+static int nand_ecc_sw_bch_init(struct nand_device *nand)
{
- struct mtd_info *mtd = nanddev_to_mtd(nand);
- unsigned int m, t, eccsteps, i;
struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
- unsigned char *erased_page;
unsigned int eccsize = nand->ecc.ctx.conf.step_size;
unsigned int eccbytes = engine_conf->code_size;
- unsigned int eccstrength = nand->ecc.ctx.conf.strength;
+ unsigned int m, t, i;
+ unsigned char *erased_page;
+ int ret;
- if (!eccbytes && eccstrength) {
- eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
- engine_conf->code_size = eccbytes;
- }
-
- if (!eccsize || !eccbytes) {
- pr_warn("ecc parameters not supplied\n");
- return -EINVAL;
- }
-
- m = fls(1+8*eccsize);
- t = (eccbytes*8)/m;
+ m = fls(1 + (8 * eccsize));
+ t = (eccbytes * 8) / m;
engine_conf->bch = bch_init(m, t, 0, false);
if (!engine_conf->bch)
return -EINVAL;
- /* verify that eccbytes has the expected value */
- if (engine_conf->bch->ecc_bytes != eccbytes) {
- pr_warn("invalid eccbytes %u, should be %u\n",
- eccbytes, engine_conf->bch->ecc_bytes);
- goto fail;
- }
-
- eccsteps = mtd->writesize/eccsize;
-
- /* Check that we have an oob layout description. */
- if (!mtd->ooblayout) {
- pr_warn("missing oob scheme");
- goto fail;
- }
-
- /* sanity checks */
- if (8*(eccsize+eccbytes) >= (1 << m)) {
- pr_warn("eccsize %u is too large\n", eccsize);
- goto fail;
- }
-
- if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
- pr_warn("invalid ecc layout\n");
- goto fail;
- }
-
engine_conf->eccmask = kzalloc(eccbytes, GFP_KERNEL);
engine_conf->errloc = kmalloc_array(t, sizeof(*engine_conf->errloc),
GFP_KERNEL);
- if (!engine_conf->eccmask || !engine_conf->errloc)
- goto fail;
+ if (!engine_conf->eccmask || !engine_conf->errloc) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
- /*
- * compute and store the inverted ecc of an erased ecc block
- */
+ /* Compute and store the inverted ECC of an erased step */
erased_page = kmalloc(eccsize, GFP_KERNEL);
- if (!erased_page)
- goto fail;
+ if (!erased_page) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
memset(erased_page, 0xff, eccsize);
bch_encode(engine_conf->bch, erased_page, eccsize,
@@ -166,33 +144,260 @@ int nand_ecc_sw_bch_init(struct nand_device *nand)
for (i = 0; i < eccbytes; i++)
engine_conf->eccmask[i] ^= 0xff;
- if (!eccstrength)
- nand->ecc.ctx.conf.strength = (eccbytes * 8) / fls(8 * eccsize);
+ /* Verify that the number of code bytes has the expected value */
+ if (engine_conf->bch->ecc_bytes != eccbytes) {
+ pr_err("Invalid number of ECC bytes: %u, expected: %u\n",
+ eccbytes, engine_conf->bch->ecc_bytes);
+ ret = -EINVAL;
+ goto cleanup;
+ }
+
+ /* Sanity checks */
+ if (8 * (eccsize + eccbytes) >= (1 << m)) {
+ pr_err("ECC step size is too large (%u)\n", eccsize);
+ ret = -EINVAL;
+ goto cleanup;
+ }
+
+ return 0;
+
+cleanup:
+ nand_ecc_sw_bch_cleanup(nand);
+
+ return ret;
+}
+
+int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
+{
+ struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ struct nand_ecc_sw_bch_conf *engine_conf;
+ unsigned int code_size = 0, nsteps;
+ int ret;
+
+ /* Only large page NAND chips may use BCH */
+ if (mtd->oobsize < 64) {
+ pr_err("BCH cannot be used with small page NAND chips\n");
+ return -EINVAL;
+ }
+
+ if (!mtd->ooblayout)
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
+
+ conf->engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+ conf->algo = NAND_ECC_ALGO_BCH;
+ conf->step_size = nand->ecc.user_conf.step_size;
+ conf->strength = nand->ecc.user_conf.strength;
+
+ /*
+ * Board driver should supply ECC size and ECC strength
+ * values to select how many bits are correctable.
+ * Otherwise, default to 512 bytes for large page devices and 256 for
+ * small page devices.
+ */
+ if (!conf->step_size) {
+ if (mtd->oobsize >= 64)
+ conf->step_size = 512;
+ else
+ conf->step_size = 256;
+
+ conf->strength = 4;
+ }
+
+ nsteps = mtd->writesize / conf->step_size;
+
+ /* Maximize */
+ if (nand->ecc.user_conf.flags & NAND_ECC_MAXIMIZE_STRENGTH) {
+ conf->step_size = 1024;
+ nsteps = mtd->writesize / conf->step_size;
+ /* Reserve 2 bytes for the BBM */
+ code_size = (mtd->oobsize - 2) / nsteps;
+ conf->strength = code_size * 8 / fls(8 * conf->step_size);
+ }
+
+ if (!code_size)
+ code_size = DIV_ROUND_UP(conf->strength *
+ fls(8 * conf->step_size), 8);
+
+ if (!conf->strength)
+ conf->strength = (code_size * 8) / fls(8 * conf->step_size);
+
+ if (!code_size && !conf->strength) {
+ pr_err("Missing ECC parameters\n");
+ return -EINVAL;
+ }
+
+ engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
+ if (!engine_conf)
+ return -ENOMEM;
+
+ ret = nand_ecc_init_req_tweaking(&engine_conf->req_ctx, nand);
+ if (ret)
+ goto free_engine_conf;
+
+ engine_conf->code_size = code_size;
+ engine_conf->nsteps = nsteps;
+ engine_conf->calc_buf = kzalloc(sizeof(mtd->oobsize), GFP_KERNEL);
+ engine_conf->code_buf = kzalloc(sizeof(mtd->oobsize), GFP_KERNEL);
+ if (!engine_conf->calc_buf || !engine_conf->code_buf) {
+ ret = -ENOMEM;
+ goto free_bufs;
+ }
+
+ nand->ecc.ctx.priv = engine_conf;
+ nand->ecc.ctx.total = nsteps * code_size;
+
+ ret = nand_ecc_sw_bch_init(nand);
+ if (ret)
+ goto free_bufs;
+
+ /* Verify the layout validity */
+ if (mtd_ooblayout_count_eccbytes(mtd) !=
+ engine_conf->nsteps * engine_conf->code_size) {
+ pr_err("Invalid ECC layout\n");
+ ret = -EINVAL;
+ goto cleanup_bch_ctx;
+ }
return 0;
-fail:
+cleanup_bch_ctx:
nand_ecc_sw_bch_cleanup(nand);
+free_bufs:
+ nand_ecc_cleanup_req_tweaking(&engine_conf->req_ctx);
+ kfree(engine_conf->calc_buf);
+ kfree(engine_conf->code_buf);
+free_engine_conf:
+ kfree(engine_conf);
- return -EINVAL;
+ return ret;
}
-EXPORT_SYMBOL(nand_ecc_sw_bch_init);
+EXPORT_SYMBOL(nand_ecc_sw_bch_init_ctx);
-/**
- * nand_ecc_sw_bch_cleanup - Cleanup software BCH ECC resources
- * @nand: NAND device
- */
-void nand_ecc_sw_bch_cleanup(struct nand_device *nand)
+void nand_ecc_sw_bch_cleanup_ctx(struct nand_device *nand)
{
struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
if (engine_conf) {
- bch_free(engine_conf->bch);
- kfree(engine_conf->errloc);
- kfree(engine_conf->eccmask);
+ nand_ecc_sw_bch_cleanup(nand);
+ nand_ecc_cleanup_req_tweaking(&engine_conf->req_ctx);
+ kfree(engine_conf->calc_buf);
+ kfree(engine_conf->code_buf);
+ kfree(engine_conf);
}
}
-EXPORT_SYMBOL(nand_ecc_sw_bch_cleanup);
+EXPORT_SYMBOL(nand_ecc_sw_bch_cleanup_ctx);
+
+static int nand_ecc_sw_bch_prepare_io_req(struct nand_device *nand,
+ struct nand_page_io_req *req)
+{
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int eccsize = nand->ecc.ctx.conf.step_size;
+ int eccbytes = engine_conf->code_size;
+ int eccsteps = engine_conf->nsteps;
+ int total = nand->ecc.ctx.total;
+ u8 *ecccalc = engine_conf->calc_buf;
+ const u8 *data = req->databuf.out;
+ int i;
+
+ /* Nothing to do for a raw operation */
+ if (req->mode == MTD_OPS_RAW)
+ return 0;
+
+ /* This engine does not provide BBM/free OOB bytes protection */
+ if (!req->datalen)
+ return 0;
+
+ nand_ecc_tweak_req(&engine_conf->req_ctx, req);
+
+ /* No more preparation for page read */
+ if (req->type == NAND_PAGE_READ)
+ return 0;
+
+ /* Preparation for page write: derive the ECC bytes and place them */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, data += eccsize)
+ nand_ecc_sw_bch_calculate(nand, data, &ecccalc[i]);
+
+ return mtd_ooblayout_set_eccbytes(mtd, ecccalc, (void *)req->oobbuf.out,
+ 0, total);
+}
+
+static int nand_ecc_sw_bch_finish_io_req(struct nand_device *nand,
+ struct nand_page_io_req *req)
+{
+ struct nand_ecc_sw_bch_conf *engine_conf = nand->ecc.ctx.priv;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int eccsize = nand->ecc.ctx.conf.step_size;
+ int total = nand->ecc.ctx.total;
+ int eccbytes = engine_conf->code_size;
+ int eccsteps = engine_conf->nsteps;
+ u8 *ecccalc = engine_conf->calc_buf;
+ u8 *ecccode = engine_conf->code_buf;
+ unsigned int max_bitflips = 0;
+ u8 *data = req->databuf.in;
+ int i, ret;
+
+ /* Nothing to do for a raw operation */
+ if (req->mode == MTD_OPS_RAW)
+ return 0;
+
+ /* This engine does not provide BBM/free OOB bytes protection */
+ if (!req->datalen)
+ return 0;
+
+ /* No more preparation for page write */
+ if (req->type == NAND_PAGE_WRITE) {
+ nand_ecc_restore_req(&engine_conf->req_ctx, req);
+ return 0;
+ }
+
+ /* Finish a page read: retrieve the (raw) ECC bytes*/
+ ret = mtd_ooblayout_get_eccbytes(mtd, ecccode, req->oobbuf.in, 0,
+ total);
+ if (ret)
+ return ret;
+
+ /* Calculate the ECC bytes */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, data += eccsize)
+ nand_ecc_sw_bch_calculate(nand, data, &ecccalc[i]);
+
+ /* Finish a page read: compare and correct */
+ for (eccsteps = engine_conf->nsteps, i = 0, data = req->databuf.in;
+ eccsteps;
+ eccsteps--, i += eccbytes, data += eccsize) {
+ int stat = nand_ecc_sw_bch_correct(nand, data,
+ &ecccode[i],
+ &ecccalc[i]);
+ if (stat < 0) {
+ mtd->ecc_stats.failed++;
+ } else {
+ mtd->ecc_stats.corrected += stat;
+ max_bitflips = max_t(unsigned int, max_bitflips, stat);
+ }
+ }
+
+ nand_ecc_restore_req(&engine_conf->req_ctx, req);
+
+ return max_bitflips;
+}
+
+static struct nand_ecc_engine_ops nand_ecc_sw_bch_engine_ops = {
+ .init_ctx = nand_ecc_sw_bch_init_ctx,
+ .cleanup_ctx = nand_ecc_sw_bch_cleanup_ctx,
+ .prepare_io_req = nand_ecc_sw_bch_prepare_io_req,
+ .finish_io_req = nand_ecc_sw_bch_finish_io_req,
+};
+
+static struct nand_ecc_engine nand_ecc_sw_bch_engine = {
+ .ops = &nand_ecc_sw_bch_engine_ops,
+};
+
+struct nand_ecc_engine *nand_ecc_sw_bch_get_engine(void)
+{
+ return &nand_ecc_sw_bch_engine;
+}
+EXPORT_SYMBOL(nand_ecc_sw_bch_get_engine);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Ivan Djelic <ivan.djelic@parrot.com>");
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 6317bb656fbf..f68802bf555a 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5155,17 +5155,11 @@ int rawnand_sw_bch_init(struct nand_chip *chip)
base->ecc.user_conf.step_size = chip->ecc.size;
base->ecc.user_conf.strength = chip->ecc.strength;
- engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
- if (!engine_conf)
- return -ENOMEM;
-
- engine_conf->code_size = chip->ecc.bytes;
-
- base->ecc.ctx.priv = engine_conf;
-
- ret = nand_ecc_sw_bch_init(base);
+ ret = nand_ecc_sw_bch_init_ctx(base);
if (ret)
- kfree(base->ecc.ctx.priv);
+ return ret;
+
+ engine_conf = base->ecc.ctx.priv;
chip->ecc.size = base->ecc.ctx.conf.step_size;
chip->ecc.strength = base->ecc.ctx.conf.strength;
@@ -5173,7 +5167,7 @@ int rawnand_sw_bch_init(struct nand_chip *chip)
chip->ecc.steps = engine_conf->nsteps;
chip->ecc.bytes = engine_conf->code_size;
- return ret;
+ return 0;
}
EXPORT_SYMBOL(rawnand_sw_bch_init);
@@ -5199,9 +5193,7 @@ void rawnand_sw_bch_cleanup(struct nand_chip *chip)
{
struct nand_device *base = &chip->base;
- nand_ecc_sw_bch_cleanup(base);
-
- kfree(base->ecc.ctx.priv);
+ nand_ecc_sw_bch_cleanup_ctx(base);
}
EXPORT_SYMBOL(rawnand_sw_bch_cleanup);
@@ -5313,51 +5305,15 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
ecc->read_oob = nand_read_oob_std;
ecc->write_oob = nand_write_oob_std;
- /*
- * Board driver should supply ecc.size and ecc.strength
- * values to select how many bits are correctable.
- * Otherwise, default to 4 bits for large page devices.
- */
- if (!ecc->size && (mtd->oobsize >= 64)) {
- ecc->size = 512;
- ecc->strength = 4;
- }
-
- /*
- * if no ecc placement scheme was provided pickup the default
- * large page one.
- */
- if (!mtd->ooblayout) {
- /* handle large page devices only */
- if (mtd->oobsize < 64) {
- WARN(1, "OOB layout is required when using software BCH on small pages\n");
- return -EINVAL;
- }
-
- mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
-
- }
-
/*
* We can only maximize ECC config when the default layout is
* used, otherwise we don't know how many bytes can really be
* used.
*/
- if (mtd->ooblayout == nand_get_large_page_ooblayout() &&
- nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE_STRENGTH) {
- int steps, bytes;
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE_STRENGTH &&
+ mtd->ooblayout != nand_get_large_page_ooblayout())
+ nanddev->ecc.user_conf.flags &= ~NAND_ECC_MAXIMIZE_STRENGTH;
- /* Always prefer 1k blocks over 512bytes ones */
- ecc->size = 1024;
- steps = mtd->writesize / ecc->size;
-
- /* Reserve 2 bytes for the BBM */
- bytes = (mtd->oobsize - 2) / steps;
- ecc->strength = bytes * 8 / fls(8 * ecc->size);
- }
-
- /* See the software BCH ECC initialization for details */
- ecc->bytes = 0;
ret = rawnand_sw_bch_init(chip);
if (ret) {
WARN(1, "BCH ECC initialization failed!\n");
diff --git a/include/linux/mtd/nand-ecc-sw-bch.h b/include/linux/mtd/nand-ecc-sw-bch.h
index ce005528e55f..22c92073b3dd 100644
--- a/include/linux/mtd/nand-ecc-sw-bch.h
+++ b/include/linux/mtd/nand-ecc-sw-bch.h
@@ -13,8 +13,8 @@
/**
* struct nand_ecc_sw_bch_conf - private software BCH ECC engine structure
- * @reqooblen: Save the actual user OOB length requested before overwriting it
- * @spare_oobbuf: Spare OOB buffer if none is provided
+ * @req_ctx: Save request context and tweak the original request to fit the
+ * engine needs
* @code_size: Number of bytes needed to store a code (one code per step)
* @nsteps: Number of steps
* @calc_buf: Buffer to use when calculating ECC bytes
@@ -24,8 +24,7 @@
* @eccmask: XOR ecc mask, allows erased pages to be decoded as valid
*/
struct nand_ecc_sw_bch_conf {
- unsigned int reqooblen;
- void *spare_oobbuf;
+ struct nand_ecc_req_tweak_ctx req_ctx;
unsigned int code_size;
unsigned int nsteps;
u8 *calc_buf;
@@ -41,8 +40,9 @@ int nand_ecc_sw_bch_calculate(struct nand_device *nand,
const unsigned char *buf, unsigned char *code);
int nand_ecc_sw_bch_correct(struct nand_device *nand, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc);
-int nand_ecc_sw_bch_init(struct nand_device *nand);
-void nand_ecc_sw_bch_cleanup(struct nand_device *nand);
+int nand_ecc_sw_bch_init_ctx(struct nand_device *nand);
+void nand_ecc_sw_bch_cleanup_ctx(struct nand_device *nand);
+struct nand_ecc_engine *nand_ecc_sw_bch_get_engine(void);
#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
@@ -61,12 +61,12 @@ static inline int nand_ecc_sw_bch_correct(struct nand_device *nand,
return -ENOTSUPP;
}
-static inline int nand_ecc_sw_bch_init(struct nand_device *nand)
+static inline int nand_ecc_sw_bch_init_ctx(struct nand_device *nand)
{
return -ENOTSUPP;
}
-static inline void nand_ecc_sw_bch_cleanup(struct nand_device *nand) {}
+static inline void nand_ecc_sw_bch_cleanup_ctx(struct nand_device *nand) {}
#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 36e4fe08d0ea..df8548187713 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -278,6 +278,15 @@ int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
bool nand_ecc_is_strong_enough(struct nand_device *nand);
+#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
+struct nand_ecc_engine *nand_ecc_sw_bch_get_engine(void);
+#else
+static inline struct nand_ecc_engine *nand_ecc_sw_bch_get_engine(void)
+{
+ return NULL;
+}
+#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
+
/**
* struct nand_ecc_req_tweak_ctx - Help for automatically tweaking requests
* @orig_req: Pointer to the original IO request
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 09/20] mtd: nand: ecc-bch: Create the software BCH engine
2020-09-29 23:01 ` [PATCH 09/20] mtd: nand: ecc-bch: Create the software BCH engine Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:13 UTC, Miquel Raynal wrote:
> Let's continue introducing the generic ECC engine abstraction in the
> NAND subsystem by instantiating a first ECC engine: the software
> BCH one.
>
> While at it, make a very tidy ecc_sw_bch_init() function and move all
> the sanity checks and user input management in
> nand_ecc_sw_bch_init_ctx(). This second helper will be called from the
> raw RAND core.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 10/20] mtd: rawnand: Get rid of chip->ecc.priv
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (8 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 09/20] mtd: nand: ecc-bch: Create the software BCH engine Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 11/20] mtd: nand: ecc-hamming: Move Hamming code to the generic NAND layer Miquel Raynal
` (9 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Maxime Ripard, Chen-Yu Tsai, Thomas Petazzoni,
Miquel Raynal
nand_ecc_ctrl embeds a private pointer which only has a meaning in the
sunxi driver. This structure will soon be deprecated, but as this
field is actually not needed, let's just drop it.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
---
drivers/mtd/nand/raw/sunxi_nand.c | 31 +++++++++++++++++--------------
include/linux/mtd/rawnand.h | 2 --
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
index 2a7ca3072f35..540529540ade 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -182,6 +182,7 @@ struct sunxi_nand_hw_ecc {
*
* @node: used to store NAND chips into a list
* @nand: base NAND chip structure
+ * @ecc: ECC controller structure
* @clk_rate: clk_rate required for this NAND chip
* @timing_cfg: TIMING_CFG register value for this NAND chip
* @timing_ctl: TIMING_CTL register value for this NAND chip
@@ -191,6 +192,7 @@ struct sunxi_nand_hw_ecc {
struct sunxi_nand_chip {
struct list_head node;
struct nand_chip nand;
+ struct sunxi_nand_hw_ecc *ecc;
unsigned long clk_rate;
u32 timing_cfg;
u32 timing_ctl;
@@ -676,15 +678,15 @@ static void sunxi_nfc_randomizer_read_buf(struct nand_chip *nand, uint8_t *buf,
static void sunxi_nfc_hw_ecc_enable(struct nand_chip *nand)
{
+ struct sunxi_nand_chip *sunxi_nand = to_sunxi_nand(nand);
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
- struct sunxi_nand_hw_ecc *data = nand->ecc.priv;
u32 ecc_ctl;
ecc_ctl = readl(nfc->regs + NFC_REG_ECC_CTL);
ecc_ctl &= ~(NFC_ECC_MODE_MSK | NFC_ECC_PIPELINE |
NFC_ECC_BLOCK_SIZE_MSK);
- ecc_ctl |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION |
- NFC_ECC_PIPELINE;
+ ecc_ctl |= NFC_ECC_EN | NFC_ECC_MODE(sunxi_nand->ecc->mode) |
+ NFC_ECC_EXCEPTION | NFC_ECC_PIPELINE;
if (nand->ecc.size == 512)
ecc_ctl |= NFC_ECC_BLOCK_512;
@@ -1597,9 +1599,9 @@ static const struct mtd_ooblayout_ops sunxi_nand_ooblayout_ops = {
.free = sunxi_nand_ooblayout_free,
};
-static void sunxi_nand_hw_ecc_ctrl_cleanup(struct nand_ecc_ctrl *ecc)
+static void sunxi_nand_hw_ecc_ctrl_cleanup(struct sunxi_nand_chip *sunxi_nand)
{
- kfree(ecc->priv);
+ kfree(sunxi_nand->ecc);
}
static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
@@ -1607,10 +1609,10 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
struct device_node *np)
{
static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+ struct sunxi_nand_chip *sunxi_nand = to_sunxi_nand(nand);
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct mtd_info *mtd = nand_to_mtd(nand);
struct nand_device *nanddev = mtd_to_nanddev(mtd);
- struct sunxi_nand_hw_ecc *data;
int nsectors;
int ret;
int i;
@@ -1647,8 +1649,8 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
if (ecc->size != 512 && ecc->size != 1024)
return -EINVAL;
- data = kzalloc(sizeof(*data), GFP_KERNEL);
- if (!data)
+ sunxi_nand->ecc = kzalloc(sizeof(*sunxi_nand->ecc), GFP_KERNEL);
+ if (!sunxi_nand->ecc)
return -ENOMEM;
/* Prefer 1k ECC chunk over 512 ones */
@@ -1675,7 +1677,7 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
goto err;
}
- data->mode = i;
+ sunxi_nand->ecc->mode = i;
/* HW ECC always request ECC bytes for 1024 bytes blocks */
ecc->bytes = DIV_ROUND_UP(ecc->strength * fls(8 * 1024), 8);
@@ -1693,7 +1695,6 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
ecc->read_oob = sunxi_nfc_hw_ecc_read_oob;
ecc->write_oob = sunxi_nfc_hw_ecc_write_oob;
mtd_set_ooblayout(mtd, &sunxi_nand_ooblayout_ops);
- ecc->priv = data;
if (nfc->dmac) {
ecc->read_page = sunxi_nfc_hw_ecc_read_page_dma;
@@ -1714,16 +1715,18 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
return 0;
err:
- kfree(data);
+ kfree(sunxi_nand->ecc);
return ret;
}
-static void sunxi_nand_ecc_cleanup(struct nand_ecc_ctrl *ecc)
+static void sunxi_nand_ecc_cleanup(struct sunxi_nand_chip *sunxi_nand)
{
+ struct nand_ecc_ctrl *ecc = &sunxi_nand->nand.ecc;
+
switch (ecc->engine_type) {
case NAND_ECC_ENGINE_TYPE_ON_HOST:
- sunxi_nand_hw_ecc_ctrl_cleanup(ecc);
+ sunxi_nand_hw_ecc_ctrl_cleanup(sunxi_nand);
break;
case NAND_ECC_ENGINE_TYPE_NONE:
default:
@@ -2053,7 +2056,7 @@ static void sunxi_nand_chips_cleanup(struct sunxi_nfc *nfc)
ret = mtd_device_unregister(nand_to_mtd(chip));
WARN_ON(ret);
nand_cleanup(chip);
- sunxi_nand_ecc_cleanup(&chip->ecc);
+ sunxi_nand_ecc_cleanup(sunxi_nand);
list_del(&sunxi_nand->node);
}
}
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 23623beaad1d..15743c2c2cab 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -302,7 +302,6 @@ static const struct nand_ecc_caps __name = { \
* @prepad: padding information for syndrome based ECC generators
* @postpad: padding information for syndrome based ECC generators
* @options: ECC specific options (see NAND_ECC_XXX flags defined above)
- * @priv: pointer to private ECC control data
* @calc_buf: buffer for calculated ECC, size is oobsize.
* @code_buf: buffer for ECC read from flash, size is oobsize.
* @hwctl: function to control hardware ECC generator. Must only
@@ -355,7 +354,6 @@ struct nand_ecc_ctrl {
int prepad;
int postpad;
unsigned int options;
- void *priv;
u8 *calc_buf;
u8 *code_buf;
void (*hwctl)(struct nand_chip *chip, int mode);
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 10/20] mtd: rawnand: Get rid of chip->ecc.priv
2020-09-29 23:01 ` [PATCH 10/20] mtd: rawnand: Get rid of chip->ecc.priv Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, Chen-Yu Tsai, ycllin, Thomas Petazzoni, Maxime Ripard
On Tue, 2020-09-29 at 23:01:14 UTC, Miquel Raynal wrote:
> nand_ecc_ctrl embeds a private pointer which only has a meaning in the
> sunxi driver. This structure will soon be deprecated, but as this
> field is actually not needed, let's just drop it.
>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 11/20] mtd: nand: ecc-hamming: Move Hamming code to the generic NAND layer
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (9 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 10/20] mtd: rawnand: Get rid of chip->ecc.priv Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 12/20] mtd: nand: ecc-hamming: Clarify the driver descriptions Miquel Raynal
` (8 subsequent siblings)
19 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Hamming ECC code might be later re-used by the SPI NAND layer.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
arch/arm/mach-s3c24xx/common-smdk.c | 2 +-
arch/arm/mach-s3c24xx/mach-anubis.c | 2 +-
arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +-
arch/arm/mach-s3c24xx/mach-bast.c | 2 +-
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
arch/arm/mach-s3c24xx/mach-qt2410.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx3715.c | 2 +-
arch/arm/mach-s3c24xx/mach-vstms.c | 2 +-
drivers/mtd/nand/Kconfig | 11 +++++++++++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/{raw/nand_ecc.c => ecc-sw-hamming.c} | 2 +-
drivers/mtd/nand/raw/Kconfig | 11 -----------
drivers/mtd/nand/raw/Makefile | 1 -
drivers/mtd/nand/raw/cs553x_nand.c | 2 +-
drivers/mtd/nand/raw/fsl_elbc_nand.c | 2 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +-
drivers/mtd/nand/raw/fsl_upm.c | 2 +-
drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_mlc.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 2 +-
drivers/mtd/nand/raw/mxic_nand.c | 2 +-
drivers/mtd/nand/raw/nand_base.c | 2 +-
drivers/mtd/nand/raw/ndfc.c | 2 +-
drivers/mtd/nand/raw/pasemi_nand.c | 2 +-
drivers/mtd/nand/raw/s3c2410.c | 2 +-
drivers/mtd/nand/raw/sharpsl.c | 2 +-
drivers/mtd/nand/raw/tmio_nand.c | 2 +-
drivers/mtd/nand/raw/txx9ndfmc.c | 2 +-
drivers/mtd/sm_ftl.c | 2 +-
drivers/mtd/tests/mtd_nandecctest.c | 2 +-
.../linux/mtd/{nand_ecc.h => nand-ecc-sw-hamming.h} | 6 +++---
include/linux/mtd/sharpsl.h | 2 +-
35 files changed, 45 insertions(+), 45 deletions(-)
rename drivers/mtd/nand/{raw/nand_ecc.c => ecc-sw-hamming.c} (99%)
rename include/linux/mtd/{nand_ecc.h => nand-ecc-sw-hamming.h} (88%)
diff --git a/arch/arm/mach-s3c24xx/common-smdk.c b/arch/arm/mach-s3c24xx/common-smdk.c
index 121646ad1bb1..72e9b87acbc6 100644
--- a/arch/arm/mach-s3c24xx/common-smdk.c
+++ b/arch/arm/mach-s3c24xx/common-smdk.c
@@ -20,7 +20,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/io.h>
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index 28326241e360..190f22574cff 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -36,7 +36,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <net/ax88796.h>
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 04dedebdb57c..87257c54140d 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -37,7 +37,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/devs.h>
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index 6465eab0ab3a..fa947bf881fe 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -24,7 +24,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/platform_data/asoc-s3c24xx_simtec.h>
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index db1b64f6e0a5..ef23402fdef5 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -36,7 +36,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 8233dcff19e7..49c3ea18b88f 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -40,7 +40,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/gpio-cfg.h>
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index 057dcbaf1b22..0d18fea49004 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -46,7 +46,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/gpio-cfg.h>
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 157448827f61..592fc67b9ffe 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -33,7 +33,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index f3131d94e90b..d75d03cf6623 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -21,7 +21,7 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-s3c24xx/mach-rx3715.c b/arch/arm/mach-s3c24xx/mach-rx3715.c
index 017010d67e01..9daf78d963ee 100644
--- a/arch/arm/mach-s3c24xx/mach-rx3715.c
+++ b/arch/arm/mach-s3c24xx/mach-rx3715.c
@@ -22,7 +22,7 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index c5fa215a527e..df30ebc02b38 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -16,7 +16,7 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/memblock.h>
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 55c17fb0dee1..306c33ca3448 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -15,6 +15,17 @@ config MTD_NAND_ECC
bool
depends on MTD_NAND_CORE
+config MTD_NAND_ECC_SW_HAMMING
+ bool
+
+config MTD_NAND_ECC_SW_HAMMING_SMC
+ bool "NAND ECC Smart Media byte order"
+ depends on MTD_NAND_ECC_SW_HAMMING
+ default n
+ help
+ Software ECC according to the Smart Media Specification.
+ The original Linux implementation had byte 0 and 1 swapped.
+
config MTD_NAND_ECC_SW_BCH
bool "Software BCH ECC engine"
select BCH
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index c7179ff23753..1c0b46960eb1 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -8,4 +8,5 @@ obj-y += raw/
obj-y += spi/
nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
+nandcore-$(CONFIG_MTD_NAND_ECC_SW_HAMMING) += ecc-sw-hamming.o
nandcore-$(CONFIG_MTD_NAND_ECC_SW_BCH) += ecc-sw-bch.o
diff --git a/drivers/mtd/nand/raw/nand_ecc.c b/drivers/mtd/nand/ecc-sw-hamming.c
similarity index 99%
rename from drivers/mtd/nand/raw/nand_ecc.c
rename to drivers/mtd/nand/ecc-sw-hamming.c
index b6a46b1b7781..76966f5ff13f 100644
--- a/drivers/mtd/nand/raw/nand_ecc.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -19,7 +19,7 @@
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <asm/byteorder.h>
/*
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index b73860aa77c6..6149096e32cb 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -1,15 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-config MTD_NAND_ECC_SW_HAMMING
- tristate
-
-config MTD_NAND_ECC_SW_HAMMING_SMC
- bool "NAND ECC Smart Media byte order"
- depends on MTD_NAND_ECC_SW_HAMMING
- default n
- help
- Software ECC according to the Smart Media Specification.
- The original Linux implementation had byte 0 and 1 swapped.
-
menuconfig MTD_RAW_NAND
tristate "Raw/Parallel NAND Device Support"
select MTD_NAND_CORE
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 76904305d091..dc38c087c693 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_MTD_RAW_NAND) += nand.o
-obj-$(CONFIG_MTD_NAND_ECC_SW_HAMMING) += nand_ecc.o
obj-$(CONFIG_MTD_SM_COMMON) += sm_common.o
obj-$(CONFIG_MTD_NAND_CAFE) += cafe_nand.o
diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c
index b7f3f6347761..7c492096426b 100644
--- a/drivers/mtd/nand/raw/cs553x_nand.c
+++ b/drivers/mtd/nand/raw/cs553x_nand.c
@@ -19,7 +19,7 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/iopoll.h>
diff --git a/drivers/mtd/nand/raw/fsl_elbc_nand.c b/drivers/mtd/nand/raw/fsl_elbc_nand.c
index b2af7f81fdf8..eb255cf83e32 100644
--- a/drivers/mtd/nand/raw/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_elbc_nand.c
@@ -22,7 +22,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/io.h>
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c
index 0e7a9b64301e..e3e3b2abb6cd 100644
--- a/drivers/mtd/nand/raw/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c
@@ -15,7 +15,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/fsl_ifc.h>
#include <linux/iopoll.h>
diff --git a/drivers/mtd/nand/raw/fsl_upm.c b/drivers/mtd/nand/raw/fsl_upm.c
index d5813b9abc8e..3824361928a1 100644
--- a/drivers/mtd/nand/raw/fsl_upm.c
+++ b/drivers/mtd/nand/raw/fsl_upm.c
@@ -11,7 +11,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/mtd.h>
#include <linux/of_platform.h>
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index 1bc2462efeab..cb41d527bee0 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -26,7 +26,7 @@
#include <linux/types.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/mtd/partitions.h>
diff --git a/drivers/mtd/nand/raw/lpc32xx_mlc.c b/drivers/mtd/nand/raw/lpc32xx_mlc.c
index 4940bb2e3c07..b9ccf6f2f9c6 100644
--- a/drivers/mtd/nand/raw/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_mlc.c
@@ -31,7 +31,7 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#define DRV_NAME "lpc32xx_mlc"
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index 6db9d2ed6881..0f395cc7f101 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -23,7 +23,7 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/gpio.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c
index d66b5b0971fa..da1070993994 100644
--- a/drivers/mtd/nand/raw/mxic_nand.c
+++ b/drivers/mtd/nand/raw/mxic_nand.c
@@ -12,8 +12,8 @@
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
#include <linux/platform_device.h>
#include "internals.h"
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index f68802bf555a..a8aaedd940cd 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -35,7 +35,7 @@
#include <linux/types.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/nand-ecc-sw-bch.h>
#include <linux/interrupt.h>
#include <linux/bitops.h>
diff --git a/drivers/mtd/nand/raw/ndfc.c b/drivers/mtd/nand/raw/ndfc.c
index 0fb4ba93c41e..8cda6633280b 100644
--- a/drivers/mtd/nand/raw/ndfc.c
+++ b/drivers/mtd/nand/raw/ndfc.c
@@ -18,7 +18,7 @@
*/
#include <linux/module.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/ndfc.h>
#include <linux/slab.h>
diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c
index 2b8f155cc0c5..108e3817737a 100644
--- a/drivers/mtd/nand/raw/pasemi_nand.c
+++ b/drivers/mtd/nand/raw/pasemi_nand.c
@@ -14,7 +14,7 @@
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
diff --git a/drivers/mtd/nand/raw/s3c2410.c b/drivers/mtd/nand/raw/s3c2410.c
index fbd0fa48e063..f7eb3b5fa792 100644
--- a/drivers/mtd/nand/raw/s3c2410.c
+++ b/drivers/mtd/nand/raw/s3c2410.c
@@ -30,7 +30,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
diff --git a/drivers/mtd/nand/raw/sharpsl.c b/drivers/mtd/nand/raw/sharpsl.c
index 1327bfb3d5d3..553ffb61b7e1 100644
--- a/drivers/mtd/nand/raw/sharpsl.c
+++ b/drivers/mtd/nand/raw/sharpsl.c
@@ -12,7 +12,7 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/sharpsl.h>
#include <linux/interrupt.h>
diff --git a/drivers/mtd/nand/raw/tmio_nand.c b/drivers/mtd/nand/raw/tmio_nand.c
index 235a2f7b1bad..cd3733c3ae04 100644
--- a/drivers/mtd/nand/raw/tmio_nand.c
+++ b/drivers/mtd/nand/raw/tmio_nand.c
@@ -35,7 +35,7 @@
#include <linux/ioport.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/slab.h>
diff --git a/drivers/mtd/nand/raw/txx9ndfmc.c b/drivers/mtd/nand/raw/txx9ndfmc.c
index ef81dce6b5c4..ade0bfd2648d 100644
--- a/drivers/mtd/nand/raw/txx9ndfmc.c
+++ b/drivers/mtd/nand/raw/txx9ndfmc.c
@@ -14,7 +14,7 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/io.h>
#include <linux/platform_data/txx9/ndfmc.h>
diff --git a/drivers/mtd/sm_ftl.c b/drivers/mtd/sm_ftl.c
index b9f272408c4d..db430ae6a1a2 100644
--- a/drivers/mtd/sm_ftl.c
+++ b/drivers/mtd/sm_ftl.c
@@ -13,7 +13,7 @@
#include <linux/sysfs.h>
#include <linux/bitops.h>
#include <linux/slab.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include "nand/raw/sm_common.h"
#include "sm_ftl.h"
diff --git a/drivers/mtd/tests/mtd_nandecctest.c b/drivers/mtd/tests/mtd_nandecctest.c
index 13bca9ea0cae..e92e3fb287b6 100644
--- a/drivers/mtd/tests/mtd_nandecctest.c
+++ b/drivers/mtd/tests/mtd_nandecctest.c
@@ -8,7 +8,7 @@
#include <linux/string.h>
#include <linux/bitops.h>
#include <linux/slab.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include "mtd_test.h"
diff --git a/include/linux/mtd/nand_ecc.h b/include/linux/mtd/nand-ecc-sw-hamming.h
similarity index 88%
rename from include/linux/mtd/nand_ecc.h
rename to include/linux/mtd/nand-ecc-sw-hamming.h
index d423916b94f0..30a0cfa50eed 100644
--- a/include/linux/mtd/nand_ecc.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -7,8 +7,8 @@
* This file is the header for the ECC algorithm.
*/
-#ifndef __MTD_NAND_ECC_H__
-#define __MTD_NAND_ECC_H__
+#ifndef __MTD_NAND_ECC_SW_HAMMING_H__
+#define __MTD_NAND_ECC_SW_HAMMING_H__
struct nand_chip;
@@ -36,4 +36,4 @@ int __nand_correct_data(u_char *dat, u_char *read_ecc, u_char *calc_ecc,
int nand_correct_data(struct nand_chip *chip, u_char *dat, u_char *read_ecc,
u_char *calc_ecc);
-#endif /* __MTD_NAND_ECC_H__ */
+#endif /* __MTD_NAND_ECC_SW_HAMMING_H__ */
diff --git a/include/linux/mtd/sharpsl.h b/include/linux/mtd/sharpsl.h
index d2c3cf29e0d1..3762a90077d6 100644
--- a/include/linux/mtd/sharpsl.h
+++ b/include/linux/mtd/sharpsl.h
@@ -9,7 +9,7 @@
#define _MTD_SHARPSL_H
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
struct sharpsl_nand_platform_data {
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 12/20] mtd: nand: ecc-hamming: Clarify the driver descriptions
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (10 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 11/20] mtd: nand: ecc-hamming: Move Hamming code to the generic NAND layer Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 13/20] mtd: nand: ecc-hamming: Drop/fix the kernel doc Miquel Raynal
` (7 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
The include file pretends being the header for "ECC algorithm", while
it is just the header for the Hamming implementation. Make this clear
by rewording the sentence.
Do the same with the module description.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 2 +-
include/linux/mtd/nand-ecc-sw-hamming.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index 76966f5ff13f..a17faed374a8 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -481,4 +481,4 @@ EXPORT_SYMBOL(nand_correct_data);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Frans Meulenbroeks <fransmeulenbroeks@gmail.com>");
-MODULE_DESCRIPTION("Generic NAND ECC support");
+MODULE_DESCRIPTION("NAND software Hamming ECC support");
diff --git a/include/linux/mtd/nand-ecc-sw-hamming.h b/include/linux/mtd/nand-ecc-sw-hamming.h
index 30a0cfa50eed..85e9a929b5f9 100644
--- a/include/linux/mtd/nand-ecc-sw-hamming.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -4,7 +4,7 @@
* David Woodhouse <dwmw2@infradead.org>
* Thomas Gleixner <tglx@linutronix.de>
*
- * This file is the header for the ECC algorithm.
+ * This file is the header for the NAND Hamming ECC implementation.
*/
#ifndef __MTD_NAND_ECC_SW_HAMMING_H__
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 12/20] mtd: nand: ecc-hamming: Clarify the driver descriptions
2020-09-29 23:01 ` [PATCH 12/20] mtd: nand: ecc-hamming: Clarify the driver descriptions Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:16 UTC, Miquel Raynal wrote:
> The include file pretends being the header for "ECC algorithm", while
> it is just the header for the Hamming implementation. Make this clear
> by rewording the sentence.
>
> Do the same with the module description.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 13/20] mtd: nand: ecc-hamming: Drop/fix the kernel doc
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (11 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 12/20] mtd: nand: ecc-hamming: Clarify the driver descriptions Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 14/20] mtd: nand: ecc-hamming: Cleanup and style fixes Miquel Raynal
` (6 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Some functions should never have been exported (the ones prefixed by
__*), in this case simply drop the documentation, we never want
anybody to use this function from the outside.
For the other functions, enhance the style.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 39 ++++++++-----------------------
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index a17faed374a8..2f6f98557e82 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -112,14 +112,6 @@ static const char addressbits[256] = {
0x0e, 0x0e, 0x0f, 0x0f, 0x0e, 0x0e, 0x0f, 0x0f
};
-/**
- * __nand_calculate_ecc - [NAND Interface] Calculate 3-byte ECC for 256/512-byte
- * block
- * @buf: input buffer with raw data
- * @eccsize: data bytes per ECC step (256 or 512)
- * @code: output buffer with ECC
- * @sm_order: Smart Media byte ordering
- */
void __nand_calculate_ecc(const unsigned char *buf, unsigned int eccsize,
unsigned char *code, bool sm_order)
{
@@ -360,11 +352,10 @@ void __nand_calculate_ecc(const unsigned char *buf, unsigned int eccsize,
EXPORT_SYMBOL(__nand_calculate_ecc);
/**
- * nand_calculate_ecc - [NAND Interface] Calculate 3-byte ECC for 256/512-byte
- * block
- * @chip: NAND chip object
- * @buf: input buffer with raw data
- * @code: output buffer with ECC
+ * nand_calculate_ecc - Calculate 3-byte ECC for 256/512-byte block
+ * @chip: NAND chip object
+ * @buf: Input buffer with raw data
+ * @code: Output buffer with ECC
*/
int nand_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
unsigned char *code)
@@ -377,16 +368,6 @@ int nand_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
}
EXPORT_SYMBOL(nand_calculate_ecc);
-/**
- * __nand_correct_data - [NAND Interface] Detect and correct bit error(s)
- * @buf: raw data read from the chip
- * @read_ecc: ECC from the chip
- * @calc_ecc: the ECC calculated from raw data
- * @eccsize: data bytes per ECC step (256 or 512)
- * @sm_order: Smart Media byte order
- *
- * Detect and correct a 1 bit error for eccsize byte block
- */
int __nand_correct_data(unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc,
unsigned int eccsize, bool sm_order)
@@ -461,13 +442,13 @@ int __nand_correct_data(unsigned char *buf,
EXPORT_SYMBOL(__nand_correct_data);
/**
- * nand_correct_data - [NAND Interface] Detect and correct bit error(s)
- * @chip: NAND chip object
- * @buf: raw data read from the chip
- * @read_ecc: ECC from the chip
- * @calc_ecc: the ECC calculated from raw data
+ * nand_correct_data - Detect and correct bit error(s)
+ * @chip: NAND chip object
+ * @buf: Raw data read from the chip
+ * @read_ecc: ECC bytes read from the chip
+ * @calc_ecc: ECC calculated from the raw data
*
- * Detect and correct a 1 bit error for 256/512 byte block
+ * Detect and correct up to 1 bit error per 256/512-byte block.
*/
int nand_correct_data(struct nand_chip *chip, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc)
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 13/20] mtd: nand: ecc-hamming: Drop/fix the kernel doc
2020-09-29 23:01 ` [PATCH 13/20] mtd: nand: ecc-hamming: Drop/fix the kernel doc Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:17 UTC, Miquel Raynal wrote:
> Some functions should never have been exported (the ones prefixed by
> __*), in this case simply drop the documentation, we never want
> anybody to use this function from the outside.
>
> For the other functions, enhance the style.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 14/20] mtd: nand: ecc-hamming: Cleanup and style fixes
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (12 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 13/20] mtd: nand: ecc-hamming: Drop/fix the kernel doc Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 15/20] mtd: nand: ecc-hamming: Rename the exported functions Miquel Raynal
` (5 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Various style fixes.
There is not functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index 2f6f98557e82..771e27ed8883 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -115,19 +115,18 @@ static const char addressbits[256] = {
void __nand_calculate_ecc(const unsigned char *buf, unsigned int eccsize,
unsigned char *code, bool sm_order)
{
+ const u32 *bp = (uint32_t *)buf;
+ const u32 eccsize_mult = eccsize >> 8;
+ /* current value in buffer */
+ u32 cur;
+ /* rp0..rp17 are the various accumulated parities (per byte) */
+ u32 rp0, rp1, rp2, rp3, rp4, rp5, rp6, rp7, rp8, rp9, rp10, rp11, rp12,
+ rp13, rp14, rp15, rp16, rp17;
+ /* Cumulative parity for all data */
+ u32 par;
+ /* Cumulative parity at the end of the loop (rp12, rp14, rp16) */
+ u32 tmppar;
int i;
- const uint32_t *bp = (uint32_t *)buf;
- /* 256 or 512 bytes/ecc */
- const uint32_t eccsize_mult = eccsize >> 8;
- uint32_t cur; /* current value in buffer */
- /* rp0..rp15..rp17 are the various accumulated parities (per byte) */
- uint32_t rp0, rp1, rp2, rp3, rp4, rp5, rp6, rp7;
- uint32_t rp8, rp9, rp10, rp11, rp12, rp13, rp14, rp15, rp16;
- uint32_t rp17;
- uint32_t par; /* the cumulative parity for all data */
- uint32_t tmppar; /* the cumulative parity for this iteration;
- for rp12, rp14 and rp16 at the end of the
- loop */
par = 0;
rp4 = 0;
@@ -372,10 +371,9 @@ int __nand_correct_data(unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc,
unsigned int eccsize, bool sm_order)
{
+ const u32 eccsize_mult = eccsize >> 8;
unsigned char b0, b1, b2, bit_addr;
unsigned int byte_addr;
- /* 256 or 512 bytes/ecc */
- const uint32_t eccsize_mult = eccsize >> 8;
/*
* b0 to b2 indicate which bit is faulty (if any)
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 15/20] mtd: nand: ecc-hamming: Rename the exported functions
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (13 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 14/20] mtd: nand: ecc-hamming: Cleanup and style fixes Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 16/20] mtd: nand: ecc-hamming: Stop using raw NAND structures Miquel Raynal
` (4 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Prefix by ecc_sw_hamming_ the functions which should be internal only
but are exported for "raw" operations.
Prefix by nand_ecc_sw_hamming_ the other functions which will be used
in the context of the declaration of an Hamming proper ECC engine
object.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 53 +++++++++++++------------
drivers/mtd/nand/raw/cs553x_nand.c | 3 +-
drivers/mtd/nand/raw/fsmc_nand.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 2 +-
drivers/mtd/nand/raw/nand_base.c | 25 +++++++++++-
drivers/mtd/nand/raw/ndfc.c | 3 +-
drivers/mtd/nand/raw/sharpsl.c | 2 +-
drivers/mtd/nand/raw/tmio_nand.c | 6 +--
drivers/mtd/nand/raw/txx9ndfmc.c | 4 +-
drivers/mtd/sm_ftl.c | 28 ++++++-------
drivers/mtd/tests/mtd_nandecctest.c | 29 +++++++-------
include/linux/mtd/nand-ecc-sw-hamming.h | 38 ++++++------------
include/linux/mtd/rawnand.h | 7 ++++
13 files changed, 109 insertions(+), 93 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index 771e27ed8883..7ee0387ecb29 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -75,7 +75,7 @@ static const char bitsperbyte[256] = {
* addressbits is a lookup table to filter out the bits from the xor-ed
* ECC data that identify the faulty location.
* this is only used for repairing parity
- * see the comments in nand_correct_data for more details
+ * see the comments in nand_ecc_sw_hamming_correct for more details
*/
static const char addressbits[256] = {
0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01,
@@ -112,11 +112,11 @@ static const char addressbits[256] = {
0x0e, 0x0e, 0x0f, 0x0f, 0x0e, 0x0e, 0x0f, 0x0f
};
-void __nand_calculate_ecc(const unsigned char *buf, unsigned int eccsize,
- unsigned char *code, bool sm_order)
+int ecc_sw_hamming_calculate(const unsigned char *buf, unsigned int step_size,
+ unsigned char *code, bool sm_order)
{
const u32 *bp = (uint32_t *)buf;
- const u32 eccsize_mult = eccsize >> 8;
+ const u32 eccsize_mult = step_size >> 8;
/* current value in buffer */
u32 cur;
/* rp0..rp17 are the various accumulated parities (per byte) */
@@ -347,31 +347,32 @@ void __nand_calculate_ecc(const unsigned char *buf, unsigned int eccsize,
(invparity[par & 0x55] << 2) |
(invparity[rp17] << 1) |
(invparity[rp16] << 0);
+
+ return 0;
}
-EXPORT_SYMBOL(__nand_calculate_ecc);
+EXPORT_SYMBOL(ecc_sw_hamming_calculate);
/**
- * nand_calculate_ecc - Calculate 3-byte ECC for 256/512-byte block
- * @chip: NAND chip object
+ * nand_ecc_sw_hamming_calculate - Calculate 3-byte ECC for 256/512-byte block
+ * @nand: NAND device
* @buf: Input buffer with raw data
* @code: Output buffer with ECC
*/
-int nand_calculate_ecc(struct nand_chip *chip, const unsigned char *buf,
- unsigned char *code)
+int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
+ const unsigned char *buf, unsigned char *code)
{
+ struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
- __nand_calculate_ecc(buf, chip->ecc.size, code, sm_order);
-
- return 0;
+ return ecc_sw_hamming_calculate(buf, chip->ecc.size, code, sm_order);
}
-EXPORT_SYMBOL(nand_calculate_ecc);
+EXPORT_SYMBOL(nand_ecc_sw_hamming_calculate);
-int __nand_correct_data(unsigned char *buf,
- unsigned char *read_ecc, unsigned char *calc_ecc,
- unsigned int eccsize, bool sm_order)
+int ecc_sw_hamming_correct(unsigned char *buf, unsigned char *read_ecc,
+ unsigned char *calc_ecc, unsigned int step_size,
+ bool sm_order)
{
- const u32 eccsize_mult = eccsize >> 8;
+ const u32 eccsize_mult = step_size >> 8;
unsigned char b0, b1, b2, bit_addr;
unsigned int byte_addr;
@@ -437,26 +438,28 @@ int __nand_correct_data(unsigned char *buf,
pr_err("%s: uncorrectable ECC error\n", __func__);
return -EBADMSG;
}
-EXPORT_SYMBOL(__nand_correct_data);
+EXPORT_SYMBOL(ecc_sw_hamming_correct);
/**
- * nand_correct_data - Detect and correct bit error(s)
- * @chip: NAND chip object
+ * nand_ecc_sw_hamming_correct - Detect and correct bit error(s)
+ * @nand: NAND device
* @buf: Raw data read from the chip
* @read_ecc: ECC bytes read from the chip
* @calc_ecc: ECC calculated from the raw data
*
* Detect and correct up to 1 bit error per 256/512-byte block.
*/
-int nand_correct_data(struct nand_chip *chip, unsigned char *buf,
- unsigned char *read_ecc, unsigned char *calc_ecc)
+int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc)
{
+ struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
- return __nand_correct_data(buf, read_ecc, calc_ecc, chip->ecc.size,
- sm_order);
+ return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, chip->ecc.size,
+ sm_order);
}
-EXPORT_SYMBOL(nand_correct_data);
+EXPORT_SYMBOL(nand_ecc_sw_hamming_correct);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Frans Meulenbroeks <fransmeulenbroeks@gmail.com>");
diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c
index 7c492096426b..b066dcae31ab 100644
--- a/drivers/mtd/nand/raw/cs553x_nand.c
+++ b/drivers/mtd/nand/raw/cs553x_nand.c
@@ -19,7 +19,6 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/iopoll.h>
@@ -291,7 +290,7 @@ static int __init cs553x_init_one(int cs, int mmio, unsigned long adr)
this->ecc.bytes = 3;
this->ecc.hwctl = cs_enable_hwecc;
this->ecc.calculate = cs_calculate_ecc;
- this->ecc.correct = nand_correct_data;
+ this->ecc.correct = rawnand_sw_hamming_correct;
this->ecc.strength = 1;
/* Enable the following for a flash based bad block table */
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index cb41d527bee0..efd422201e54 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -904,7 +904,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
case NAND_ECC_ENGINE_TYPE_ON_HOST:
dev_info(host->dev, "Using 1-bit HW ECC scheme\n");
nand->ecc.calculate = fsmc_read_hwecc_ecc1;
- nand->ecc.correct = nand_correct_data;
+ nand->ecc.correct = rawnand_sw_hamming_correct;
nand->ecc.bytes = 3;
nand->ecc.strength = 1;
nand->ecc.options |= NAND_ECC_SOFT_HAMMING_SM_ORDER;
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index 0f395cc7f101..2bf8e85578a3 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -893,7 +893,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
chip->ecc.write_oob = lpc32xx_nand_write_oob_syndrome;
chip->ecc.read_oob = lpc32xx_nand_read_oob_syndrome;
chip->ecc.calculate = lpc32xx_nand_ecc_calculate;
- chip->ecc.correct = nand_correct_data;
+ chip->ecc.correct = rawnand_sw_hamming_correct;
chip->ecc.strength = 1;
chip->ecc.hwctl = lpc32xx_nand_ecc_enable;
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index a8aaedd940cd..07a5ceb8bf39 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5144,6 +5144,27 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
kfree(chip->parameters.onfi);
}
+int rawnand_sw_hamming_calculate(struct nand_chip *chip,
+ const unsigned char *buf,
+ unsigned char *code)
+{
+ struct nand_device *base = &chip->base;
+
+ return nand_ecc_sw_hamming_calculate(base, buf, code);
+}
+EXPORT_SYMBOL(rawnand_sw_hamming_calculate);
+
+int rawnand_sw_hamming_correct(struct nand_chip *chip,
+ unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc)
+{
+ struct nand_device *base = &chip->base;
+
+ return nand_ecc_sw_hamming_correct(base, buf, read_ecc, calc_ecc);
+}
+EXPORT_SYMBOL(rawnand_sw_hamming_correct);
+
int rawnand_sw_bch_init(struct nand_chip *chip)
{
struct nand_device *base = &chip->base;
@@ -5268,8 +5289,8 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
switch (ecc->algo) {
case NAND_ECC_ALGO_HAMMING:
- ecc->calculate = nand_calculate_ecc;
- ecc->correct = nand_correct_data;
+ ecc->calculate = rawnand_sw_hamming_calculate;
+ ecc->correct = rawnand_sw_hamming_correct;
ecc->read_page = nand_read_page_swecc;
ecc->read_subpage = nand_read_subpage;
ecc->write_page = nand_write_page_swecc;
diff --git a/drivers/mtd/nand/raw/ndfc.c b/drivers/mtd/nand/raw/ndfc.c
index 8cda6633280b..338d6b1a189e 100644
--- a/drivers/mtd/nand/raw/ndfc.c
+++ b/drivers/mtd/nand/raw/ndfc.c
@@ -18,7 +18,6 @@
*/
#include <linux/module.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/ndfc.h>
#include <linux/slab.h>
@@ -146,7 +145,7 @@ static int ndfc_chip_init(struct ndfc_controller *ndfc,
chip->controller = &ndfc->ndfc_control;
chip->legacy.read_buf = ndfc_read_buf;
chip->legacy.write_buf = ndfc_write_buf;
- chip->ecc.correct = nand_correct_data;
+ chip->ecc.correct = rawnand_sw_hamming_correct;
chip->ecc.hwctl = ndfc_enable_hwecc;
chip->ecc.calculate = ndfc_calculate_ecc;
chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST;
diff --git a/drivers/mtd/nand/raw/sharpsl.c b/drivers/mtd/nand/raw/sharpsl.c
index 553ffb61b7e1..da0621c44e86 100644
--- a/drivers/mtd/nand/raw/sharpsl.c
+++ b/drivers/mtd/nand/raw/sharpsl.c
@@ -164,7 +164,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
this->badblock_pattern = data->badblock_pattern;
this->ecc.hwctl = sharpsl_nand_enable_hwecc;
this->ecc.calculate = sharpsl_nand_calculate_ecc;
- this->ecc.correct = nand_correct_data;
+ this->ecc.correct = rawnand_sw_hamming_correct;
/* Scan to find existence of the device */
err = nand_scan(this, 1);
diff --git a/drivers/mtd/nand/raw/tmio_nand.c b/drivers/mtd/nand/raw/tmio_nand.c
index cd3733c3ae04..fc331e734898 100644
--- a/drivers/mtd/nand/raw/tmio_nand.c
+++ b/drivers/mtd/nand/raw/tmio_nand.c
@@ -292,11 +292,11 @@ static int tmio_nand_correct_data(struct nand_chip *chip, unsigned char *buf,
int r0, r1;
/* assume ecc.size = 512 and ecc.bytes = 6 */
- r0 = __nand_correct_data(buf, read_ecc, calc_ecc, 256, false);
+ r0 = rawnand_sw_hamming_correct(chip, buf, read_ecc, calc_ecc);
if (r0 < 0)
return r0;
- r1 = __nand_correct_data(buf + 256, read_ecc + 3, calc_ecc + 3, 256,
- false);
+ r1 = rawnand_sw_hamming_correct(chip, buf + 256, read_ecc + 3,
+ calc_ecc + 3);
if (r1 < 0)
return r1;
return r0 + r1;
diff --git a/drivers/mtd/nand/raw/txx9ndfmc.c b/drivers/mtd/nand/raw/txx9ndfmc.c
index ade0bfd2648d..5919d2bb222a 100644
--- a/drivers/mtd/nand/raw/txx9ndfmc.c
+++ b/drivers/mtd/nand/raw/txx9ndfmc.c
@@ -194,8 +194,8 @@ static int txx9ndfmc_correct_data(struct nand_chip *chip, unsigned char *buf,
int stat;
for (eccsize = chip->ecc.size; eccsize > 0; eccsize -= 256) {
- stat = __nand_correct_data(buf, read_ecc, calc_ecc, 256,
- false);
+ stat = rawnand_sw_hamming_correct(chip, buf, read_ecc,
+ calc_ecc);
if (stat < 0)
return stat;
corrected += stat;
diff --git a/drivers/mtd/sm_ftl.c b/drivers/mtd/sm_ftl.c
index db430ae6a1a2..4d1ae25507ab 100644
--- a/drivers/mtd/sm_ftl.c
+++ b/drivers/mtd/sm_ftl.c
@@ -216,20 +216,19 @@ static void sm_break_offset(struct sm_ftl *ftl, loff_t loffset,
static int sm_correct_sector(uint8_t *buffer, struct sm_oob *oob)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
uint8_t ecc[3];
- __nand_calculate_ecc(buffer, SM_SMALL_PAGE, ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
- if (__nand_correct_data(buffer, ecc, oob->ecc1, SM_SMALL_PAGE,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC)) < 0)
+ ecc_sw_hamming_calculate(buffer, SM_SMALL_PAGE, ecc, sm_order);
+ if (ecc_sw_hamming_correct(buffer, ecc, oob->ecc1, SM_SMALL_PAGE,
+ sm_order) < 0)
return -EIO;
buffer += SM_SMALL_PAGE;
- __nand_calculate_ecc(buffer, SM_SMALL_PAGE, ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
- if (__nand_correct_data(buffer, ecc, oob->ecc2, SM_SMALL_PAGE,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC)) < 0)
+ ecc_sw_hamming_calculate(buffer, SM_SMALL_PAGE, ecc, sm_order);
+ if (ecc_sw_hamming_correct(buffer, ecc, oob->ecc2, SM_SMALL_PAGE,
+ sm_order) < 0)
return -EIO;
return 0;
}
@@ -369,6 +368,7 @@ static int sm_write_block(struct sm_ftl *ftl, uint8_t *buf,
int zone, int block, int lba,
unsigned long invalid_bitmap)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
struct sm_oob oob;
int boffset;
int retry = 0;
@@ -395,13 +395,13 @@ static int sm_write_block(struct sm_ftl *ftl, uint8_t *buf,
}
if (ftl->smallpagenand) {
- __nand_calculate_ecc(buf + boffset, SM_SMALL_PAGE,
- oob.ecc1,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
+ ecc_sw_hamming_calculate(buf + boffset,
+ SM_SMALL_PAGE, oob.ecc1,
+ sm_order);
- __nand_calculate_ecc(buf + boffset + SM_SMALL_PAGE,
- SM_SMALL_PAGE, oob.ecc2,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
+ ecc_sw_hamming_calculate(buf + boffset + SM_SMALL_PAGE,
+ SM_SMALL_PAGE, oob.ecc2,
+ sm_order);
}
if (!sm_write_sector(ftl, zone, block, boffset,
buf + boffset, &oob))
diff --git a/drivers/mtd/tests/mtd_nandecctest.c b/drivers/mtd/tests/mtd_nandecctest.c
index e92e3fb287b6..c4f271314f52 100644
--- a/drivers/mtd/tests/mtd_nandecctest.c
+++ b/drivers/mtd/tests/mtd_nandecctest.c
@@ -119,13 +119,13 @@ static void no_bit_error(void *error_data, void *error_ecc,
static int no_bit_error_verify(void *error_data, void *error_ecc,
void *correct_data, const size_t size)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
unsigned char calc_ecc[3];
int ret;
- __nand_calculate_ecc(error_data, size, calc_ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
- ret = __nand_correct_data(error_data, error_ecc, calc_ecc, size,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
+ ecc_sw_hamming_calculate(error_data, size, calc_ecc, sm_order);
+ ret = ecc_sw_hamming_correct(error_data, error_ecc, calc_ecc, size,
+ sm_order);
if (ret == 0 && !memcmp(correct_data, error_data, size))
return 0;
@@ -149,13 +149,13 @@ static void single_bit_error_in_ecc(void *error_data, void *error_ecc,
static int single_bit_error_correct(void *error_data, void *error_ecc,
void *correct_data, const size_t size)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
unsigned char calc_ecc[3];
int ret;
- __nand_calculate_ecc(error_data, size, calc_ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
- ret = __nand_correct_data(error_data, error_ecc, calc_ecc, size,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
+ ecc_sw_hamming_calculate(error_data, size, calc_ecc, sm_order);
+ ret = ecc_sw_hamming_correct(error_data, error_ecc, calc_ecc, size,
+ sm_order);
if (ret == 1 && !memcmp(correct_data, error_data, size))
return 0;
@@ -186,13 +186,13 @@ static void double_bit_error_in_ecc(void *error_data, void *error_ecc,
static int double_bit_error_detect(void *error_data, void *error_ecc,
void *correct_data, const size_t size)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
unsigned char calc_ecc[3];
int ret;
- __nand_calculate_ecc(error_data, size, calc_ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
- ret = __nand_correct_data(error_data, error_ecc, calc_ecc, size,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
+ ecc_sw_hamming_calculate(error_data, size, calc_ecc, sm_order);
+ ret = ecc_sw_hamming_correct(error_data, error_ecc, calc_ecc, size,
+ sm_order);
return (ret == -EBADMSG) ? 0 : -EINVAL;
}
@@ -248,6 +248,7 @@ static void dump_data_ecc(void *error_data, void *error_ecc, void *correct_data,
static int nand_ecc_test_run(const size_t size)
{
+ bool sm_order = IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC);
int i;
int err = 0;
void *error_data;
@@ -266,9 +267,7 @@ static int nand_ecc_test_run(const size_t size)
}
prandom_bytes(correct_data, size);
- __nand_calculate_ecc(correct_data, size, correct_ecc,
- IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC));
-
+ ecc_sw_hamming_calculate(correct_data, size, correct_ecc, sm_order);
for (i = 0; i < ARRAY_SIZE(nand_ecc_test); i++) {
nand_ecc_test[i].prepare(error_data, error_ecc,
correct_data, correct_ecc, size);
diff --git a/include/linux/mtd/nand-ecc-sw-hamming.h b/include/linux/mtd/nand-ecc-sw-hamming.h
index 85e9a929b5f9..84a123bf45f3 100644
--- a/include/linux/mtd/nand-ecc-sw-hamming.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -10,30 +10,18 @@
#ifndef __MTD_NAND_ECC_SW_HAMMING_H__
#define __MTD_NAND_ECC_SW_HAMMING_H__
-struct nand_chip;
-
-/*
- * Calculate 3 byte ECC code for eccsize byte block
- */
-void __nand_calculate_ecc(const u_char *dat, unsigned int eccsize,
- u_char *ecc_code, bool sm_order);
-
-/*
- * Calculate 3 byte ECC code for 256/512 byte block
- */
-int nand_calculate_ecc(struct nand_chip *chip, const u_char *dat,
- u_char *ecc_code);
-
-/*
- * Detect and correct a 1 bit error for eccsize byte block
- */
-int __nand_correct_data(u_char *dat, u_char *read_ecc, u_char *calc_ecc,
- unsigned int eccsize, bool sm_order);
-
-/*
- * Detect and correct a 1 bit error for 256/512 byte block
- */
-int nand_correct_data(struct nand_chip *chip, u_char *dat, u_char *read_ecc,
- u_char *calc_ecc);
+#include <linux/mtd/nand.h>
+
+int ecc_sw_hamming_calculate(const unsigned char *buf, unsigned int step_size,
+ unsigned char *code, bool sm_order);
+int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
+ const unsigned char *buf,
+ unsigned char *code);
+int ecc_sw_hamming_correct(unsigned char *buf, unsigned char *read_ecc,
+ unsigned char *calc_ecc, unsigned int step_size,
+ bool sm_order);
+int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc);
#endif /* __MTD_NAND_ECC_SW_HAMMING_H__ */
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 15743c2c2cab..685d24557e95 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1301,6 +1301,13 @@ static inline int nand_opcode_8bits(unsigned int command)
return 0;
}
+int rawnand_sw_hamming_calculate(struct nand_chip *chip,
+ const unsigned char *buf,
+ unsigned char *code);
+int rawnand_sw_hamming_correct(struct nand_chip *chip,
+ unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc);
int rawnand_sw_bch_init(struct nand_chip *chip);
int rawnand_sw_bch_correct(struct nand_chip *chip, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc);
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 16/20] mtd: nand: ecc-hamming: Stop using raw NAND structures
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (14 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 15/20] mtd: nand: ecc-hamming: Rename the exported functions Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 17/20] mtd: nand: ecc-hamming: Remove useless includes Miquel Raynal
` (3 subsequent siblings)
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
This code is meant to be reused by the SPI-NAND core. Now that the
driver has been cleaned and reorganized, use a generic ECC engine
object to store the driver's data instead of accessing members of the
nand_chip structure. This means adding proper init/cleanup helpers.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 17 ++++---
drivers/mtd/nand/raw/nand_base.c | 63 +++++++++++++++++++++++--
include/linux/mtd/nand-ecc-sw-hamming.h | 20 ++++++++
include/linux/mtd/rawnand.h | 2 +
4 files changed, 90 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index 7ee0387ecb29..9cd70b4637c1 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -17,8 +17,6 @@
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/rawnand.h>
#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <asm/byteorder.h>
@@ -361,10 +359,11 @@ EXPORT_SYMBOL(ecc_sw_hamming_calculate);
int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
const unsigned char *buf, unsigned char *code)
{
- struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
- bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
+ struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv;
+ unsigned int step_size = nand->ecc.ctx.conf.step_size;
- return ecc_sw_hamming_calculate(buf, chip->ecc.size, code, sm_order);
+ return ecc_sw_hamming_calculate(buf, step_size, code,
+ engine_conf->sm_order);
}
EXPORT_SYMBOL(nand_ecc_sw_hamming_calculate);
@@ -453,11 +452,11 @@ int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
unsigned char *read_ecc,
unsigned char *calc_ecc)
{
- struct nand_chip *chip = mtd_to_nand(nanddev_to_mtd(nand));
- bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
+ struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv;
+ unsigned int step_size = nand->ecc.ctx.conf.step_size;
- return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, chip->ecc.size,
- sm_order);
+ return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, step_size,
+ engine_conf->sm_order);
}
EXPORT_SYMBOL(nand_ecc_sw_hamming_correct);
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 07a5ceb8bf39..95dede09481b 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5144,6 +5144,46 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
kfree(chip->parameters.onfi);
}
+int rawnand_sw_hamming_init(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_sw_hamming_conf *engine_conf;
+ struct nand_device *base = &chip->base;
+
+ base->ecc.user_conf.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+ base->ecc.user_conf.algo = NAND_ECC_ALGO_HAMMING;
+ base->ecc.user_conf.strength = chip->ecc.strength;
+ base->ecc.user_conf.step_size = chip->ecc.size;
+
+ if (base->ecc.user_conf.strength != 1 ||
+ (base->ecc.user_conf.step_size != 256 &&
+ base->ecc.user_conf.step_size != 512)) {
+ pr_err("%s: unsupported strength or step size\n", __func__);
+ return -EINVAL;
+ }
+
+ engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
+ if (!engine_conf)
+ return -ENOMEM;
+
+ engine_conf->code_size = 3;
+ engine_conf->nsteps = mtd->writesize / base->ecc.user_conf.step_size;
+
+ if (chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER)
+ engine_conf->sm_order = true;
+
+ base->ecc.ctx.priv = engine_conf;
+
+ chip->ecc.size = base->ecc.ctx.conf.step_size;
+ chip->ecc.strength = base->ecc.ctx.conf.strength;
+ chip->ecc.total = base->ecc.ctx.total;
+ chip->ecc.steps = engine_conf->nsteps;
+ chip->ecc.bytes = engine_conf->code_size;
+
+ return 0;
+}
+EXPORT_SYMBOL(rawnand_sw_hamming_init);
+
int rawnand_sw_hamming_calculate(struct nand_chip *chip,
const unsigned char *buf,
unsigned char *code)
@@ -5165,6 +5205,14 @@ int rawnand_sw_hamming_correct(struct nand_chip *chip,
}
EXPORT_SYMBOL(rawnand_sw_hamming_correct);
+void rawnand_sw_hamming_cleanup(struct nand_chip *chip)
+{
+ struct nand_device *base = &chip->base;
+
+ kfree(base->ecc.ctx.priv);
+}
+EXPORT_SYMBOL(rawnand_sw_hamming_cleanup);
+
int rawnand_sw_bch_init(struct nand_chip *chip)
{
struct nand_device *base = &chip->base;
@@ -5308,6 +5356,12 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
if (IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC))
ecc->options |= NAND_ECC_SOFT_HAMMING_SM_ORDER;
+ ret = rawnand_sw_hamming_init(chip);
+ if (ret) {
+ WARN(1, "Hamming ECC initialization failed!\n");
+ return ret;
+ }
+
return 0;
case NAND_ECC_ALGO_BCH:
if (!IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)) {
@@ -6001,9 +6055,12 @@ EXPORT_SYMBOL(nand_scan_with_ids);
*/
void nand_cleanup(struct nand_chip *chip)
{
- if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
- chip->ecc.algo == NAND_ECC_ALGO_BCH)
- rawnand_sw_bch_cleanup(chip);
+ if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT) {
+ if (chip->ecc.algo == NAND_ECC_ALGO_HAMMING)
+ rawnand_sw_hamming_cleanup(chip);
+ else if (chip->ecc.algo == NAND_ECC_ALGO_BCH)
+ rawnand_sw_bch_cleanup(chip);
+ }
nanddev_cleanup(&chip->base);
diff --git a/include/linux/mtd/nand-ecc-sw-hamming.h b/include/linux/mtd/nand-ecc-sw-hamming.h
index 84a123bf45f3..9d4b4d623741 100644
--- a/include/linux/mtd/nand-ecc-sw-hamming.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -12,6 +12,26 @@
#include <linux/mtd/nand.h>
+/**
+ * struct nand_ecc_sw_hamming_conf - private software Hamming ECC engine structure
+ * @reqooblen: Save the actual user OOB length requested before overwriting it
+ * @spare_oobbuf: Spare OOB buffer if none is provided
+ * @code_size: Number of bytes needed to store a code (one code per step)
+ * @nsteps: Number of steps
+ * @calc_buf: Buffer to use when calculating ECC bytes
+ * @code_buf: Buffer to use when reading (raw) ECC bytes from the chip
+ * @sm_order: Smart Media special ordering
+ */
+struct nand_ecc_sw_hamming_conf {
+ unsigned int reqooblen;
+ void *spare_oobbuf;
+ unsigned int code_size;
+ unsigned int nsteps;
+ u8 *calc_buf;
+ u8 *code_buf;
+ unsigned int sm_order;
+};
+
int ecc_sw_hamming_calculate(const unsigned char *buf, unsigned int step_size,
unsigned char *code, bool sm_order);
int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 685d24557e95..0a90a8792d18 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1301,6 +1301,7 @@ static inline int nand_opcode_8bits(unsigned int command)
return 0;
}
+int rawnand_sw_hamming_init(struct nand_chip *chip);
int rawnand_sw_hamming_calculate(struct nand_chip *chip,
const unsigned char *buf,
unsigned char *code);
@@ -1308,6 +1309,7 @@ int rawnand_sw_hamming_correct(struct nand_chip *chip,
unsigned char *buf,
unsigned char *read_ecc,
unsigned char *calc_ecc);
+void rawnand_sw_hamming_cleanup(struct nand_chip *chip);
int rawnand_sw_bch_init(struct nand_chip *chip);
int rawnand_sw_bch_correct(struct nand_chip *chip, unsigned char *buf,
unsigned char *read_ecc, unsigned char *calc_ecc);
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 16/20] mtd: nand: ecc-hamming: Stop using raw NAND structures
2020-09-29 23:01 ` [PATCH 16/20] mtd: nand: ecc-hamming: Stop using raw NAND structures Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:20 UTC, Miquel Raynal wrote:
> This code is meant to be reused by the SPI-NAND core. Now that the
> driver has been cleaned and reorganized, use a generic ECC engine
> object to store the driver's data instead of accessing members of the
> nand_chip structure. This means adding proper init/cleanup helpers.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 17/20] mtd: nand: ecc-hamming: Remove useless includes
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (15 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 16/20] mtd: nand: ecc-hamming: Stop using raw NAND structures Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 18/20] mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselected Miquel Raynal
` (2 subsequent siblings)
19 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Most of the includes are simply useless, drop them.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
arch/arm/mach-s3c24xx/common-smdk.c | 1 -
arch/arm/mach-s3c24xx/mach-anubis.c | 1 -
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 -
arch/arm/mach-s3c24xx/mach-bast.c | 1 -
arch/arm/mach-s3c24xx/mach-gta02.c | 1 -
arch/arm/mach-s3c24xx/mach-jive.c | 1 -
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 -
arch/arm/mach-s3c24xx/mach-osiris.c | 1 -
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 -
arch/arm/mach-s3c24xx/mach-rx3715.c | 1 -
arch/arm/mach-s3c24xx/mach-vstms.c | 1 -
drivers/mtd/nand/raw/fsl_elbc_nand.c | 1 -
drivers/mtd/nand/raw/fsl_ifc_nand.c | 1 -
drivers/mtd/nand/raw/fsl_upm.c | 1 -
drivers/mtd/nand/raw/fsmc_nand.c | 1 -
drivers/mtd/nand/raw/lpc32xx_mlc.c | 1 -
drivers/mtd/nand/raw/lpc32xx_slc.c | 1 -
drivers/mtd/nand/raw/pasemi_nand.c | 1 -
drivers/mtd/nand/raw/s3c2410.c | 1 -
drivers/mtd/nand/raw/sharpsl.c | 1 -
drivers/mtd/nand/raw/tmio_nand.c | 1 -
drivers/mtd/nand/raw/txx9ndfmc.c | 1 -
include/linux/mtd/sharpsl.h | 1 -
23 files changed, 23 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/common-smdk.c b/arch/arm/mach-s3c24xx/common-smdk.c
index 72e9b87acbc6..d604e510ff5f 100644
--- a/arch/arm/mach-s3c24xx/common-smdk.c
+++ b/arch/arm/mach-s3c24xx/common-smdk.c
@@ -20,7 +20,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/io.h>
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index 190f22574cff..dc850e85ba5a 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -36,7 +36,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <net/ax88796.h>
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index 87257c54140d..cb67deb5b8c8 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -37,7 +37,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/devs.h>
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index fa947bf881fe..09758200fda2 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -24,7 +24,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/platform_data/asoc-s3c24xx_simtec.h>
diff --git a/arch/arm/mach-s3c24xx/mach-gta02.c b/arch/arm/mach-s3c24xx/mach-gta02.c
index ef23402fdef5..f713b76c1aa4 100644
--- a/arch/arm/mach-s3c24xx/mach-gta02.c
+++ b/arch/arm/mach-s3c24xx/mach-gta02.c
@@ -36,7 +36,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 49c3ea18b88f..3a974d303f1b 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -40,7 +40,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/gpio-cfg.h>
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index 0d18fea49004..8b65dca3eb74 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -46,7 +46,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/gpio-cfg.h>
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 592fc67b9ffe..57cb2d3ba74f 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -33,7 +33,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index d75d03cf6623..71356f36a5ac 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -21,7 +21,6 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-s3c24xx/mach-rx3715.c b/arch/arm/mach-s3c24xx/mach-rx3715.c
index 9daf78d963ee..151b4a75c495 100644
--- a/arch/arm/mach-s3c24xx/mach-rx3715.c
+++ b/arch/arm/mach-s3c24xx/mach-rx3715.c
@@ -22,7 +22,6 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index df30ebc02b38..4f8a1809f123 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -16,7 +16,6 @@
#include <linux/io.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/memblock.h>
diff --git a/drivers/mtd/nand/raw/fsl_elbc_nand.c b/drivers/mtd/nand/raw/fsl_elbc_nand.c
index eb255cf83e32..aab93b9e6052 100644
--- a/drivers/mtd/nand/raw/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_elbc_nand.c
@@ -22,7 +22,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <asm/io.h>
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c
index e3e3b2abb6cd..0f64b7e704c2 100644
--- a/drivers/mtd/nand/raw/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c
@@ -15,7 +15,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/fsl_ifc.h>
#include <linux/iopoll.h>
diff --git a/drivers/mtd/nand/raw/fsl_upm.c b/drivers/mtd/nand/raw/fsl_upm.c
index 3824361928a1..b3cc427100a2 100644
--- a/drivers/mtd/nand/raw/fsl_upm.c
+++ b/drivers/mtd/nand/raw/fsl_upm.c
@@ -11,7 +11,6 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/mtd.h>
#include <linux/of_platform.h>
diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index efd422201e54..d0855d4f5627 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -26,7 +26,6 @@
#include <linux/types.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/mtd/partitions.h>
diff --git a/drivers/mtd/nand/raw/lpc32xx_mlc.c b/drivers/mtd/nand/raw/lpc32xx_mlc.c
index b9ccf6f2f9c6..bd854e044898 100644
--- a/drivers/mtd/nand/raw/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_mlc.c
@@ -31,7 +31,6 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#define DRV_NAME "lpc32xx_mlc"
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index 2bf8e85578a3..e98ab22f9047 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -23,7 +23,6 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/gpio.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
diff --git a/drivers/mtd/nand/raw/pasemi_nand.c b/drivers/mtd/nand/raw/pasemi_nand.c
index 108e3817737a..7e9d711d5a8a 100644
--- a/drivers/mtd/nand/raw/pasemi_nand.c
+++ b/drivers/mtd/nand/raw/pasemi_nand.c
@@ -14,7 +14,6 @@
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
diff --git a/drivers/mtd/nand/raw/s3c2410.c b/drivers/mtd/nand/raw/s3c2410.c
index f7eb3b5fa792..cb2d1b4e278c 100644
--- a/drivers/mtd/nand/raw/s3c2410.c
+++ b/drivers/mtd/nand/raw/s3c2410.c
@@ -30,7 +30,6 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
diff --git a/drivers/mtd/nand/raw/sharpsl.c b/drivers/mtd/nand/raw/sharpsl.c
index da0621c44e86..6ceb961d2c9f 100644
--- a/drivers/mtd/nand/raw/sharpsl.c
+++ b/drivers/mtd/nand/raw/sharpsl.c
@@ -12,7 +12,6 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/sharpsl.h>
#include <linux/interrupt.h>
diff --git a/drivers/mtd/nand/raw/tmio_nand.c b/drivers/mtd/nand/raw/tmio_nand.c
index fc331e734898..31e5e50e77e2 100644
--- a/drivers/mtd/nand/raw/tmio_nand.c
+++ b/drivers/mtd/nand/raw/tmio_nand.c
@@ -35,7 +35,6 @@
#include <linux/ioport.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/slab.h>
diff --git a/drivers/mtd/nand/raw/txx9ndfmc.c b/drivers/mtd/nand/raw/txx9ndfmc.c
index 5919d2bb222a..5f3dbff60d47 100644
--- a/drivers/mtd/nand/raw/txx9ndfmc.c
+++ b/drivers/mtd/nand/raw/txx9ndfmc.c
@@ -14,7 +14,6 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
#include <linux/io.h>
#include <linux/platform_data/txx9/ndfmc.h>
diff --git a/include/linux/mtd/sharpsl.h b/include/linux/mtd/sharpsl.h
index 3762a90077d6..231bd1c3f408 100644
--- a/include/linux/mtd/sharpsl.h
+++ b/include/linux/mtd/sharpsl.h
@@ -9,7 +9,6 @@
#define _MTD_SHARPSL_H
#include <linux/mtd/rawnand.h>
-#include <linux/mtd/nand-ecc-sw-hamming.h>
#include <linux/mtd/partitions.h>
struct sharpsl_nand_platform_data {
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 18/20] mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselected
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (16 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 17/20] mtd: nand: ecc-hamming: Remove useless includes Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:29 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 19/20] mtd: nand: ecc-hamming: Create the software Hamming engine Miquel Raynal
2020-09-29 23:01 ` [PATCH 20/20] mtd: nand: Let software ECC engines be retrieved from the NAND core Miquel Raynal
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
There is no reason to always embed the software Hamming ECC engine
implementation. By default it is (with raw NAND), but we can let the
user decide.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/Kconfig | 11 +++++++-
drivers/mtd/nand/raw/Kconfig | 2 +-
include/linux/mtd/nand-ecc-sw-hamming.h | 36 +++++++++++++++++++++++++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 306c33ca3448..15ffe1a1b863 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -16,7 +16,16 @@ config MTD_NAND_ECC
depends on MTD_NAND_CORE
config MTD_NAND_ECC_SW_HAMMING
- bool
+ bool "Software Hamming ECC engine"
+ default y if MTD_RAW_NAND
+ select MTD_NAND_ECC
+ help
+ This enables support for software Hamming error
+ correction. This correction can correct up to 1 bit error
+ per chunk and detect up to 2 bit errors. While it used to be
+ widely used with old parts, newer NAND chips usually require
+ more strength correction and in this case BCH or RS will be
+ preferred.
config MTD_NAND_ECC_SW_HAMMING_SMC
bool "NAND ECC Smart Media byte order"
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 6149096e32cb..cc86d6e4e042 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -3,7 +3,6 @@ menuconfig MTD_RAW_NAND
tristate "Raw/Parallel NAND Device Support"
select MTD_NAND_CORE
select MTD_NAND_ECC
- select MTD_NAND_ECC_SW_HAMMING
help
This enables support for accessing all type of raw/parallel
NAND flash devices. For further information see
@@ -72,6 +71,7 @@ config MTD_NAND_AU1550
config MTD_NAND_NDFC
tristate "IBM/MCC 4xx NAND controller"
depends on 4xx
+ select MTD_NAND_ECC_SW_HAMMING
select MTD_NAND_ECC_SW_HAMMING_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/include/linux/mtd/nand-ecc-sw-hamming.h b/include/linux/mtd/nand-ecc-sw-hamming.h
index 9d4b4d623741..5a39e96c3546 100644
--- a/include/linux/mtd/nand-ecc-sw-hamming.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -32,6 +32,8 @@ struct nand_ecc_sw_hamming_conf {
unsigned int sm_order;
};
+#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
+
int ecc_sw_hamming_calculate(const unsigned char *buf, unsigned int step_size,
unsigned char *code, bool sm_order);
int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
@@ -44,4 +46,38 @@ int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
unsigned char *read_ecc,
unsigned char *calc_ecc);
+#else /* !CONFIG_MTD_NAND_ECC_SW_HAMMING */
+
+static inline int ecc_sw_hamming_calculate(const unsigned char *buf,
+ unsigned int step_size,
+ unsigned char *code, bool sm_order)
+{
+ return -ENOTSUPP;
+}
+
+static inline int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
+ const unsigned char *buf,
+ unsigned char *code)
+{
+ return -ENOTSUPP;
+}
+
+static inline int ecc_sw_hamming_correct(unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc,
+ unsigned int step_size, bool sm_order)
+{
+ return -ENOTSUPP;
+}
+
+static inline int nand_ecc_sw_hamming_correct(struct nand_device *nand,
+ unsigned char *buf,
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc)
+{
+ return -ENOTSUPP;
+}
+
+#endif /* CONFIG_MTD_NAND_ECC_SW_HAMMING */
+
#endif /* __MTD_NAND_ECC_SW_HAMMING_H__ */
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 18/20] mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselected
2020-09-29 23:01 ` [PATCH 18/20] mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselected Miquel Raynal
@ 2020-10-30 17:29 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:29 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:22 UTC, Miquel Raynal wrote:
> There is no reason to always embed the software Hamming ECC engine
> implementation. By default it is (with raw NAND), but we can let the
> user decide.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 19/20] mtd: nand: ecc-hamming: Create the software Hamming engine
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (17 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 18/20] mtd: nand: ecc-hamming: Let the software Hamming ECC engine be unselected Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:28 ` Miquel Raynal
2020-09-29 23:01 ` [PATCH 20/20] mtd: nand: Let software ECC engines be retrieved from the NAND core Miquel Raynal
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Let's continue introducing the generic ECC engine abstraction in the
NAND subsystem by instantiating a second ECC engine: software
Hamming.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc-sw-hamming.c | 191 ++++++++++++++++++++++++
drivers/mtd/nand/raw/nand_base.c | 26 ++--
include/linux/mtd/nand-ecc-sw-hamming.h | 16 +-
include/linux/mtd/nand.h | 9 ++
4 files changed, 221 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/nand/ecc-sw-hamming.c b/drivers/mtd/nand/ecc-sw-hamming.c
index 9cd70b4637c1..334e619b35c9 100644
--- a/drivers/mtd/nand/ecc-sw-hamming.c
+++ b/drivers/mtd/nand/ecc-sw-hamming.c
@@ -17,7 +17,9 @@
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/nand-ecc-sw-hamming.h>
+#include <linux/slab.h>
#include <asm/byteorder.h>
/*
@@ -460,6 +462,195 @@ int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
}
EXPORT_SYMBOL(nand_ecc_sw_hamming_correct);
+int nand_ecc_sw_hamming_init_ctx(struct nand_device *nand)
+{
+ struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
+ struct nand_ecc_sw_hamming_conf *engine_conf;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int ret;
+
+ if (!mtd->ooblayout) {
+ switch (mtd->oobsize) {
+ case 8:
+ case 16:
+ mtd_set_ooblayout(mtd, nand_get_small_page_ooblayout());
+ break;
+ case 64:
+ case 128:
+ mtd_set_ooblayout(mtd,
+ nand_get_large_page_hamming_ooblayout());
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+ }
+
+ conf->engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+ conf->algo = NAND_ECC_ALGO_HAMMING;
+ conf->step_size = nand->ecc.user_conf.step_size;
+ conf->strength = 1;
+
+ /* Use the strongest configuration by default */
+ if (conf->step_size != 256 && conf->step_size != 512)
+ conf->step_size = 256;
+
+ engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
+ if (!engine_conf)
+ return -ENOMEM;
+
+ ret = nand_ecc_init_req_tweaking(&engine_conf->req_ctx, nand);
+ if (ret)
+ goto free_engine_conf;
+
+ engine_conf->code_size = 3;
+ engine_conf->nsteps = mtd->writesize / conf->step_size;
+ engine_conf->calc_buf = kzalloc(sizeof(mtd->oobsize), GFP_KERNEL);
+ engine_conf->code_buf = kzalloc(sizeof(mtd->oobsize), GFP_KERNEL);
+ if (!engine_conf->calc_buf || !engine_conf->code_buf) {
+ ret = -ENOMEM;
+ goto free_bufs;
+ }
+
+ nand->ecc.ctx.priv = engine_conf;
+ nand->ecc.ctx.total = engine_conf->nsteps * engine_conf->code_size;
+
+ return 0;
+
+free_bufs:
+ nand_ecc_cleanup_req_tweaking(&engine_conf->req_ctx);
+ kfree(engine_conf->calc_buf);
+ kfree(engine_conf->code_buf);
+free_engine_conf:
+ kfree(engine_conf);
+
+ return ret;
+}
+EXPORT_SYMBOL(nand_ecc_sw_hamming_init_ctx);
+
+void nand_ecc_sw_hamming_cleanup_ctx(struct nand_device *nand)
+{
+ struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv;
+
+ if (engine_conf) {
+ nand_ecc_cleanup_req_tweaking(&engine_conf->req_ctx);
+ kfree(engine_conf->calc_buf);
+ kfree(engine_conf->code_buf);
+ kfree(engine_conf);
+ }
+}
+EXPORT_SYMBOL(nand_ecc_sw_hamming_cleanup_ctx);
+
+static int nand_ecc_sw_hamming_prepare_io_req(struct nand_device *nand,
+ struct nand_page_io_req *req)
+{
+ struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int eccsize = nand->ecc.ctx.conf.step_size;
+ int eccbytes = engine_conf->code_size;
+ int eccsteps = engine_conf->nsteps;
+ int total = nand->ecc.ctx.total;
+ u8 *ecccalc = engine_conf->calc_buf;
+ const u8 *data = req->databuf.out;
+ int i;
+
+ /* Nothing to do for a raw operation */
+ if (req->mode == MTD_OPS_RAW)
+ return 0;
+
+ /* This engine does not provide BBM/free OOB bytes protection */
+ if (!req->datalen)
+ return 0;
+
+ nand_ecc_tweak_req(&engine_conf->req_ctx, req);
+
+ /* No more preparation for page read */
+ if (req->type == NAND_PAGE_READ)
+ return 0;
+
+ /* Preparation for page write: derive the ECC bytes and place them */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, data += eccsize)
+ nand_ecc_sw_hamming_calculate(nand, data, &ecccalc[i]);
+
+ return mtd_ooblayout_set_eccbytes(mtd, ecccalc, (void *)req->oobbuf.out,
+ 0, total);
+}
+
+static int nand_ecc_sw_hamming_finish_io_req(struct nand_device *nand,
+ struct nand_page_io_req *req)
+{
+ struct nand_ecc_sw_hamming_conf *engine_conf = nand->ecc.ctx.priv;
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int eccsize = nand->ecc.ctx.conf.step_size;
+ int total = nand->ecc.ctx.total;
+ int eccbytes = engine_conf->code_size;
+ int eccsteps = engine_conf->nsteps;
+ u8 *ecccalc = engine_conf->calc_buf;
+ u8 *ecccode = engine_conf->code_buf;
+ unsigned int max_bitflips = 0;
+ u8 *data = req->databuf.in;
+ int i, ret;
+
+ /* Nothing to do for a raw operation */
+ if (req->mode == MTD_OPS_RAW)
+ return 0;
+
+ /* This engine does not provide BBM/free OOB bytes protection */
+ if (!req->datalen)
+ return 0;
+
+ /* No more preparation for page write */
+ if (req->type == NAND_PAGE_WRITE) {
+ nand_ecc_restore_req(&engine_conf->req_ctx, req);
+ return 0;
+ }
+
+ /* Finish a page read: retrieve the (raw) ECC bytes*/
+ ret = mtd_ooblayout_get_eccbytes(mtd, ecccode, req->oobbuf.in, 0,
+ total);
+ if (ret)
+ return ret;
+
+ /* Calculate the ECC bytes */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, data += eccsize)
+ nand_ecc_sw_hamming_calculate(nand, data, &ecccalc[i]);
+
+ /* Finish a page read: compare and correct */
+ for (eccsteps = engine_conf->nsteps, i = 0, data = req->databuf.in;
+ eccsteps;
+ eccsteps--, i += eccbytes, data += eccsize) {
+ int stat = nand_ecc_sw_hamming_correct(nand, data,
+ &ecccode[i],
+ &ecccalc[i]);
+ if (stat < 0) {
+ mtd->ecc_stats.failed++;
+ } else {
+ mtd->ecc_stats.corrected += stat;
+ max_bitflips = max_t(unsigned int, max_bitflips, stat);
+ }
+ }
+
+ nand_ecc_restore_req(&engine_conf->req_ctx, req);
+
+ return max_bitflips;
+}
+
+static struct nand_ecc_engine_ops nand_ecc_sw_hamming_engine_ops = {
+ .init_ctx = nand_ecc_sw_hamming_init_ctx,
+ .cleanup_ctx = nand_ecc_sw_hamming_cleanup_ctx,
+ .prepare_io_req = nand_ecc_sw_hamming_prepare_io_req,
+ .finish_io_req = nand_ecc_sw_hamming_finish_io_req,
+};
+
+static struct nand_ecc_engine nand_ecc_sw_hamming_engine = {
+ .ops = &nand_ecc_sw_hamming_engine_ops,
+};
+
+struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void)
+{
+ return &nand_ecc_sw_hamming_engine;
+}
+EXPORT_SYMBOL(nand_ecc_sw_hamming_get_engine);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Frans Meulenbroeks <fransmeulenbroeks@gmail.com>");
MODULE_DESCRIPTION("NAND software Hamming ECC support");
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 95dede09481b..9a29d207c56b 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5146,34 +5146,24 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
int rawnand_sw_hamming_init(struct nand_chip *chip)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
struct nand_ecc_sw_hamming_conf *engine_conf;
struct nand_device *base = &chip->base;
+ int ret;
base->ecc.user_conf.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
base->ecc.user_conf.algo = NAND_ECC_ALGO_HAMMING;
base->ecc.user_conf.strength = chip->ecc.strength;
base->ecc.user_conf.step_size = chip->ecc.size;
- if (base->ecc.user_conf.strength != 1 ||
- (base->ecc.user_conf.step_size != 256 &&
- base->ecc.user_conf.step_size != 512)) {
- pr_err("%s: unsupported strength or step size\n", __func__);
- return -EINVAL;
- }
+ ret = nand_ecc_sw_hamming_init_ctx(base);
+ if (ret)
+ return ret;
- engine_conf = kzalloc(sizeof(*engine_conf), GFP_KERNEL);
- if (!engine_conf)
- return -ENOMEM;
-
- engine_conf->code_size = 3;
- engine_conf->nsteps = mtd->writesize / base->ecc.user_conf.step_size;
+ engine_conf = base->ecc.ctx.priv;
if (chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER)
engine_conf->sm_order = true;
- base->ecc.ctx.priv = engine_conf;
-
chip->ecc.size = base->ecc.ctx.conf.step_size;
chip->ecc.strength = base->ecc.ctx.conf.strength;
chip->ecc.total = base->ecc.ctx.total;
@@ -5209,7 +5199,7 @@ void rawnand_sw_hamming_cleanup(struct nand_chip *chip)
{
struct nand_device *base = &chip->base;
- kfree(base->ecc.ctx.priv);
+ nand_ecc_sw_hamming_cleanup_ctx(base);
}
EXPORT_SYMBOL(rawnand_sw_hamming_cleanup);
@@ -5738,7 +5728,9 @@ static int nand_scan_tail(struct nand_chip *chip)
*/
if (!mtd->ooblayout &&
!(ecc->engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
- ecc->algo == NAND_ECC_ALGO_BCH)) {
+ ecc->algo == NAND_ECC_ALGO_BCH) &&
+ !(ecc->engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
+ ecc->algo == NAND_ECC_ALGO_HAMMING)) {
switch (mtd->oobsize) {
case 8:
case 16:
diff --git a/include/linux/mtd/nand-ecc-sw-hamming.h b/include/linux/mtd/nand-ecc-sw-hamming.h
index 5a39e96c3546..9f9073d86ff3 100644
--- a/include/linux/mtd/nand-ecc-sw-hamming.h
+++ b/include/linux/mtd/nand-ecc-sw-hamming.h
@@ -14,8 +14,8 @@
/**
* struct nand_ecc_sw_hamming_conf - private software Hamming ECC engine structure
- * @reqooblen: Save the actual user OOB length requested before overwriting it
- * @spare_oobbuf: Spare OOB buffer if none is provided
+ * @req_ctx: Save request context and tweak the original request to fit the
+ * engine needs
* @code_size: Number of bytes needed to store a code (one code per step)
* @nsteps: Number of steps
* @calc_buf: Buffer to use when calculating ECC bytes
@@ -23,8 +23,7 @@
* @sm_order: Smart Media special ordering
*/
struct nand_ecc_sw_hamming_conf {
- unsigned int reqooblen;
- void *spare_oobbuf;
+ struct nand_ecc_req_tweak_ctx req_ctx;
unsigned int code_size;
unsigned int nsteps;
u8 *calc_buf;
@@ -34,6 +33,8 @@ struct nand_ecc_sw_hamming_conf {
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
+int nand_ecc_sw_hamming_init_ctx(struct nand_device *nand);
+void nand_ecc_sw_hamming_cleanup_ctx(struct nand_device *nand);
int ecc_sw_hamming_calculate(const unsigned char *buf, unsigned int step_size,
unsigned char *code, bool sm_order);
int nand_ecc_sw_hamming_calculate(struct nand_device *nand,
@@ -48,6 +49,13 @@ int nand_ecc_sw_hamming_correct(struct nand_device *nand, unsigned char *buf,
#else /* !CONFIG_MTD_NAND_ECC_SW_HAMMING */
+static inline int nand_ecc_sw_hamming_init_ctx(struct nand_device *nand)
+{
+ return -ENOTSUPP;
+}
+
+static inline void nand_ecc_sw_hamming_cleanup_ctx(struct nand_device *nand) {}
+
static inline int ecc_sw_hamming_calculate(const unsigned char *buf,
unsigned int step_size,
unsigned char *code, bool sm_order)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index df8548187713..3616fa27eaa1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -278,6 +278,15 @@ int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
bool nand_ecc_is_strong_enough(struct nand_device *nand);
+#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
+struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
+#else
+static inline struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void)
+{
+ return NULL;
+}
+#endif /* CONFIG_MTD_NAND_ECC_SW_HAMMING */
+
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_BCH)
struct nand_ecc_engine *nand_ecc_sw_bch_get_engine(void);
#else
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* [PATCH 20/20] mtd: nand: Let software ECC engines be retrieved from the NAND core
2020-09-29 23:01 [PATCH 00/20] Create generic software ECC engines Miquel Raynal
` (18 preceding siblings ...)
2020-09-29 23:01 ` [PATCH 19/20] mtd: nand: ecc-hamming: Create the software Hamming engine Miquel Raynal
@ 2020-09-29 23:01 ` Miquel Raynal
2020-10-30 17:28 ` Miquel Raynal
19 siblings, 1 reply; 69+ messages in thread
From: Miquel Raynal @ 2020-09-29 23:01 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni, Miquel Raynal
Before making use of the ECC engines, we must retrieve them. Add the
boilerplate for the ones already available: software engines (Hamming
and BCH).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 20 ++++++++++++++++++++
include/linux/mtd/nand.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index 86bbc4ecc58a..a85269b03b2f 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -585,6 +585,26 @@ void nand_ecc_restore_req(struct nand_ecc_req_tweak_ctx *ctx,
}
EXPORT_SYMBOL_GPL(nand_ecc_restore_req);
+struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand)
+{
+ unsigned int algo = nand->ecc.user_conf.algo;
+
+ if (algo == NAND_ECC_ALGO_UNKNOWN)
+ algo = nand->ecc.defaults.algo;
+
+ switch (algo) {
+ case NAND_ECC_ALGO_HAMMING:
+ return nand_ecc_sw_hamming_get_engine();
+ case NAND_ECC_ALGO_BCH:
+ return nand_ecc_sw_bch_get_engine();
+ default:
+ break;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(nand_ecc_get_sw_engine);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 3616fa27eaa1..f78f61c9a9ee 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -277,6 +277,7 @@ int nand_ecc_prepare_io_req(struct nand_device *nand,
int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
bool nand_ecc_is_strong_enough(struct nand_device *nand);
+struct nand_ecc_engine *nand_ecc_get_sw_engine(struct nand_device *nand);
#if IS_ENABLED(CONFIG_MTD_NAND_ECC_SW_HAMMING)
struct nand_ecc_engine *nand_ecc_sw_hamming_get_engine(void);
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH 20/20] mtd: nand: Let software ECC engines be retrieved from the NAND core
2020-09-29 23:01 ` [PATCH 20/20] mtd: nand: Let software ECC engines be retrieved from the NAND core Miquel Raynal
@ 2020-10-30 17:28 ` Miquel Raynal
0 siblings, 0 replies; 69+ messages in thread
From: Miquel Raynal @ 2020-10-30 17:28 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Tudor Ambarus, linux-mtd
Cc: Julien Su, ycllin, Thomas Petazzoni
On Tue, 2020-09-29 at 23:01:24 UTC, Miquel Raynal wrote:
> Before making use of the ECC engines, we must retrieve them. Add the
> boilerplate for the ones already available: software engines (Hamming
> and BCH).
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 69+ messages in thread