On Fri, 15 Dec 2017 13:30:28 +0100, Pierre-Louis Bossart wrote: > > On 12/15/17 5:07 AM, Takashi Iwai wrote: > > On Fri, 15 Dec 2017 01:44:43 +0100, > > Pierre-Louis Bossart wrote: > >> > >> +config SND_SOC_ACPI_INTEL_MATCH > >> + tristate > >> + depends on X86 && ACPI > >> + select SND_SOC_ACPI > > > > An item that is selected by others can only select, not depend. > > The depends need to be put for the items that select this instead. > > Initially the code was > > config SND_SOC_ACPI_INTEL_MATCH > tristate > select SND_SOC_ACPI if ACPI > > I changed it to use depends to make some 0-day reports go away, for > some reason this option was selected with ARCH=mn10300 and generated > warnings. I don't quite understand how that happened since X86 and > ACPI are clear dependencies in the items which select this option... > > Vinod also added a similar pattern with > > +config SND_SOC_INTEL_SST_TOPLEVEL > + bool "Intel ASoC SST drivers" > + default y > + depends on X86 || COMPILE_TEST > + select SND_SOC_INTEL_MACH > > +menuconfig SND_SOC_INTEL_MACH > + bool "Intel Machine drivers" > depends on SND_SOC_INTEL_SST_TOPLEVEL > > Maybe that needs to be removed as well? Having both depends and select on the top-level is OK. The only problem is when an item that is selected by others has another depends. For example, a simple-looking case like below is actually buggy: config BAR tristate depends on X config FOO tristate "foo" select BAR Here BAR would be enabled by FOO no matter what X is, even if X=n. That said, when an item is selected, its own dependency is ignored. For correcting this, the depends-on-X must be moved to the top-level who selects the item: config BAR tristate config FOO tristate "foo" depends on X select BAR Note that the reverse-select chain works as expected. The breakage is only the mixture of select and depends in the selected items. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
