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

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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