[PATCH v7 4/7] mtd: nand: gpmi: may use minimum required ecc

[Bean Huo 霍斌斌 (beanhuo)]

> > > By default NAND driver will choose the highest ecc strength that oob
> > > could contain, in this case, for some 8K+744 NAND flash, the ecc
> > > strength will be up to 52bit, which beyonds the i.MX6QDL BCH capability
> (40bit).
> >
> >
> > For normal working environment, if hardware BCH ECC cannot meet NAND
> > ecc requirement, We can set a minimum required ecc strength, and file
> system refresh/scrub can control bitflips under NAND ecc strength. But during
> reflow solder, it is very possible that NAND bitflips may increase over your
> hardware BCH capability, I don't know how this controller handle this?
> > For example, NAND require 80bit ECC, but hardware BCH ECC can only hold
> 40bit.
> > After reflow, there are some blocks that bitflips over 40bit.
> 
> if the minimum ecc strength read from NAND ONFI parameter exceeds the
> BCH ECC capability, the NAND driver quits and reports unsupport NAND chip.

Current Linux already set ECC strength according to NAND minimum required ECC that read
from ONFI table. So if NAND minimum required ECC is 60bit, but this BCH controller can only hold 40bit,
NAND driver quits? Why not transfer to use software BCH ECC? 

> Do you mean reflow solder may change the NAND minimum required ECC
> strength, in other word, the actual minimum ECC may larger than it said in
> NAND chip SPEC?

NAND minimum required ECC does not changed because of reflow.
I mean that if hardware BCH ECC Can not meet nand minimum required ECC, during normal working, we can set
ECC strength according to Your hardware ECC capability. 
for example in this case, NAND minimum required ECC is 60bit, but hardware ECC capability Is 40bit, during normal working,
we can set ECC strength according to 40bit, this can work, it will definitely increase PE cycle.
But for reflow operation, there are some blocks that their bitflips will increase over your hardware ECC 40bit, so how do you handle this?
Or you don't meet this case?



> --
> Best Regards,
> 
> Han "Allen" Xu