From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: kbuild-all@lists.01.org
Subject: Re: sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe'
Date: Tue, 27 Apr 2021 14:13:40 -0500 [thread overview]
Message-ID: <fddb59dd-8bf2-7f2c-7388-fab0475482e4@linux.intel.com> (raw)
In-Reply-To: <CAK8P3a0k2rk=eN1v1JcpeXOm6kU+MJDKESyyC2AQ7CJVfREFFw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]
>>> ld: sound/soc/sof/intel/byt.o: in function `sof_baytrail_probe':
>>>>> sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe'
>>>>> ld: sound/soc/sof/intel/byt.o:(.data+0x44): undefined reference to `sof_acpi_remove'
>>>>> ld: sound/soc/sof/intel/byt.o:(.data+0x94): undefined reference to `sof_acpi_pm'
>>
>> Ack, this is again the partition between Baytrail and Merrifield that's
>> problematic in the corner case where ACPI is compiled as module and PCI
>> as built-in. It's a bit academic since the PCI probe wouldn't work, but
>> still it's not well partitioned.
>>
>> I've been wanting to change this for a while, and split the common atom
>> parts from the ACPI/PCI parts. I guess it's time to fix this for good.
>
> I wonder why I never see these in randconfig builds here. I can reproduce it
> with the .config from the link above though, and I see these relevant config
> lines:
>
> CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y
> CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP=y
> CONFIG_SND_SOC_SOF_MERRIFIELD=y
> CONFIG_SND_SOC_SOF_ACPI=m
> CONFIG_SND_SOC_SOF_ACPI_DEV=m
> CONFIG_SND_SOC_SOF_BAYTRAIL=m
yes, we end-up with a bad configuration with BAYTRAIL as m and
Merrifield as y. That's broken since they share the same file.
> An easy workaround would be to move the first 500 or so lines of
> sound/soc/sof/intel/byt.c into a separate file and #include that from
> distinct baytrail and merrifield modules, at the cost of a bit of
> object code duplication and a somewhat dirty hack.
I have a fix being tested here:
https://github.com/thesofproject/linux/pull/2874
The idea is what you suggested, move the common parts to a new file but
I used an 'atom' module instead #include to avoid duplication. The
exported functions are namespaced to avoid polluting the global symbol map.
The only other change needed is in the Makefile, We already have
CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP in the Kconfig and that can be
used for this module.
> Another option would be a Kconfig hack to prevent the broken
> configuration, such as
>
> diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig
> index eebe784ff652..b2039b4af9cf 100644
> --- a/sound/soc/sof/intel/Kconfig
> +++ b/sound/soc/sof/intel/Kconfig
> @@ -85,6 +85,8 @@ config SND_SOC_SOF_MERRIFIELD
> tristate "SOF support for Tangier/Merrifield"
> default SND_SOC_SOF_PCI
> select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> + # Merrifield can't be built-in if snd-sof-acpi-intel-byt.ko is a module
> + depends on SND_SOC_SOF_BAYTRAIL || !SND_SOC_SOF_BAYTRAIL
> help
> This adds support for Sound Open Firmware for Intel(R) platforms
> using the Tangier/Merrifield processors.
It'd rather do this the right way with a proper code partitioning, I was
tempted to do it multiple times and I've had it with this code.
WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: kernel test robot <lkp@intel.com>,
kbuild-all@lists.01.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Takashi Iwai <tiwai@suse.de>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>,
Bard Liao <bard.liao@intel.com>, Mark Brown <broonie@kernel.org>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Subject: Re: sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe'
Date: Tue, 27 Apr 2021 14:13:40 -0500 [thread overview]
Message-ID: <fddb59dd-8bf2-7f2c-7388-fab0475482e4@linux.intel.com> (raw)
In-Reply-To: <CAK8P3a0k2rk=eN1v1JcpeXOm6kU+MJDKESyyC2AQ7CJVfREFFw@mail.gmail.com>
>>> ld: sound/soc/sof/intel/byt.o: in function `sof_baytrail_probe':
>>>>> sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe'
>>>>> ld: sound/soc/sof/intel/byt.o:(.data+0x44): undefined reference to `sof_acpi_remove'
>>>>> ld: sound/soc/sof/intel/byt.o:(.data+0x94): undefined reference to `sof_acpi_pm'
>>
>> Ack, this is again the partition between Baytrail and Merrifield that's
>> problematic in the corner case where ACPI is compiled as module and PCI
>> as built-in. It's a bit academic since the PCI probe wouldn't work, but
>> still it's not well partitioned.
>>
>> I've been wanting to change this for a while, and split the common atom
>> parts from the ACPI/PCI parts. I guess it's time to fix this for good.
>
> I wonder why I never see these in randconfig builds here. I can reproduce it
> with the .config from the link above though, and I see these relevant config
> lines:
>
> CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y
> CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP=y
> CONFIG_SND_SOC_SOF_MERRIFIELD=y
> CONFIG_SND_SOC_SOF_ACPI=m
> CONFIG_SND_SOC_SOF_ACPI_DEV=m
> CONFIG_SND_SOC_SOF_BAYTRAIL=m
yes, we end-up with a bad configuration with BAYTRAIL as m and
Merrifield as y. That's broken since they share the same file.
> An easy workaround would be to move the first 500 or so lines of
> sound/soc/sof/intel/byt.c into a separate file and #include that from
> distinct baytrail and merrifield modules, at the cost of a bit of
> object code duplication and a somewhat dirty hack.
I have a fix being tested here:
https://github.com/thesofproject/linux/pull/2874
The idea is what you suggested, move the common parts to a new file but
I used an 'atom' module instead #include to avoid duplication. The
exported functions are namespaced to avoid polluting the global symbol map.
The only other change needed is in the Makefile, We already have
CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP in the Kconfig and that can be
used for this module.
> Another option would be a Kconfig hack to prevent the broken
> configuration, such as
>
> diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig
> index eebe784ff652..b2039b4af9cf 100644
> --- a/sound/soc/sof/intel/Kconfig
> +++ b/sound/soc/sof/intel/Kconfig
> @@ -85,6 +85,8 @@ config SND_SOC_SOF_MERRIFIELD
> tristate "SOF support for Tangier/Merrifield"
> default SND_SOC_SOF_PCI
> select SND_SOC_SOF_INTEL_ATOM_HIFI_EP
> + # Merrifield can't be built-in if snd-sof-acpi-intel-byt.ko is a module
> + depends on SND_SOC_SOF_BAYTRAIL || !SND_SOC_SOF_BAYTRAIL
> help
> This adds support for Sound Open Firmware for Intel(R) platforms
> using the Tangier/Merrifield processors.
It'd rather do this the right way with a proper code partitioning, I was
tempted to do it multiple times and I've had it with this code.
next prev parent reply other threads:[~2021-04-27 19:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 11:10 sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe' kernel test robot
2021-04-27 11:10 ` kernel test robot
2021-04-27 16:07 ` Pierre-Louis Bossart
2021-04-27 16:07 ` Pierre-Louis Bossart
2021-04-27 18:42 ` Arnd Bergmann
2021-04-27 18:42 ` Arnd Bergmann
2021-04-27 19:13 ` Pierre-Louis Bossart [this message]
2021-04-27 19:13 ` Pierre-Louis Bossart
2021-04-27 20:01 ` Arnd Bergmann
2021-04-27 20:01 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fddb59dd-8bf2-7f2c-7388-fab0475482e4@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=kbuild-all@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.