CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC

[David Peverley]

Hi all,

I've noticed that some of the problems we see are exacerbated further
by us having CONFIG_MTD_NAND_VERIFY_WRITE enabled. In the case where
blocks have occasional 1-bit ECC failures (i.e. normally correctable
and not enough to warrant marking as bad) the generic verify routine
will cause nand_write_page() to return failure. I've prototyped a
verify routine that uses an ECC corrected read in our driver and it
seems to do the job correctly.

I think that there's a good argument to address this by changing the
generic verify routine(s) by doing something along the lines of the
following :

static uint8_t readbackbuf[NAND_MAX_PAGESIZE];

static int nand_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
{
    int err;
    struct nand_chip *chip = mtd->priv;

    /* Read back page using ECC read */
    err = chip->ecc.read_page(mtd, this, readbackbuf_ecc);
    if (err < 0) {
        printk(KERN_NOTICE "nand_verify_buf: ERROR: ecc.read_page() failed.\n");
        return -EFAULT;
    }

    if (memcmp(readbackbuf, buf, len) != 0)
        return -EFAULT;

    return 0;
}

which would use the appropriate page read mechanism based on what was
configured as a result of ecc.mode. Does this make sense to you guys?
If so I'll put together a patch to submit. This would also
nand_verify_buf16() becomes obsolete as the bus width differences are
taken care of within the call to read_page().

Of course it adds a little more overhead but will avoid writes failing
and possibly causing some blocks to be marked as bad before their
time...

Cheers,

~Pev