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