[Yaffs] bit error rates --> a vendor speaks

[Thomas Gleixner]

On Tue, 2006-02-21 at 11:40 +1300, Charles Manning wrote:
> Just going for the lowest common denominator all the time is like saying "run 
> all serial links at 9600 and never use 115200 because 115200 might not be 
> supported on all possible serial links", or "you can't run an ftdi USB serial 
> port at 230k because most PC serial ports only go up to 115200".

Again, the comparison is still flawed. 

The worst serial device still guarantees a baudrate > 0 and the
effective baudrate has no impact on data storage size.

> The benefits of good clean interfaces are modularity. If you were to write a 
> nand driver from scratch that obeys the interface then you can use it with 
> mtdpart, mtdconcat, various fs etc. This is the major reason I don't like to 
> have oobinfo hanging through the interface.

I'm well aware of interface design, but I see no convincing argument not
to remove oob access at all. At least there is no in kernel user
essentially depending on it. Making JFFS2 oob independend is a no brain
patch.

> OK I got that wrong. I don't have the specs for the device you're looking at 
> so I can't see all the details.

Simply as I said. Standard NAND interface, no oob access. Well, I can
read the raw device (including OOB) for diagnostic purposes in a special
mode.

> > > I lose no sleep that it does not work with YAFFS.
> >
> > Wake up please. Thats going to be reality for NAND based stuff in the
> > future. The controllers will expose the raw FLASH but claim the OOB area
> > for their own purpose - hardware based error correction.
> 
> Yes that is so for a few parts like OneNAND etc as well as some modules. 
> However, there's still a lot of NAND out there that will provide OOB.

That's no reason to keep a dead thing alive. There are still a lot of
cars which need leaded fuel. I dont see any gas station providing it
within a 100km range.

> Perhaps opening up YAFFS to those people would be valuable. Would you like to 
> see YAFFS run on your non-oob board?

At least for a test.

> I guess it could also make YAFFS easier to use for NOR people. Currently NOR 
> folks have to do quite a bit of trickery. Enough people do this for me to 
> think this could be valuable.

:)

> However, if that happens I'd still like to be able to use OOB if it is there 
> (just like I want to be able to use 115200 if it is there) because OOB can 
> make a more efficient fs with page alignment etc.

Go back to top - and as you said before:
> > Already, many people replace nand_base.c for performance reasons.

Nobody is going to prevent this, so they can expose any interface they
want for their private performance gain. 

	tglx