[PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum

[PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum

[Ahmed Naseef]

The ECC engine strictly validates that flash OOB size equals exactly
64 bytes. However, some NAND chips have a larger physical OOB while
vendor firmware only uses the first 64 bytes for the ECC layout. For
example the Macronix MX35LF1G24AD found in the Netlink HG323DAC has
128 byte physical OOB but vendor firmware only uses the first 64
bytes (24 bytes free + 40 bytes BCH6 parity), leaving bytes 64-127
unused.

Since the engine only operates on the first 64 bytes of OOB
regardless of the physical size, change the check from exact match
to minimum size. Flash with OOB >= 64 bytes works correctly with
the engine's 64-byte layout.

Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
On the Netlink HG323DAC with the Macronix MX35LF1G24AD (ID: 0xc2,
0x14), the Realtek ECC engine probe fails with:

  spi-nand spi0.0: Macronix SPI NAND was found.
  spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
  rtl-nand-ecc-engine 1801a600.ecc: only flash geometry data=2048, oob=64 supported
  nand: No suitable ECC configuration
  spi-nand spi0.0: probe with driver spi-nand failed with error -22

The chip has 128 bytes of physical OOB but the OEM firmware only uses
64 bytes (24 free + 40 BCH6 parity). The OEM bootlog confirms:

  nand: device found, Manufacturer ID: 0xc2, Chip ID: 0x14
  nand: Macronix
  nand: 128MiB, SLC, page size: 2048, OOB size: 64

The rtl9607c GPL sources have no specific entry for chip ID 0x14 in
the Macronix SPI NAND table and fall back to the default 64-byte
spare configuration with BCH6 ECC.

I verified this by booting an OpenWrt initramfs with the ECC engine
disabled and inspecting raw OOB via nanddump --noecc --oob. Both
the env and kernel partitions confirm the OEM layout uses only the
first 64 bytes:

  - OOB[0:23]:   24 bytes free  (4 steps x 6 bytes)
  - OOB[24:63]:  40 bytes BCH6 parity (4 steps x 10 bytes)
  - OOB[64:127]: unused (all 0xFF)

This matches the engine's expected format exactly. Since the engine
only operates on the first 64 bytes, the relaxation from exact match
to minimum size is safe for any flash with OOB >= 64.

 drivers/mtd/nand/ecc-realtek.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/ecc-realtek.c b/drivers/mtd/nand/ecc-realtek.c
index 0046da37e..9e2d15252 100644
--- a/drivers/mtd/nand/ecc-realtek.c
+++ b/drivers/mtd/nand/ecc-realtek.c
@@ -20,7 +20,9 @@
  * are only two known devices in the wild that have NAND flash and make use of this ECC engine
  * (Linksys LGS328C & LGS352C). To keep compatibility with vendor firmware, new modes can only
  * be added when new data layouts have been analyzed. For now allow BCH6 on flash with 2048 byte
- * blocks and 64 bytes oob.
+ * blocks and at least 64 bytes oob. Some NAND chips (e.g. Macronix MX35LF1G24AD) have a
+ * physical OOB size of 128 bytes but vendor firmware only uses the first 64 bytes for the ECC
+ * layout. The engine operates on the first 64 bytes of OOB only; any extra bytes are unused.
  *
  * This driver aligns with kernel ECC naming conventions. Neverthless a short notice on the
  * Realtek naming conventions for the different structures in the OOB area.
@@ -39,7 +41,7 @@
  */
 
 #define RTL_ECC_ALLOWED_PAGE_SIZE 	2048
-#define RTL_ECC_ALLOWED_OOB_SIZE	64
+#define RTL_ECC_ALLOWED_MIN_OOB_SIZE	64
 #define RTL_ECC_ALLOWED_STRENGTH	6
 
 #define RTL_ECC_BLOCK_SIZE 		512
@@ -310,10 +312,10 @@ static int rtl_ecc_check_support(struct nand_device *nand)
 	struct mtd_info *mtd = nanddev_to_mtd(nand);
 	struct device *dev = nand->ecc.engine->dev;
 
-	if (mtd->oobsize != RTL_ECC_ALLOWED_OOB_SIZE ||
+	if (mtd->oobsize < RTL_ECC_ALLOWED_MIN_OOB_SIZE ||
 	    mtd->writesize != RTL_ECC_ALLOWED_PAGE_SIZE) {
-		dev_err(dev, "only flash geometry data=%d, oob=%d supported\n",
-			RTL_ECC_ALLOWED_PAGE_SIZE, RTL_ECC_ALLOWED_OOB_SIZE);
+		dev_err(dev, "only flash geometry data=%d, oob>=%d supported\n",
+			RTL_ECC_ALLOWED_PAGE_SIZE, RTL_ECC_ALLOWED_MIN_OOB_SIZE);
 		return -EINVAL;
 	}
 
-- 
2.34.1

RE: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum

[markus.stockhausen]

Hi Ahmed,

thanks for that finding.

> Von: Ahmed Naseef <naseefkm@gmail.com> 
> Gesendet: Freitag, 6. Februar 2026 11:58
> Betreff: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum
>
> ...
>
> Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
> Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>

IIRC this should be the other way round.

> ...
>  * are only two known devices in the wild that have NAND flash and make use of this ECC engine
>  * (Linksys LGS328C & LGS352C). To keep compatibility with vendor firmware, new modes can only

Now it is more than these two devices. Please adapt the whole description so it
gives a consistent explanation.

Markus

Re: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum

[Ahmed Naseef]

On Fri, Feb 06, 2026 at 12:11:20PM +0100, markus.stockhausen@gmx.de wrote:

Hi Markus,

Thanks for the review.

> Hi Ahmed,
> 
> thanks for that finding.
> 
> > Von: Ahmed Naseef <naseefkm@gmail.com> 
> > Gesendet: Freitag, 6. Februar 2026 11:58
> > Betreff: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum
> >
> > ...
> >
> > Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
> > Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
> 
> IIRC this should be the other way round.
> 
Could you clarify what you meant by "the other way round" — do you
mean the ordering of the Suggested-by/Signed-off-by tags, or the
attribution itself?
> > ...
> >  * are only two known devices in the wild that have NAND flash and make use of this ECC engine
> >  * (Linksys LGS328C & LGS352C). To keep compatibility with vendor firmware, new modes can only
> 
> Now it is more than these two devices. Please adapt the whole description so it
> gives a consistent explanation.
> 
Regarding the comment about the two known devices — I was planning
to update it to something like:

    * It can run for arbitrary NAND flash chips with different block and OOB sizes. Currently there
    * are a few known devices in the wild that have NAND flash and make use of this ECC engine
    * (Linksys LGS328C, LGS352C & Netlink HG323DAC). To keep compatibility with vendor firmware,
    * new modes can only be added when new data layouts have been analyzed. For now allow BCH6 on
    * flash with 2048 byte blocks and at least 64 bytes oob.Some NAND chips (e.g. Macronix 
    * MX35LF1G24AD) have a physical OOB size of 128 bytes but vendor firmware only uses the first
    * 64 bytes for the ECC layout. The engine operates on the first 64 bytes of OOB only; any extra
    * bytes are unused.

Does that look reasonable to you, or would you prefer a different wording?

I'll send a v2 once I have your feedback.

Thanks,
Ahmed Naseef

AW: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum

[markus.stockhausen]

> Von: Ahmed Naseef <naseefkm@gmail.com> 
> An: markus.stockhausen@gmx.de
> Betreff: Re: [PATCH] mtd: nand: realtek-ecc: relax OOB size check to minimum
> ...
> > > Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
> > > Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
> > 
> > IIRC this should be the other way round.
> > 
> Could you clarify what you meant by "the other way round" — do you
> mean the ordering of the Suggested-by/Signed-off-by tags, or the
> attribution itself?

The one who had the patch in his/her hands last, must be on the bottom 
of the list. Chronological order so to say.

> Regarding the comment about the two known devices — I was planning
> to update it to something like:

    * It can run for arbitrary NAND flash chips with different block and OOB sizes. Currently there
    * are a few known devices in the wild that make use of this ECC engine
    * (Linksys LGS328C, LGS352C & Netlink HG323DAC). To keep compatibility with vendor firmware,
    * new modes can only be added when new data layouts have been analyzed. For now allow BCH6 on
    * flash with 2048 byte blocks and at least 64 bytes oob. Some vendors make use of
    * 128 bytes OOB NAND chips (e.g. Macronix MX35LF1G24AD) but only use BCH6 and thus the first
    * 64 bytes of the OOB area. In this case the engine leaves any extra bytes unused.

Small adaptions fromm y side in the comment above. Check for spelling 
mistakes and line lengths. With this good to go from my side.

Markus