Re: [RFC PATCH 2/8] ASoC: SDCA: allow building without ACPI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unbounded recursion in `set_input_terminal_sources()` can lead to a kernel stack overflow if the firmware-provided SDCA topology graph contains a cycle.
- [Medium] The commit message and `SND_SOC_SDCA` Kconfig help text claim non-ACPI SDCA topology is supplied via `sdca_class_hw_ops.get_function_data`, but this API does not exist.
--

--- Patch [2]: [RFC PATCH 2/8] ASoC: SDCA: allow building without ACPI ---
commit b04522a00403ca00a5d4ee2768eab7c24cb31da7
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>

ASoC: SDCA: allow building without ACPI

This commit drops the ACPI dependency for the SDCA class driver to allow
building on non-ACPI platforms. It also guards ACPI-parsing implementations
with IS_ENABLED(CONFIG_ACPI), providing empty stubs when ACPI is disabled.

> The SDCA class driver is useful on non-ACPI platforms where the
> topology is supplied statically via sdca_class_hw_ops.get_function_data.

[Severity: Medium]
Does this API actually exist in the kernel tree? Searching for
sdca_class_hw_ops or get_function_data yields no definitions. Is there a
missing patch that introduces this mechanism for codec drivers to supply
topology data on non-ACPI platforms?

> diff --git a/sound/soc/sdca/Kconfig b/sound/soc/sdca/Kconfig
> index 4c0dcb9ff3b94..dc4cba1e3e0ed 100644
> --- a/sound/soc/sdca/Kconfig
> +++ b/sound/soc/sdca/Kconfig
> @@ -3,11 +3,13 @@ menu "SoundWire (SDCA)"
>  
>  config SND_SOC_SDCA
>  	tristate "SDCA core support"
> -	depends on ACPI
>  	select AUXILIARY_BUS
>  	help
>  	  This option enables support for the MIPI SoundWire Device
> -	  Class for Audio (SDCA).
> +	  Class for Audio (SDCA).  The ACPI/DisCo topology parser is
> +	  only built when CONFIG_ACPI is enabled; on non-ACPI platforms
> +	  (e.g. ARM/DT) codec drivers supply the SDCA function data
> +	  via sdca_class_hw_ops.get_function_data.

[Severity: Medium]
Similar to the commit message, this help text points developers to
sdca_class_hw_ops.get_function_data. Since this interface doesn't seem to be
defined anywhere, should this documentation be updated to reflect the actual
mechanism used by codec drivers?

While reviewing this code, I also noticed a potential regression in the
topology parsing logic:

sound/soc/sdca/sdca_asoc.c:set_input_terminal_sources() {
    ...
		ret = set_input_terminal_sources(dev, regmap, function, src,
						 channels, rate, width);
    ...
}

[Severity: High]
Can this recursive call cause a kernel stack overflow if the firmware-provided
SDCA topology graph contains a cycle?

The graph of SDCA entities is populated directly from external firmware data,
such as ACPI _DSD. The traversal appears to lack cycle detection (like a
visited bitmask) or a recursion depth limit.

If a malformed or malicious firmware blob provides a cyclic connection, such
as Entity A connecting to Entity B and back to Entity A, would this function
recurse infinitely and exhaust the stack during device probing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722234221.884765-1-srinivas.kandagatla@oss.qualcomm.com?part=2