Hi Boris, Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote on Thu, 21 Feb 2019 11:55:54 +0100: > On Thu, 21 Feb 2019 11:01:51 +0100 > Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > 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. > > > > > 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@xxxxxxxxxxx> > > --- > > 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. > > > + 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 MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/