On Thu, 2015-12-17 at 12:25 +0100, Ulf Hansson wrote: > On 16 December 2015 at 23:48, Scott Wood <scottwood@xxxxxxxxxxxxx> 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. The guts driver is not going to depend on anything that the esdhc driver shouldn't already be depending on (why does MMC_SDHCI_OF_ESDHC not currently depend on OF?) and if the guts driver ever did grow a dependency that isn't met but it is selected anyway, kconfig will warn. I realize that growing a guts dependency list in every user would be bad but I just don't see such dependencies happening. -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
