[PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Sinan Kaya]

After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
satisfied implicitly through dependencies on CONFIG_ACPI have to be
specified directly. This code relies on IOSF_MBI and IOSF_MBI depends
on PCI. For this reason, add a direct dependency on CONFIG_PCI to the
IOSF_MBI driver.

Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya <okaya@kernel.org>
---
 sound/soc/intel/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index 2fd1b61e8331..b0764b2fe001 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -91,7 +91,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI
 config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
 	tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
 	default ACPI
-	depends on X86 && ACPI
+	depends on X86 && ACPI && PCI
 	select SND_SST_IPC_ACPI
 	select SND_SST_ATOM_HIFI2_PLATFORM
 	select SND_SOC_ACPI_INTEL_MATCH
-- 
2.19.0

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Pierre-Louis Bossart]

[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]

I have three opens with this ACPI/PCI change

1. the baseline change fails on my cross-compilation checks, see below 
the result of the attached script (simplification of the one I use to 
avoid 0day reports).

2. there are different patterns to express the dependency on PCI e.g.

  config MMC_SDHCI_ACPI
      tristate "SDHCI support for ACPI enumerated SDHCI controllers"
      depends on MMC_SDHCI && ACPI
-    select IOSF_MBI if X86
+    select IOSF_MBI if (X86 && PCI)

but

config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
      tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
      default ACPI
-    depends on X86 && ACPI
+    depends on X86 && ACPI && PCI
      select SND_SST_IPC_ACPI
      select SND_SST_ATOM_HIFI2_PLATFORM
      select SND_SOC_ACPI_INTEL_MATCH

IOSF is only needed for Baytrail-CR detection, and the code will compile 
fine without it, so maybe it'd be a better model if you used the 
following diff?

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index 2fd1b61e8331..68af0ea5c96c 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -95,7 +95,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
         select SND_SST_IPC_ACPI
         select SND_SST_ATOM_HIFI2_PLATFORM
         select SND_SOC_ACPI_INTEL_MATCH
-       select IOSF_MBI
+       select IOSF_MBI if PCI

3. All the Intel machine drivers depend on X86_INTEL_LPSS which depends 
on PCI. But for Baytrail/Haswell/Broadwell we have only a dependency on 
ACPI, so we expose drivers that can be selected but fail on probe since 
there are no machine drivers. I am not sure if we want to be strict and 
only expose meaningful configurations, or allow for more compilations 
tests and corner cases?

-Pierre


cross-compilation issue:

git checkout next-20190102

make CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/ia64-linux/bin/ia64-linux- 
--jobs=16 allmodconfig ARCH=ia64
   HOSTCC  scripts/basic/fixdep
   HOSTCC  scripts/kconfig/conf.o
   YACC    scripts/kconfig/zconf.tab.c
   LEX     scripts/kconfig/zconf.lex.c
   HOSTCC  scripts/kconfig/confdata.o
   HOSTCC  scripts/kconfig/expr.o
   HOSTCC  scripts/kconfig/symbol.o
   YACC    scripts/kconfig/zconf.tab.h
   HOSTCC  scripts/kconfig/preprocess.o
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTCC  scripts/kconfig/zconf.lex.o
   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --allmodconfig Kconfig
arch/ia64/Kconfig:128:error: recursive dependency detected!
arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by 
HIBERNATION
kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
init/Kconfig:250:    symbol SWAP depends on BLOCK
block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
fs/Kconfig:227:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI
drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by 
IA64_HP_SIM
arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"


[-- Attachment #2: cross-check._sh --]
[-- Type: text/plain, Size: 1075 bytes --]

#!/bin/bash

set -e

test_fast() {

    PLATFORM="$1"
    make mrproper
    ../make.cross allmodconfig ARCH=$PLATFORM
    ../make.cross olddefconfig ARCH=$PLATFORM    
    ../make.cross ARCH=$PLATFORM modules_prepare
}

test_compile() {

    PLATFORM="$1"
    make mrproper
    
    make defconfig ARCH=$PLATFORM
    
    echo "modules first"
    ../make.cross ARCH=$PLATFORM
    if [ "$PLATFORM" = "x86_64" ]; then
	../make.cross bindeb-pkg ARCH=$PLATFORM
    fi


    echo "all yes second"
    perl -pi.bak -e 's/=m/=y/g' .config
    ../make.cross olddefconfig ARCH=$PLATFORM
    ../make.cross ARCH=$PLATFORM
    if [ "$PLATFORM" = "x86_64" ]; then
	../make.cross bindeb-pkg ARCH=$PLATFORM
    fi

}

test_platform() {

    PLATFORM="$1"
       
    test_fast    $PLATFORM
#    test_compile $PLATFORM
}

test_platform x86_64
test_platform i386
test_platform ia64
test_platform arm
test_platform arm64
test_platform sh
test_platform mips
test_platform s390
test_platform openrisc
test_platform sparc
test_platform sparc64
test_platform m68k

echo "X-compilation check PASS"

Re: [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Rafael J. Wysocki]

On Wed, Jan 2, 2019 at 9:33 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
> I have three opens with this ACPI/PCI change
>
> 1. the baseline change fails on my cross-compilation checks, see below
> the result of the attached script (simplification of the one I use to
> avoid 0day reports).

What baseline change?

That failure is not related to PCI if I'm not missing anything.

> 2. there are different patterns to express the dependency on PCI e.g.
>
>   config MMC_SDHCI_ACPI
>       tristate "SDHCI support for ACPI enumerated SDHCI controllers"
>       depends on MMC_SDHCI && ACPI
> -    select IOSF_MBI if X86
> +    select IOSF_MBI if (X86 && PCI)
>
> but
>
> config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>       tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
>       default ACPI
> -    depends on X86 && ACPI
> +    depends on X86 && ACPI && PCI
>       select SND_SST_IPC_ACPI
>       select SND_SST_ATOM_HIFI2_PLATFORM
>       select SND_SOC_ACPI_INTEL_MATCH
>
> IOSF is only needed for Baytrail-CR detection, and the code will compile
> fine without it, so maybe it'd be a better model if you used the
> following diff?
>
> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> index 2fd1b61e8331..68af0ea5c96c 100644
> --- a/sound/soc/intel/Kconfig
> +++ b/sound/soc/intel/Kconfig
> @@ -95,7 +95,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>          select SND_SST_IPC_ACPI
>          select SND_SST_ATOM_HIFI2_PLATFORM
>          select SND_SOC_ACPI_INTEL_MATCH
> -       select IOSF_MBI
> +       select IOSF_MBI if PCI

Well, does it actually make sense to ever set
SND_SST_ATOM_HIFI2_PLATFORM_ACPI without PCI?

> 3. All the Intel machine drivers depend on X86_INTEL_LPSS which depends
> on PCI. But for Baytrail/Haswell/Broadwell we have only a dependency on
> ACPI, so we expose drivers that can be selected but fail on probe since
> there are no machine drivers. I am not sure if we want to be strict and
> only expose meaningful configurations, or allow for more compilations
> tests and corner cases?

I would only expose meaningful configurations to start with and then
*maybe* relax that going forward as long as the benefit is worth it.

Cheers,
Rafael

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Sinan Kaya]

On Wed, Jan 2, 2019 at 8:33 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
> I have three opens with this ACPI/PCI change
>
> 1. the baseline change fails on my cross-compilation checks, see below
> the result of the attached script (simplification of the one I use to
> avoid 0day reports).
>

This is pointing to a kconfig issue on ia64 arch.

arch/ia64/Kconfig:128:error: recursive dependency detected!
arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM

IA64_HP_SIM is both a choice and is selected.

I did allyesconfig and disabled PCI afterwards to find all the issues
on this patchset.

> 2. there are different patterns to express the dependency on PCI e.g.
>
>   config MMC_SDHCI_ACPI
>       tristate "SDHCI support for ACPI enumerated SDHCI controllers"
>       depends on MMC_SDHCI && ACPI
> -    select IOSF_MBI if X86
> +    select IOSF_MBI if (X86 && PCI)
>
> but
>
> config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>       tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
>       default ACPI
> -    depends on X86 && ACPI
> +    depends on X86 && ACPI && PCI
>       select SND_SST_IPC_ACPI
>       select SND_SST_ATOM_HIFI2_PLATFORM
>       select SND_SOC_ACPI_INTEL_MATCH
>

I matched depends line to

depends on X86 && ACPI && PCI

for MMC_SDHCI_ACPI per feedback from Rafael on V5. This should resolve
the inconsistency.


> IOSF is only needed for Baytrail-CR detection, and the code will compile
> fine without it, so maybe it'd be a better model if you used the
> following diff?
>
> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> index 2fd1b61e8331..68af0ea5c96c 100644
> --- a/sound/soc/intel/Kconfig
> +++ b/sound/soc/intel/Kconfig
> @@ -95,7 +95,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>          select SND_SST_IPC_ACPI
>          select SND_SST_ATOM_HIFI2_PLATFORM
>          select SND_SOC_ACPI_INTEL_MATCH
> -       select IOSF_MBI
> +       select IOSF_MBI if PCI
>
> 3. All the Intel machine drivers depend on X86_INTEL_LPSS which depends
> on PCI. But for Baytrail/Haswell/Broadwell we have only a dependency on
> ACPI, so we expose drivers that can be selected but fail on probe since
> there are no machine drivers. I am not sure if we want to be strict and
> only expose meaningful configurations, or allow for more compilations
> tests and corner cases?

Hopefully, v5 resolves this too with

depends on X86 && ACPI && PCI

Let me know otherwise.

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Pierre-Louis Bossart]

> This is pointing to a kconfig issue on ia64 arch.
>
> arch/ia64/Kconfig:128:error: recursive dependency detected!
> arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
> arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
>
> IA64_HP_SIM is both a choice and is selected.
>
> I did allyesconfig and disabled PCI afterwards to find all the issues
> on this patchset.

Are you saying there's a newer series that fixes this issue for both 
allyesconfig and allmodconfig?

if yes, then we're good.

>
>> 2. there are different patterns to express the dependency on PCI e.g.
>>
>>    config MMC_SDHCI_ACPI
>>        tristate "SDHCI support for ACPI enumerated SDHCI controllers"
>>        depends on MMC_SDHCI && ACPI
>> -    select IOSF_MBI if X86
>> +    select IOSF_MBI if (X86 && PCI)
>>
>> but
>>
>> config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>>        tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
>>        default ACPI
>> -    depends on X86 && ACPI
>> +    depends on X86 && ACPI && PCI
>>        select SND_SST_IPC_ACPI
>>        select SND_SST_ATOM_HIFI2_PLATFORM
>>        select SND_SOC_ACPI_INTEL_MATCH
>>
> I matched depends line to
>
> depends on X86 && ACPI && PCI
>
> for MMC_SDHCI_ACPI per feedback from Rafael on V5. This should resolve
> the inconsistency.
ok, I didn't see the delta
>
>
>> IOSF is only needed for Baytrail-CR detection, and the code will compile
>> fine without it, so maybe it'd be a better model if you used the
>> following diff?
>>
>> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
>> index 2fd1b61e8331..68af0ea5c96c 100644
>> --- a/sound/soc/intel/Kconfig
>> +++ b/sound/soc/intel/Kconfig
>> @@ -95,7 +95,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
>>           select SND_SST_IPC_ACPI
>>           select SND_SST_ATOM_HIFI2_PLATFORM
>>           select SND_SOC_ACPI_INTEL_MATCH
>> -       select IOSF_MBI
>> +       select IOSF_MBI if PCI
>>
>> 3. All the Intel machine drivers depend on X86_INTEL_LPSS which depends
>> on PCI. But for Baytrail/Haswell/Broadwell we have only a dependency on
>> ACPI, so we expose drivers that can be selected but fail on probe since
>> there are no machine drivers. I am not sure if we want to be strict and
>> only expose meaningful configurations, or allow for more compilations
>> tests and corner cases?
> Hopefully, v5 resolves this too with
>
> depends on X86 && ACPI && PCI
>
> Let me know otherwise.

it doesn't but that's not a good enough reason to lay on the tracks. 
I'll follow-up with a cleanup for the Intel audio parts when this series 
is merged. The PCI dependency could be moved to the top-level since it's 
pretty much required for all platforms except for compilation tests, and 
there are multiple dependencies that repeated for no good reason, so FWIW

Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Sinan Kaya]

On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
> > This is pointing to a kconfig issue on ia64 arch.
> >
> > arch/ia64/Kconfig:128:error: recursive dependency detected!
> > arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
> > arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
> >
> > IA64_HP_SIM is both a choice and is selected.
> >
> > I did allyesconfig and disabled PCI afterwards to find all the issues
> > on this patchset.
>
> Are you saying there's a newer series that fixes this issue for both
> allyesconfig and allmodconfig?
>
> if yes, then we're good.


No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I
used allyesconfig to find out all compilation issues on x86 arch to
come up with this patchset.


>
> >
> >> 2. there are different patterns to express the dependency on PCI e.g.
> >>
> >>    config MMC_SDHCI_ACPI
> >>        tristate "SDHCI support for ACPI enumerated SDHCI controllers"
> >>        depends on MMC_SDHCI && ACPI
> >> -    select IOSF_MBI if X86
> >> +    select IOSF_MBI if (X86 && PCI)
> >>
> >> but
> >>
> >> config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
> >>        tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
> >>        default ACPI
> >> -    depends on X86 && ACPI
> >> +    depends on X86 && ACPI && PCI
> >>        select SND_SST_IPC_ACPI
> >>        select SND_SST_ATOM_HIFI2_PLATFORM
> >>        select SND_SOC_ACPI_INTEL_MATCH
> >>
> > I matched depends line to
> >
> > depends on X86 && ACPI && PCI
> >
> > for MMC_SDHCI_ACPI per feedback from Rafael on V5. This should resolve
> > the inconsistency.
> ok, I didn't see the delta
> >
> >
> >> IOSF is only needed for Baytrail-CR detection, and the code will compile
> >> fine without it, so maybe it'd be a better model if you used the
> >> following diff?
> >>
> >> diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> >> index 2fd1b61e8331..68af0ea5c96c 100644
> >> --- a/sound/soc/intel/Kconfig
> >> +++ b/sound/soc/intel/Kconfig
> >> @@ -95,7 +95,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
> >>           select SND_SST_IPC_ACPI
> >>           select SND_SST_ATOM_HIFI2_PLATFORM
> >>           select SND_SOC_ACPI_INTEL_MATCH
> >> -       select IOSF_MBI
> >> +       select IOSF_MBI if PCI
> >>
> >> 3. All the Intel machine drivers depend on X86_INTEL_LPSS which depends
> >> on PCI. But for Baytrail/Haswell/Broadwell we have only a dependency on
> >> ACPI, so we expose drivers that can be selected but fail on probe since
> >> there are no machine drivers. I am not sure if we want to be strict and
> >> only expose meaningful configurations, or allow for more compilations
> >> tests and corner cases?
> > Hopefully, v5 resolves this too with
> >
> > depends on X86 && ACPI && PCI
> >
> > Let me know otherwise.
>
> it doesn't but that's not a good enough reason to lay on the tracks.
> I'll follow-up with a cleanup for the Intel audio parts when this series
> is merged. The PCI dependency could be moved to the top-level since it's
> pretty much required for all platforms except for compilation tests, and
> there are multiple dependencies that repeated for no good reason, so FWIW
>
> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
>

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Pierre-Louis Bossart]

On 1/2/19 4:58 PM, Sinan Kaya wrote:
> On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com> wrote:
>>
>>> This is pointing to a kconfig issue on ia64 arch.
>>>
>>> arch/ia64/Kconfig:128:error: recursive dependency detected!
>>> arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
>>> arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
>>>
>>> IA64_HP_SIM is both a choice and is selected.
>>>
>>> I did allyesconfig and disabled PCI afterwards to find all the issues
>>> on this patchset.
>> Are you saying there's a newer series that fixes this issue for both
>> allyesconfig and allmodconfig?
>>
>> if yes, then we're good.
>
> No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I
> used allyesconfig to find out all compilation issues on x86 arch to
> come up with this patchset.

Nothing makes me cringe more than "somebody else's job" statements. In 
this case, there is obviously a correlation with your ACPI changes since 
the circular dependency happens because of the ACPI symbol.

arch/ia64/Kconfig:126:error: recursive dependency detected!
arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by 
HIBERNATION
kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
init/Kconfig:250:    symbol SWAP depends on BLOCK
block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI 
<<<< LOOK HERE
drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by 
IA64_HP_SIM
arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>

At any rate, a 3 mn git bisect tells me the circular dependency is 
exposed by this change:

f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date:   Sat Dec 8 12:21:38 2018 +0530

     fscrypt: remove filesystem specific build config option

     In order to have a common code base for fscrypt "post read" processing
     for all filesystems which support encryption, this commit removes
     filesystem specific build config option (e.g. 
CONFIG_EXT4_FS_ENCRYPTION)
     and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
     value affects all the filesystems making use of fscrypt.

     Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
     Signed-off-by: Theodore Ts'o <tytso@mit.edu>

-Pierre

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Sinan Kaya]

+Tony

On Wed, Jan 2, 2019 at 11:50 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
> On 1/2/19 4:58 PM, Sinan Kaya wrote:
> > On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart
> > <pierre-louis.bossart@linux.intel.com> wrote:
> >>
> >>> This is pointing to a kconfig issue on ia64 arch.
> >>>
> >>> arch/ia64/Kconfig:128:error: recursive dependency detected!
> >>> arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
> >>> arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
> >>>
> >>> IA64_HP_SIM is both a choice and is selected.
> >>>
> >>> I did allyesconfig and disabled PCI afterwards to find all the issues
> >>> on this patchset.
> >> Are you saying there's a newer series that fixes this issue for both
> >> allyesconfig and allmodconfig?
> >>
> >> if yes, then we're good.
> >
> > No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I
> > used allyesconfig to find out all compilation issues on x86 arch to
> > come up with this patchset.
>
> Nothing makes me cringe more than "somebody else's job" statements. In
> this case, there is obviously a correlation with your ACPI changes since
> the circular dependency happens because of the ACPI symbol.
>

I agree that it needs to be fixed. I am not convinced that the issue
is related to my change.
Your log is pointing to an inconsistency in ia64 kconfig.

> arch/ia64/Kconfig:126:error: recursive dependency detected!
> arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
> kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
> kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by
> HIBERNATION
> kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
> init/Kconfig:250:    symbol SWAP depends on BLOCK
> block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
> fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
> fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
> drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
> drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI
> <<<< LOOK HERE

I am still having hard time seeing how this issue is exposed by
removing PCI dependency from ACPi.

Rafael, Tony:

can you help me?

> drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by
> IA64_HP_SIM
> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>
>
> At any rate, a 3 mn git bisect tells me the circular dependency is
> exposed by this change:
>
> f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
> commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
> Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> Date:   Sat Dec 8 12:21:38 2018 +0530
>
>      fscrypt: remove filesystem specific build config option
>
>      In order to have a common code base for fscrypt "post read" processing
>      for all filesystems which support encryption, this commit removes
>      filesystem specific build config option (e.g.
> CONFIG_EXT4_FS_ENCRYPTION)
>      and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
>      value affects all the filesystems making use of fscrypt.
>
>      Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>      Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>
> -Pierre
>
>

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Chandan Rajendra]

On Thursday, January 3, 2019 5:20:27 AM IST Pierre-Louis Bossart wrote:
> 
> On 1/2/19 4:58 PM, Sinan Kaya wrote:
> > On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart
> > <pierre-louis.bossart@linux.intel.com> wrote:
> >>
> >>> This is pointing to a kconfig issue on ia64 arch.
> >>>
> >>> arch/ia64/Kconfig:128:error: recursive dependency detected!
> >>> arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
> >>> arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
> >>>
> >>> IA64_HP_SIM is both a choice and is selected.
> >>>
> >>> I did allyesconfig and disabled PCI afterwards to find all the issues
> >>> on this patchset.
> >> Are you saying there's a newer series that fixes this issue for both
> >> allyesconfig and allmodconfig?
> >>
> >> if yes, then we're good.
> >
> > No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I
> > used allyesconfig to find out all compilation issues on x86 arch to
> > come up with this patchset.
> 
> Nothing makes me cringe more than "somebody else's job" statements. In 
> this case, there is obviously a correlation with your ACPI changes since 
> the circular dependency happens because of the ACPI symbol.
> 
> arch/ia64/Kconfig:126:error: recursive dependency detected!
> arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
> kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
> kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by 
> HIBERNATION
> kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
> init/Kconfig:250:    symbol SWAP depends on BLOCK
> block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
> fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
> fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
> drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
> drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI 
> <<<< LOOK HERE
> drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by 
> IA64_HP_SIM
> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>
> 
> At any rate, a 3 mn git bisect tells me the circular dependency is 
> exposed by this change:
> 
> f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
> commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
> Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> Date:   Sat Dec 8 12:21:38 2018 +0530
> 
>      fscrypt: remove filesystem specific build config option
> 
>      In order to have a common code base for fscrypt "post read" processing
>      for all filesystems which support encryption, this commit removes
>      filesystem specific build config option (e.g. 
> CONFIG_EXT4_FS_ENCRYPTION)
>      and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
>      value affects all the filesystems making use of fscrypt.
> 
>      Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>      Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 

FWIW, The patch at https://patchwork.kernel.org/patch/10725883/ fixes this
problem by removing "select BLOCK if FS_ENCRYPTION" from fs/ubifs/Kconfig.

-- 
chandan

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Rafael J. Wysocki]

On Thu, Jan 3, 2019 at 5:08 AM Chandan Rajendra <chandan@linux.ibm.com> wrote:
>
> On Thursday, January 3, 2019 5:20:27 AM IST Pierre-Louis Bossart wrote:
> >
> > On 1/2/19 4:58 PM, Sinan Kaya wrote:
> > > On Wed, Jan 2, 2019 at 10:50 PM Pierre-Louis Bossart
> > > <pierre-louis.bossart@linux.intel.com> wrote:
> > >>
> > >>> This is pointing to a kconfig issue on ia64 arch.
> > >>>
> > >>> arch/ia64/Kconfig:128:error: recursive dependency detected!
> > >>> arch/ia64/Kconfig:128:    choice <choice> contains symbol IA64_HP_SIM
> > >>> arch/ia64/Kconfig:202:    symbol IA64_HP_SIM is part of choice PM
> > >>>
> > >>> IA64_HP_SIM is both a choice and is selected.
> > >>>
> > >>> I did allyesconfig and disabled PCI afterwards to find all the issues
> > >>> on this patchset.
> > >> Are you saying there's a newer series that fixes this issue for both
> > >> allyesconfig and allmodconfig?
> > >>
> > >> if yes, then we're good.
> > >
> > > No, I haven't fixed ia64 kconfig issue. That's somebody else's job. I
> > > used allyesconfig to find out all compilation issues on x86 arch to
> > > come up with this patchset.
> >
> > Nothing makes me cringe more than "somebody else's job" statements. In
> > this case, there is obviously a correlation with your ACPI changes since
> > the circular dependency happens because of the ACPI symbol.
> >
> > arch/ia64/Kconfig:126:error: recursive dependency detected!
> > arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
> > arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
> > kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
> > kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> > kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by
> > HIBERNATION
> > kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
> > init/Kconfig:250:    symbol SWAP depends on BLOCK
> > block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
> > fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
> > fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
> > drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
> > drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI
> > <<<< LOOK HERE
> > drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by
> > IA64_HP_SIM
> > arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>
> >
> > At any rate, a 3 mn git bisect tells me the circular dependency is
> > exposed by this change:
> >
> > f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
> > commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
> > Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> > Date:   Sat Dec 8 12:21:38 2018 +0530
> >
> >      fscrypt: remove filesystem specific build config option
> >
> >      In order to have a common code base for fscrypt "post read" processing
> >      for all filesystems which support encryption, this commit removes
> >      filesystem specific build config option (e.g.
> > CONFIG_EXT4_FS_ENCRYPTION)
> >      and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
> >      value affects all the filesystems making use of fscrypt.
> >
> >      Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> >      Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> >
>
> FWIW, The patch at https://patchwork.kernel.org/patch/10725883/ fixes this
> problem by removing "select BLOCK if FS_ENCRYPTION" from fs/ubifs/Kconfig.

OK

Pierre-Louis, can you check if this patch makes the issue go away for
you, please?

Re: [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Pierre-Louis Bossart]

>>> arch/ia64/Kconfig:126:error: recursive dependency detected!
>>> arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
>>> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
>>> kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
>>> kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
>>> kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by
>>> HIBERNATION
>>> kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
>>> init/Kconfig:250:    symbol SWAP depends on BLOCK
>>> block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
>>> fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
>>> fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
>>> drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
>>> drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI
>>> <<<< LOOK HERE
>>> drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by
>>> IA64_HP_SIM
>>> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>
>>>
>>> At any rate, a 3 mn git bisect tells me the circular dependency is
>>> exposed by this change:
>>>
>>> f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
>>> commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
>>> Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>>> Date:   Sat Dec 8 12:21:38 2018 +0530
>>>
>>>       fscrypt: remove filesystem specific build config option
>>>
>>>       In order to have a common code base for fscrypt "post read" processing
>>>       for all filesystems which support encryption, this commit removes
>>>       filesystem specific build config option (e.g.
>>> CONFIG_EXT4_FS_ENCRYPTION)
>>>       and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
>>>       value affects all the filesystems making use of fscrypt.
>>>
>>>       Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
>>>       Signed-off-by: Theodore Ts'o <tytso@mit.edu>
>>>
>> FWIW, The patch at https://patchwork.kernel.org/patch/10725883/ fixes this
>> problem by removing "select BLOCK if FS_ENCRYPTION" from fs/ubifs/Kconfig.
> OK
>
> Pierre-Louis, can you check if this patch makes the issue go away for
> you, please?

Wondering if Chandan provided the right pointer, I wasn't able to apply 
this patch, but commenting out "select BLOCK if FS_ENCRYPTION" in 
fs/ubifs/Kconfig makes the circular dependency go away. All good for me.

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Chandan Rajendra]

On Thursday, January 3, 2019 9:58:28 PM IST Pierre-Louis Bossart wrote:
> 
> >>> arch/ia64/Kconfig:126:error: recursive dependency detected!
> >>> arch/ia64/Kconfig:126:    choice <choice> contains symbol IA64_HP_SIM
> >>> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice PM
> >>> kernel/power/Kconfig:144:    symbol PM is selected by PM_SLEEP
> >>> kernel/power/Kconfig:104:    symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> >>> kernel/power/Kconfig:31:    symbol HIBERNATE_CALLBACKS is selected by
> >>> HIBERNATION
> >>> kernel/power/Kconfig:34:    symbol HIBERNATION depends on SWAP
> >>> init/Kconfig:250:    symbol SWAP depends on BLOCK
> >>> block/Kconfig:5:    symbol BLOCK is selected by UBIFS_FS
> >>> fs/ubifs/Kconfig:1:    symbol UBIFS_FS depends on MISC_FILESYSTEMS
> >>> fs/Kconfig:220:    symbol MISC_FILESYSTEMS is selected by ACPI_APEI
> >>> drivers/acpi/apei/Kconfig:8:    symbol ACPI_APEI depends on ACPI
> >>> drivers/acpi/Kconfig:9:    symbol ACPI depends on ARCH_SUPPORTS_ACPI
> >>> <<<< LOOK HERE
> >>> drivers/acpi/Kconfig:6:    symbol ARCH_SUPPORTS_ACPI is selected by
> >>> IA64_HP_SIM
> >>> arch/ia64/Kconfig:200:    symbol IA64_HP_SIM is part of choice <choice>
> >>>
> >>> At any rate, a 3 mn git bisect tells me the circular dependency is
> >>> exposed by this change:
> >>>
> >>> f3fd6cd74fedf99b6060f75df00943fda13b65f2 is the first bad commit
> >>> commit f3fd6cd74fedf99b6060f75df00943fda13b65f2
> >>> Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> >>> Date:   Sat Dec 8 12:21:38 2018 +0530
> >>>
> >>>       fscrypt: remove filesystem specific build config option
> >>>
> >>>       In order to have a common code base for fscrypt "post read" processing
> >>>       for all filesystems which support encryption, this commit removes
> >>>       filesystem specific build config option (e.g.
> >>> CONFIG_EXT4_FS_ENCRYPTION)
> >>>       and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
> >>>       value affects all the filesystems making use of fscrypt.
> >>>
> >>>       Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> >>>       Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> >>>
> >> FWIW, The patch at https://patchwork.kernel.org/patch/10725883/ fixes this
> >> problem by removing "select BLOCK if FS_ENCRYPTION" from fs/ubifs/Kconfig.
> > OK
> >
> > Pierre-Louis, can you check if this patch makes the issue go away for
> > you, please?
> 
> Wondering if Chandan provided the right pointer, I wasn't able to apply 
> this patch, but commenting out "select BLOCK if FS_ENCRYPTION" in 
> fs/ubifs/Kconfig makes the circular dependency go away. All good for me.
> 

V4 version of the patchset (which is part of linux-next) had introduced the
"select BLOCK if FS_ENCRYPTION". The V5 patchset omits that line. Hence the
patch did not apply cleanly. However just commenting out that line was the
right thing to do.

-- 
chandan

Re: [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

On Wed, Jan 02, 2019 at 06:10:35PM +0000, Sinan Kaya wrote:

> After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
> CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
> satisfied implicitly through dependencies on CONFIG_ACPI have to be
> specified directly. This code relies on IOSF_MBI and IOSF_MBI depends
> on PCI. For this reason, add a direct dependency on CONFIG_PCI to the
> IOSF_MBI driver.

I still don't understand what's going on with dependencies here and
still don't have the cover letter or anything :( .  As far as I can tell
the above commit is in Linus' tree so I'd expect I can just apply it
directly but you were saying that this needs to go via some other tree
so I'm a bit confused as to what's going on here.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

[Rafael J. Wysocki]

On Thu, Jan 3, 2019 at 1:34 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Jan 02, 2019 at 06:10:35PM +0000, Sinan Kaya wrote:
>
> > After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
> > CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
> > satisfied implicitly through dependencies on CONFIG_ACPI have to be
> > specified directly. This code relies on IOSF_MBI and IOSF_MBI depends
> > on PCI. For this reason, add a direct dependency on CONFIG_PCI to the
> > IOSF_MBI driver.
>
> I still don't understand what's going on with dependencies here and
> still don't have the cover letter or anything :( .  As far as I can tell
> the above commit is in Linus' tree so I'd expect I can just apply it
> directly

Yes, you can.

> but you were saying that this needs to go via some other tree
> so I'm a bit confused as to what's going on here.

I guess Sinan wanted it to go in via the ACPI tree like 5d32a66541c4,
but that of course isn't necessary.

If you want to pick up anything from this series, please do.  I will
pick up what's left. :-)