[U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().

[Scott Wood]

On Sat, 16 Oct 2010 00:48:11 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20101015173533.4e1d8bcb at udp111988uds.am.freescale.net> you wrote:
> >
> > > This looks like a broken design to me.
> > 
> > What would you rather see in its place?
> 
> Good question. I have to admit that I don't know all this code and
> it's embroilments too well. There is this with MTD and that without,
> there is this for JFFS2 and that without. I lost track in that maze
> long ago.
> 
> Eventually we should have some mtd_init() call which does this, 

OK, so replace the nand_init() with a call to a new mtd_init(), that
currently just calls nand_init()?

The parts that access nand_info[] directly rather than using the MTD
interface would use nand_init() directly.

> but then, I'm not sure if there might not be a case ot mtdparts without
> MTD.

There's an existing dependency there -- if that dependency is
conditionalized/removed in the future, then doing the same to its call
to mtd_init() would be part of that.

> > > Assume we add this call here; would it then not also be needed in the
> > > 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever
> > > 'static' is supposed to mean) ?
> > 
> > Yes, it seems so.  Is there a good reason why jffs2 has its own
> > implementation of this stuff?
> 
> Too many people working on differnt parts of the code, without
> looking over their respective rims ?  Sorry, I never understood.
> I think Stefan spent already some time to clean up parts of the mess,
> but this probably needs more effort.
> 
> > yaffs_StartUp is in a similar situation.
> 
> Oh dear. It doesn't come to an end.

Some grepping turns up omap_nand_switch_ecc, and lcd_show_board_info in
a few boards -- but I think that's it.

-Scott