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

[Miquel Raynal <miquel.raynal@xxxxxxxxxxx>]

Hi Boris,

Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote on Thu, 21 Feb 2019
12:14:37 +0100:

> 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.

Yes, do you think it is a problem?

> 
> > 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.

Then why not using this symbol? I don't get why you are opposed.

So you would like a config NAND_CORE (invisible) and a visible
menuconfig NAND? And all entries in the NAND menu selecting NAND_CORE?

> 
> >   
> > >     
> > > > +	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.


Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/