Hi Boris,

Boris Brezillon [off-list ref] wrote on Thu, 21 Feb 2019
11:55:54 +0100:

On Thu, 21 Feb 2019 11:01:51 +0100
Miquel Raynal [off-list ref] wrote:

quoted

Force the NAND core be compiled-in when using any kind of NAND.  

Why?

Because all the logic that comes later in the series relies on this
change. I need the NAND core to be compiled-in, as well the ECC engine
core, as well as everything that is shared between raw NAND and
SPI-NAND which I move in the NAND core.

quoted

Also remove the redundant dependencies on MTD which is enforced by the
game of the if/endif blocs.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/Kconfig         | 12 ++++++++++--
 drivers/mtd/nand/onenand/Kconfig |  1 -
 drivers/mtd/nand/raw/Kconfig     |  1 -
 drivers/mtd/nand/spi/Kconfig     |  1 -
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 495751ed3fd7..e8d26a715922 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig

@@ -1,6 +1,14 @@
-config MTD_NAND_CORE
-	tristate
+menuconfig MTD_NAND_CORE
+	tristate "NAND"  

Definitely not something we want to expose in menuconfig.

I considered the NAND core as essential when using raw NAND and
SPI-NAND. Hence, turning it into a menuconfig option make the whole
NAND subsystem available (or not) and will appear in a different
"menuconfig page", which really enhances the readability.

quoted

+	default y  

I don't see what's the problem with letting SPINAND, RAWNAND and
ONENAND select this options if they actually need it.

See the reason above, hence having it "default y" is needed to do not
break existing defconfigs.


Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel