mtd: rawnand: xway: No hardcoded ECC engine for Micron Chips

Some lantiq xway devices use Micron NAND chips, which use on-die ECC. The hardcoded setting of NAND_ECC_ENGINE_TYPE_SOFT makes them unusable, because the software ECC on top of the hardware ECC produces errors for every read and write access, not to mention that booting does not work,

because the boot loader uses the correct ECC when trying to load the kernel and stops loading on severe ECC errors.
Removing the hardcoded settings would break a number of devices that work with those settings.
Adding a DTB property was considered, but did not work, because devices of the same type but from different manufacture dates have different NAND chips and as such it is not possible to determine the NAND chip in advance or device specific.

Signed-off-by Daniel Kestrel <[email protected]>

---
 drivers/mtd/nand/raw/xway_nand.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/mtd/nand/raw/xway_nand.c +1 -0

index 26751976e502..20cb5ce2f3b0 100644
@@ -10,6 +10,7 @@
 #include <linux/of_platform.h>
 
 #include <lantiq_soc.h>
+#include "internals.h"
 
 /* nand registers */
 #define EBU_ADDSEL1		0x24

Hi Daniel,

Daniel Kestrel <[email protected]> wrote on Tue, 3 Aug 2021 16:32:56 +0200:

Quoted 4 lines

Some lantiq xway devices use Micron NAND chips, which use on-die ECC. The hardcoded setting of NAND_ECC_ENGINE_TYPE_SOFT makes them unusable, because the software ECC on top of the hardware ECC produces errors for every read and write access, not to mention that booting does not work,

Quoted 8 lines

because the boot loader uses the correct ECC when trying to load the kernel and stops loading on severe ECC errors.
Removing the hardcoded settings would break a number of devices that work with those settings.
Adding a DTB property was considered, but did not work, because devices of the same type but from different manufacture dates have different NAND chips and as such it is not possible to determine the NAND chip in advance or device specific.

I understand the problem and it is a very crappy situation.

Quoted 19 lines

Signed-off-by Daniel Kestrel <[email protected]>

---
 drivers/mtd/nand/raw/xway_nand.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/mtd/nand/raw/xway_nand.c +1 -0

index 26751976e502..20cb5ce2f3b0 100644
@@ -10,6 +10,7 @@
 #include <linux/of_platform.h>
 
 #include <lantiq_soc.h>
+#include "internals.h"
 
 /* nand registers */
 #define EBU_ADDSEL1          0x24

drivers/mtd/nand/raw/xway_nand.c static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len) · line 153

Quoted 6 lines

drivers/mtd/nand/raw/xway_nand.c +2 -1

@@ -148,7 +149,8 @@ static void xway_write_buf(struct nand_chip *chip, const u_char *buf, int len)
 
 static int xway_attach_chip(struct nand_chip *chip)
 {
-     chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
+     if (chip->manufacturer.desc->id != NAND_MFR_MICRON)
+             chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;

Could we make this a little bit clever with something like this:
https://elixir.bootlin.com/linux/v5.13-rc7/source/drivers/mtd/nand/raw/nand_micron.c#L434

This is far from ideal, there should definitely be a change in the DT. But given your initial comments I guess it is not possible.

Anyway I don't find a better way as, during the attach() call, we don't yet ran the manufacturer code, hence we don't know if on-die ECC is actually available or not.

Thanks,
Miquèl