Messages in this thread | | | Date | Tue, 26 Apr 2022 11:00:59 +0200 | Subject | Re: linux-next: build failure after merge of the sound-asoc tree | From | Amadeusz Sławiński <> |
| |
On 4/26/2022 10:30 AM, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > sound/soc/soc-acpi.c:34:1: error: redefinition of 'snd_soc_acpi_find_machine' > 34 | snd_soc_acpi_find_machine(struct snd_soc_acpi_mach *machines) > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from sound/soc/soc-acpi.c:9: > include/sound/soc-acpi.h:38:1: note: previous definition of 'snd_soc_acpi_find_machine' with type 'struct snd_soc_acpi_mach *(struct snd_soc_acpi_mach *)' > 38 | snd_soc_acpi_find_machine(struct snd_soc_acpi_mach *machines) > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > sound/soc/soc-acpi.c: In function 'snd_soc_acpi_find_package': > sound/soc/soc-acpi.c:58:36: error: implicit declaration of function 'acpi_fetch_acpi_dev'; did you mean 'device_match_acpi_dev'? [-Werror=implicit-function-declaration] > 58 | struct acpi_device *adev = acpi_fetch_acpi_dev(handle); > | ^~~~~~~~~~~~~~~~~~~ > | device_match_acpi_dev > sound/soc/soc-acpi.c:58:36: error: initialization of 'struct acpi_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] > sound/soc/soc-acpi.c:64:25: error: invalid use of undefined type 'struct acpi_device' > 64 | if (adev && adev->status.present && adev->status.functional) { > | ^~ > sound/soc/soc-acpi.c:64:49: error: invalid use of undefined type 'struct acpi_device' > 64 | if (adev && adev->status.present && adev->status.functional) { > | ^~ > sound/soc/soc-acpi.c:80:26: error: implicit declaration of function 'acpi_extract_package' [-Werror=implicit-function-declaration] > 80 | status = acpi_extract_package(myobj, > | ^~~~~~~~~~~~~~~~~~~~ > sound/soc/soc-acpi.c: At top level: > sound/soc/soc-acpi.c:95:6: error: redefinition of 'snd_soc_acpi_find_package_from_hid' > 95 | bool snd_soc_acpi_find_package_from_hid(const u8 hid[ACPI_ID_LEN], > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from sound/soc/soc-acpi.c:9: > include/sound/soc-acpi.h:44:1: note: previous definition of 'snd_soc_acpi_find_package_from_hid' with type 'bool(const u8 *, struct snd_soc_acpi_package_context *)' {aka '_Bool(const unsigned char *, struct snd_soc_acpi_package_context *)'} > 44 | snd_soc_acpi_find_package_from_hid(const u8 hid[ACPI_ID_LEN], > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > sound/soc/soc-acpi.c:109:27: error: redefinition of 'snd_soc_acpi_codec_list' > 109 | struct snd_soc_acpi_mach *snd_soc_acpi_codec_list(void *arg) > | ^~~~~~~~~~~~~~~~~~~~~~~ > In file included from sound/soc/soc-acpi.c:9: > include/sound/soc-acpi.h:51:41: note: previous definition of 'snd_soc_acpi_codec_list' with type 'struct snd_soc_acpi_mach *(void *)' > 51 | static inline struct snd_soc_acpi_mach *snd_soc_acpi_codec_list(void *arg) > | ^~~~~~~~~~~~~~~~~~~~~~~ > > Caused by commit > > 47a1886a610a ("ASoC: Intel: avs: Enable AVS driver only on x86 platforms") > > I have applied the following patch for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Tue, 26 Apr 2022 18:01:06 +1000 > Subject: [PATCH] partial revert of "ASoC: Intel: avs: Enable AVS driver only on x86 platforms" > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > 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 be42c4eff165..b0b46deb25c6 100644 > --- a/sound/soc/intel/Kconfig > +++ b/sound/soc/intel/Kconfig > @@ -211,7 +211,7 @@ config SND_SOC_INTEL_KEEMBAY > > config SND_SOC_INTEL_AVS > tristate "Intel AVS driver" > - depends on (X86 && ACPI) || COMPILE_TEST > + depends on (X86 && ACPI) > depends on PCI > depends on COMMON_CLK > select SND_SOC_ACPI
Well, I'm surprised, as there are 2 other drivers that have depends on ACPI || COMPILE_TEST...
I guess it is ultimately caused by select SND_SOC_ACPI as failure is in sound/soc/soc-acpi.c file.
I guess SND_SOC_ACPI could depend on ACPI explicitly, to make sure there is no weird dependency issues?
On the other hand I guess we can just leave X86 with COMPILE_TEST and move ACPI to depends on, without COMPILE_TEST.
Mark, what do you think?
| |