On Tue, Apr 05, 2016 at 02:07:46PM +0530, Mugunthan V N wrote: > Scott/Tom > > On Saturday 02 April 2016 05:55 AM, Tom Rini wrote: > > On Fri, Apr 01, 2016 at 06:45:03PM -0500, Scott Wood wrote: > >> On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > >>> On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > >>> > >>>> On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > >>>>> On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > >>>>> > >>>>>> Add CONFIG_NAND as a Kconfig option so that it can be selected > >>>>>> using menuconfig or defconfig. > >>>>>> > >>>>>> Signed-off-by: Mugunthan V N <mugunthan...@ti.com> > >>>>> > >>>>> Good but you need to update configs/ to remove NAND from > >>>>> CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > >>>> > >>>> NACK > >>>> > >>>> That CONFIG_NAND is a target-local option used by some boards to indicate > >>>> boot > >>>> source. It is not equivalent to CONFIG_CMD_NAND which is what enables > >>>> the > >>>> NAND subsystem. > >>> > >>> Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and > >>> into a real Kconfig entry. That said, I think this might have forgotten > >>> to enable it in other places too but just 'NAND' needs to migrate out of > >>> where it is. > >> > >> If we must start using NAND rather than CMD_NAND to enable the NAND > >> subsystem > >> (which is what this patch does), then a lot more than that needs to > >> change. > >> We'll need a new name for the boot source selection, and we'll need to > >> kconfigize all the boards that enable CONFIG_CMD_NAND via the board config > >> header. > > > > OK, I see your point now too. Yes, we need to tackle NAND/CMD_NAND > > Kconfig stuff (including the tangled web of CMD_NAND being how we toggle > > NAND the functionality) as a pre-patch series to this. But it needs > > doing :) > > Should I be moving back NAND to "CONFIG_SYS_EXTRA_OPTIONS"? > > Since CONFIG_CMD_NAND is used to enable NAND subsystem, so move > CONFIG_CMD_NAND to drivers/mtd/nand/Kconfig? > > or am I missing something?
I would like to see, but I want to hear Scott's opinion, move to CONFIG_NAND is what enables NAND support for everyone (so yes, lots of defconfigs will need an update) so that we can move it all over to Kconfig. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
