[U-Boot] [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

[Scott Wood <oss@buserror.net>]

On Sat, 2016-06-04 at 13:06 +0200, Boris Brezillon wrote:
> On Sat, 04 Jun 2016 02:14:09 -0500
> Scott Wood <oss@buserror.net> wrote:
> 
> > On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote:
> > > On Fri, 03 Jun 2016 20:08:49 -0500
> > > Scott Wood <oss@buserror.net> wrote:
> > >  
> > > > This doesn't work.  CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined
> > > > when SPL is defined, and the user will be forced to enter a value
> > > > before
> > > > kconfig will continue (or kconfig will error out in an automated
> > > > build).  
> > > 
> > > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be
> > > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header
> > > file.
> > > And for the "user will forced to enter a value before Kconfig
> > > continue" comment, we could just have
> > > 
> > > config SPL_NAND_U_BOOT_OFFS
> > >   	hex "Location in NAND to read U-Boot from"
> > >   	default 0x8000 if NAND_SUNXI
> > > 	default 0x0
> > > 	...  
> > 
> > If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS
> > from
> > the header.
> 
> Nope, because the condition is
> 
> #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
> #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
> #endif
> 
> and not
> 
> #ifdef CONFIG_SPL_NAND_U_BOOT_OFFS
> #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
> #endif
> 
> So CONFIG_SYS_NAND_U_BOOT_OFFS is always preferred over
> CONFIG_SPL_NAND_U_BOOT_OFFS if it's defined.

Ah, right.  Still, I think it would be less confusing to not have two
different names for the same thing, both of which would be present (albeit
only one is used) in the legacy case -- especially if we start adding
references directly to the SPL name in some drivers.  The bool could
eventually be reversed so that only the legacy targets need it.

-Scott