[U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver

[Scott Wood]

On Mon, 2016-06-06 at 20:31 +0200, Boris Brezillon wrote:
> On Mon, 06 Jun 2016 12:56:48 -0500
> Scott Wood <oss at buserror.net> wrote:
> 
> > On Mon, 2016-06-06 at 18:22 +0200, Boris Brezillon wrote:
> > > On Mon, 6 Jun 2016 17:36:10 +0200
> > > Hans de Goede <hdegoede at redhat.com> wrote:
> > >   
> > > > > +#ifndef CONFIG_SPL_BUILD
> > > > > +void sunxi_nand_init(void);
> > > > > +#endif
> > > > > +    
> > > > 
> > > > Can we have this in a header somewhere please, and without
> > > > the #ifdef around it, that is not necessary for prototypes.  
> > > 
> > > Hehe, I was expecting this one :-). Do you know where I should put this
> > > prototype definition? A board.h file in board/sunxi/?  
> > 
> > It's defined in drivers/mtd/nand and called from board/sunxi so the
> > prototype
> > needs to go somewhere under include/.  It can go in include/configs/sunxi
> > -common.h with #ifndef __ASSEMBLY__ around it -- or as long as it's
> > limited to
> > one init func per driver, maybe we could just put it in include/nand.h.
> 
> Hm, none of these solutions seem ideal.
> 
> Maybe we could define a generic void nand_controller_init(void)
> prototype so that we don't need to add new xxx_nand_init() functions for
> platforms needing this 2 steps initialization (platform specific pinmux
> + clocks config before NAND controller initialization).
> 
> Otherwise, I think I'll go for the 2nd solution (defining
> sunxi_nand_init() in include/nand.h).

I'd prefer not having a generic nand_controller_init() because some platforms
may want to pass arguments, plus I don't want to rule out the possibility of
two different NAND controller types being supported at once.

include/nand.h is fine with me, as long as any driver than wants more than an
initfunc moves its stuff into a dedicated header.  Of course the driver model
is probably the long-term solution.

-Scott