| Message ID | 1459510190-26306-4-git-send-email-mugunthanvnm@ti.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
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 <mugunthanvnm@ti.com> Good but you need to update configs/ to remove NAND from CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y Doing: $ for F in `git grep -lE SYS_EXTRA.*NAND configs/`;do sed -i -e \ 's/,NAND//' $F && echo CONFIG_NAND=y >> $F;done will get you most of the way there, then just a: $ for C in `git status configs/ | grep modified: | cut -d / -f 2`;do \ make O=$C $C savedefconfig && cp $C/defconfig configs/$C;done To get it in the right spot, git add -p only the bits you really wanted, done. Thanks!
On Friday 01 April 2016 06:21 PM, 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 <mugunthanvnm@ti.com> > > Good but you need to update configs/ to remove NAND from > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > Doing: > $ for F in `git grep -lE SYS_EXTRA.*NAND configs/`;do sed -i -e \ > 's/,NAND//' $F && echo CONFIG_NAND=y >> $F;done > will get you most of the way there, then just a: > $ for C in `git status configs/ | grep modified: | cut -d / -f 2`;do \ > make O=$C $C savedefconfig && cp $C/defconfig configs/$C;done > > To get it in the right spot, git add -p only the bits you really wanted, > done. Thanks! > Will fix it in v2 Regards Mugunthan V N
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 <mugunthanvnm@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. -Scott
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 <mugunthanvnm@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.
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 <mugunthanvnm@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. -Scott
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 <mugunthanvnm@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 :)
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 <mugunthanvnm@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? Regards Mugunthan V N
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 <mugunthanvnm@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.
On Fri, 2016-04-08 at 15:45 -0400, Tom Rini wrote: > 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 <mugunthanvnm@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. I'm fine with changing the names as long as everything gets updated properly. The boards which use CONFIG_NAND to mean NAND boot (which is a relic of an old and dead config mechanism that parsed extra words added to a target name) can be changed to CONFIG_NAND_BOOT. -Scott
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 2fc73ef..7787505 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -1,4 +1,12 @@ -menu "NAND Device Support" +menuconfig NAND + bool "NAND device support" + help + You must select Y to enable any NAND device support + Generally if you have any NAND devices this is a given + + If unsure, say Y + +if NAND config SYS_NAND_SELF_INIT bool @@ -118,4 +126,4 @@ config SPL_NAND_DENALI endif -endmenu +endif
Add CONFIG_NAND as a Kconfig option so that it can be selected using menuconfig or defconfig. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> --- drivers/mtd/nand/Kconfig | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)