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

From: Boris Brezillon <[email-masked]>
Date: Thu, 21 Feb 2019 12:14:37 +0100

On Thu, 21 Feb 2019 12:06:10 +0100
Miquel Raynal <[email-masked]> wrote:

> Hi Boris,
> 
> Boris Brezillon <[email-masked]> wrote on Thu, 21 Feb 2019
> 11:55:54 +0100:
> 
> > On Thu, 21 Feb 2019 11:01:51 +0100
> > Miquel Raynal <[email-masked]> 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 <[email-masked]>
> > > ---
> > >  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
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel