[lkml]   [2017]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/9] ASoC: Intel: Fix Kconfig with top-level selector
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:
> >>
> >> + 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
> 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
> + bool "Intel ASoC SST drivers"
> + default y
> + depends on X86 || COMPILE_TEST
> +menuconfig SND_SOC_INTEL_MACH
> + bool "Intel Machine drivers"
> 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

config BAR
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

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.


 \ /
  Last update: 2017-12-19 11:17    [W:0.095 / U:5.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site