Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for MMC_SDHCI_OF_ESDHC

[Scott Wood <scottwood@freescale.com>]

On Tue, 2015-12-15 at 10:46 +0100, Ulf Hansson wrote:
> [...]
> > > > --- a/drivers/mmc/host/Kconfig
> > > > +++ b/drivers/mmc/host/Kconfig
> > > > @@ -142,6 +142,8 @@ config MMC_SDHCI_OF_ESDHC
> > > >         depends on MMC_SDHCI_PLTFM
> > > >         depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
> > > >         select MMC_SDHCI_IO_ACCESSORS
> > > > +       select SOC_FSL
> > > > +       select FSL_GUTS
> > > 
> > > This is weird.
> > > 
> > > First, perhaps it would make sense to have stub functions for those
> > > the FSL_GUTS driver provides via its API, thus the above wouldn't be
> > > required at all. Of course this makes only sense if you think there
> > > are/could be configurations for a cross SOC driver which don't need
> > > the GUTS driver.
> > > 
> > > Second, even if you think the stubs above is a bad idea, I would from
> > > the top-level Kconfig for your platform, add the needed "selects" as I
> > > think it's where it belongs and then change this to "depends on"
> > > instead.
> > 
> > Why is it weird for a driver to select another driver that it makes calls
> > to?
> >  Much easier to do it here than in all the platforms that use this driver.
> 
> Because using "select" will not consider the dependencies for the new
> selected Kconfig option. I can imagine that it might become a problem,
> sooner or later.

It's not a problem as long as the selected option's dependencies (if any) are
selected, or depended on by the selecting driver.  I wouldn't expect the
FSL_GUTS driver to depend on anything other than basic OF support.

> So, "select" shall be used by care and in this case I think we can
> cope fine with using "depends on".

What does select exist for if not situations like this?  What "care" is
missing?

-Scott