linux-kernel - Re: sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 27 Apr 2021 22:01:07 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     kernel test robot <lkp@...el.com>, kbuild-all@...ts.01.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.de>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>,
        Bard Liao <bard.liao@...el.com>,
        Mark Brown <broonie@...nel.org>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>
Subject: Re: sound/soc/sof/intel/byt.c:1057: undefined reference to `sof_acpi_probe'

On Tue, Apr 27, 2021 at 9:13 PM Pierre-Louis Bossart
<pierre-louis.bossart@...ux.intel.com> wrote:

> > 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.

Makes sense. I was slightly worried this would require exporting a ton
of symbols and possibly circular dependencies but looking at your patch,
it seems entirely fine.

      Arnd