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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
