[PATCH,RFC] [MTD] replace MTD_NORFLASH with MTD_GENERIC_TYPE

Jörn Engel joern at wohnheim.fh-wedel.de
Tue May 30 11:50:01 EDT 2006


On Tue, 30 May 2006 16:40:20 +0100, David Woodhouse wrote:
> On Tue, 2006-05-30 at 17:24 +0200, Jörn Engel wrote:
> > Apart from the text substitution, the STMicro ECC-NOR and Intel Sibley
> > flashes need special treatment.  This patch introduces a special
> > kernel-only flag for them that jffs2 uses to call special code.  It
> > should be noted that special code for these devices should not be
> > used.  But until jffs2 is clean in that respect, the flag serves as a
> > reminder that a cleanup is still required at some point.
> 
> Explain. Why shouldn't the existing code be used? What should we do
> instead?
> 
> ??? only a certain number of combinations of features in _real_ hardware
> -- fairly much covered by 'ROM, RAM, NOR, NAND and Sibley/ECC-NOR'.
> Enumerating those, and coping specifically with those, makes as much
> sense as handling arbitrary combinations of feature flags.

Until recently, we had four different variants of jffs2 wbuf code,
depending on the flash type.  I fail to see the difference between
those four and have already merged two of them.  Unless I am missing
something important, the other three can also be combined into one.

But doing so would result in something like
	if ((mtd->type == MTD_NAND) || (mtd->type == MTD_SIBLEY) ||
			(mtd->type == MTD_ECCNOR) ||
			(mtd->type == MTD_DATAFLASH))

Or, more realistically, in something like the recent situation, where
each one of those cases had its own copy of special code because
people don't realize that their type is no different from another
long-merged type.  Note that Nico didn't notice and copied the ECC_NOR
code almost verbatim.  Considering that he is a solid developer
otherwise, what would an average or below-average hacker come up with?

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu




More information about the linux-mtd mailing list