On Thu, 21 Feb 2019 12:06:10 +0100 Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > 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, Hm, not exactly compiled-in as it can still be selected as a module. > 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. Yes, the core is required for SPI NAND and soon will be for RAW NAND, but I still don't see the problem with the "select NAND_CORE" approach, sorry. > > > > > > > > > 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. It is needed for SPI NAND, and will be for raw NAND for sure, but I still see no reasons for turning it into a user-visible option. > 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. That's a different thing, and I have no problem with adding an extra level in the Kconfig hierarchy. > > > > > > + 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. Not if you make RAW_NAND select NAND_CORE. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/