Re: [RFC PATCH 02/27] mtd: nand: Compile in the NAND core by default

From: Boris Brezillon <bbrezillon@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Mason Yang <masonccyang@mxic.com.tw>, Vignesh R <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Julien Su <juliensu@mxic.com.tw>,
	Richard Weinberger <richard@nod.at>,
	Schrempf Frieder <frieder.schrempf@kontron.de>,
	Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 02/27] mtd: nand: Compile in the NAND core by default
Date: Thu, 21 Feb 2019 12:14:37 +0100	[thread overview]
Message-ID: <20190221121437.7c551bc5@kernel.org> (raw)
In-Reply-To: <20190221120610.5abb49ae@xps13>

On Thu, 21 Feb 2019 12:06:10 +0100
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hi Boris,
> 
> Boris Brezillon <bbrezillon@kernel.org> wrote on Thu, 21 Feb 2019
> 11:55:54 +0100:
> 
> > On Thu, 21 Feb 2019 11:01:51 +0100
> > Miquel Raynal <miquel.raynal@bootlin.com> 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@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.

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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel