On 16 December 2015 at 23:48, Scott Wood <scottw...@freescale.com> wrote: > 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? >
The GUTS driver is SoC specific driver. If/when dependencies are added for that driver it will break the usage of the select for the MMC host driver. No, thanks it's fragile! To me, the best way to use select is either from top-level platform Kconfig or where it's better isolated, perhaps within a subsystem. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
