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

[Scott Wood <scottwood@freescale.com>]

On Mon, 2015-12-14 at 14:08 +0100, Ulf Hansson wrote:
> On 14 December 2015 at 05:24, Yangbo Lu <yangbo.lu@freescale.com> wrote:
> > The sdhci-of-esdhc driver needs the GUTS driver support
> > to access the global utilities registers for SVR value.
> > So we select FSL_GUTS for MMC_SDHCI_OF_ESDHC here.
> > 
> > Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
> > ---
> > Changes for v2:
> >         - None
> > Changes for v3:
> >         - None
> > Changes for v4:
> >         - Added this patch
> > ---
> >  drivers/mmc/host/Kconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 1526b8a..df57c14 100644
> > --- 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.

And I think stubs for reading SVR is quite a bad idea.  It'll make the driver
build but it will silently not be able to apply SVR-based workarounds.

-Scott