[BUG] ASoC: SOF: ipc4-topology: vmlinux link failure when SND_INTEL_DSP_CONFIG=m

[Jude Gyimah <jude.gyimah87@gmail.com>]

Greetings,

sound/soc/sof/ipc4-topology.c can be built into vmlinux while the Intel NHLT
code it calls is in a module, which breaks the link:

  ipc4-topology.c:(.text+0x22bc): undefined reference to `intel_nhlt_get_endpoint_blob'
  aarch64-linux-gnu-ld: ipc4-topology.c:(.text+0x2424): undefined reference to `intel_nhlt_ssp_device_type'
  aarch64-linux-gnu-ld: ipc4-topology.c:(.text+0x2458): undefined reference to `intel_nhlt_get_endpoint_blob'

arm64, v7.3, full .config attached.  The relevant settings are:

  CONFIG_ACPI=y
  CONFIG_SND_SOC_SOF_IMX_COMMON=y
  CONFIG_SND_SOC_SOF=y
  CONFIG_SND_SOC_SOF_INTEL_COMMON=m
  CONFIG_SND_INTEL_DSP_CONFIG=m
  CONFIG_SND_INTEL_NHLT=y

This is the same shape as the sof-pci-dev failure Arnd reported in 2021,
fixed in 8a3fea95fab1 ("ASoC: SOF: SND_INTEL_DSP_CONFIG dependency") and then
properly in 194fe0fc3422 ("ASoC: SOF: pci: move DSP_CONFIG use to
platform-specific drivers").  The NHLT calls in ipc4-topology.c look like the
part that move left behind.

The route in

  SND_SOC_SOF_IMX_COMMON=y selects SND_SOC_SOF, so snd-sof including
  ipc4-topology.o is built into vmlinux.

  SND_SOC_SOF_INTEL_COMMON=m selects SND_INTEL_DSP_CONFIG, so it is m, and
  intel-nhlt.o goes into snd-intel-dspcfg.ko:

    sound/hda/core/Makefile:18: snd-intel-dspcfg-$(CONFIG_SND_INTEL_NHLT) += intel-nhlt.o

  SND_INTEL_DSP_CONFIG then does "select SND_INTEL_NHLT if ACPI".
  SND_INTEL_NHLT is a bool, so a select from an m-valued symbol sets it to y.

  ipc4-topology.c:1793 guards the calls with

    #if IS_ENABLED(CONFIG_ACPI) && IS_ENABLED(CONFIG_SND_INTEL_NHLT)

  which is now true, so the calls are compiled into vmlinux while their
  definitions are in a module.

Why the guard cannot help:

Simply because the guard tests SND_INTEL_NHLT, but the code is shipped by
SND_INTEL_DSP_CONFIG, and SND_INTEL_NHLT is y whenever SND_INTEL_DSP_CONFIG
is y *or* m.  So the condition distinguishes only "NHLT support is present
somewhere" from "absent" i.e., it cannot distinguish built-in from modular, for
any value of SND_INTEL_DSP_CONFIG.  The static inline fallbacks in
include/sound/intel-nhlt.h are keyed on the same condition, so they are
unreachable here too.

The smallest fix imo

Change the condition at ipc4-topology.c:1793 to test reachability of the
option that actually ships the code:

  -#if IS_ENABLED(CONFIG_ACPI) && IS_ENABLED(CONFIG_SND_INTEL_NHLT)
  +#if IS_ENABLED(CONFIG_ACPI) && IS_REACHABLE(CONFIG_SND_INTEL_DSP_CONFIG)

IS_REACHABLE is true when the provider is built in, and when the provider is
a module and the caller is also a module too, this seems to be exactly the condition under
which these calls can link.  However, no header change is needed. The file's own #else
branch at line 1972 already stubs snd_sof_get_nhlt_endpoint_data() to return
0, and where IS_REACHABLE is true with ACPI=y, SND_INTEL_NHLT is y as well,
so the real declarations are in scope.  This is the same one-line remedy
8a3fea95fab1 applied for snd_intel_dsp_driver_probe, named as a temporary fix
pending the restructuring.

The complete fix, if you would rather do it once

Move the NHLT calls to the Intel side, as 194fe0fc3422 did for the PCI probe.
Two things suggest that is where they belong: (i) ipc4_data->nhlt is declared
void * in sound/soc/sof/ipc4-priv.h, and (ii) the only code that ever sets it is
sound/soc/sof/intel/hda-dai.c:764 via intel_nhlt_init().  So, the generic core
holds an opaque pointer that only Intel fills, and then calls Intel accessors
on it.  Outside the header and sound/hda/core/intel-nhlt.c itself,
ipc4-topology.c is the only caller of either function.

A third option would be "depends on SND_INTEL_DSP_CONFIG || !SND_INTEL_DSP_CONFIG"
on config SND_SOC_SOF, but that puts an Intel constraint on the generic core.
An i.MX, MediaTek or AMD user with SND_INTEL_DSP_CONFIG=m for unrelated
reasons could no longer build SOF in.  I have mentioned it only to rule it out.

I am happy to send a patch for whichever of the first two you prefer.

Fixes: aa84ffb72158 ("ASoC: SOF: ipc4-topology: Add support for SSP/DMIC DAI's")

Found this with kreach, a static checker that compares what Kconfig allows against
the symbols the compiled objects actually reference:
https://github.com/JGyimah/kreach

Thanks,
Jude Gyimah