[alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit
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
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"
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
- 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.
- 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?
- 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
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
- 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.
- 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
- 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.
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.
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
- 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
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.
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
- 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
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
+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
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.
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. :-)
participants (4)
-
Mark Brown -
Pierre-Louis Bossart -
Rafael J. Wysocki -
Sinan Kaya