oh - sorry, I was looking at the fix-uboot branch when I said that
master implemented the same behaviour I see on 1006cb3. I see that
master does do things differently, and inband tags don't seem to
influence the interpretation of read errors.

I'll probably change my code to ignore the value of tags->ecc_result,
but I would be grateful if anyone could enlighten me regarding the
history here (the git logs aren't helping me).

Regards,
Dunk

On 28 September 2015 at 14:36, Duncan Palmer <dpalmer@digisoft.tv> wrote:
> Hi guys,
>
> I'm testing a vendors nand driver using yaffs with inband tags
> enabled. I was surprised to discover that yaffs doesn't mark blocks
> which consistently fail to read with unrecoverable ECC errors as bad.
> On closer inspection, I see that yaffs would mark these blocks as bad,
> if I were not using inband tags. The following code from
> yaffs_mtdif2.c seems to be to be behind this behaviour (I'm using
> 1006cb3, but this is present at the HEAD of master as well);
>
>     if (tags && retval == -EBADMSG && tags->ecc_result ==
> YAFFS_ECC_RESULT_NO_ERROR) {
>         tags->ecc_result = YAFFS_ECC_RESULT_UNFIXED;
>         dev->n_ecc_unfixed++;
>     }
>     if(tags && retval == -EUCLEAN && tags->ecc_result ==
> YAFFS_ECC_RESULT_NO_ERROR) {
>         tags->ecc_result = YAFFS_ECC_RESULT_FIXED;
>         dev->n_ecc_fixed++;
>     }
>
> When using inband tags, tags->ecc_result is never assigned to, hence
> it's always YAFFS_ECC_RESULT_UNKNOWN, and so n_ecc_unfixed and
> n_ecc_fixed are never incremented.
>
> If there some reason things are implemented this way? I see someone
> else came across this a couple of years back, but there were no
> replies to his message -
> http://www.aleph1.co.uk/lurker/message/20120716.182456.29a5ea4f.en.html
>
> Regards,
> Dunk