On Friday 10 December 2004 11:55, Thomas Gleixner wrote:
> On Thu, 2004-12-09 at 21:10 +0000, Nick Bane wrote:
> > That is precisely what I do and I comment out the MTD whinge.
> > It is clearly important that SOMEONE does the ECC and it is a
> > mild pity that the MTD layer assumes that only it is competant to do so.
>
> It's not a pity. It's correct. If you do software ECC, fine. If you have
> hardware ECC then it _CAN_ only be done in the MTD layer. The filesystem
> layer does not know anything about the available hardware. So it makes
> totaly sense that ECC is done in the MTD/NAND layer and nowhere else.
>
> A filesystem is a filesystem and is not competent to fiddle around with
> hardware. I know that there are OS targets for YAFFS where YAFFS has to
> do everything, but MTD does it the right way.

I might argue the latter point here. I believe the ECC byte ordering 
calculated by SJHill's nand_ecc.c is wrong.   yaffs_ecc.c can calculate this 
ECC order or the SmartMedia "correct" order.  yaffs_ecc.c is also slightly 
faster than nand_ecc.c ;-).

I don't think I have a gripe with the ECC stuff, it's the write verification 
that gets me.

>
> > It is probably that yaffs should get the MTD layer to do its ecc
> > eventually as standard.
>
> Can you please explain this statement to somebody who's native language
> is German ?
>
> What do you mean ?
> Fix YAFFS or hack MTD ?

From my understanding this is only a configuration issue.

YAFFS can be build with CONFIG_YAFFS_USE_NAND_ECC which means yaffs won't do 
ECC - it lets mtd do all ECC. This is, IMHO, the best way to do things with 
Linux - particularly if there are other non-yaffs users of the NAND.

With non-Linux usage, I recommend using yaffs_ecc.c if software ECC is 
required.

Where things do break down a bit is with mkyaffs which does calculate ECC. 
You need to be careful to use a consistent ECC strategy.