kernel/git/stable/linux-stable.git/sound/soc/sof, branch master

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

ASoC: SOF: validate topology volume range before allocation

2026-08-14T14:22:55+00:00

SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table. Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20260814081238.25434-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown

ASoC: SOF: Use auto-cleanup for firmware loading

2026-08-10T14:34:17+00:00

Simplify the code to manage the firmware loading with __free(firmware) and __free(kfree) auto-cleanups for the firmware data and the temporary string or array. Only the code refactoring, no functional changes. Cc: Liam Girdwood Cc: Bard Liao Cc: Daniel Baluta Cc: Pierre-Louis Bossart Cc: Vijendar Mukunda Acked-by: Peter Ujfalusi Tested-by: Peter Ujfalusi Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260806140006.1412298-32-tiwai@suse.de Signed-off-by: Mark Brown

ASoC: add and use new snd_soc_register_component()

2026-08-04T23:39:37+00:00

Kuninori Morimoto says: Current component has component->name. But snd_soc_register_component() user can't setup it, because component itself is alloced in that function. So, to setup it, user need to use snd_soc_component_initialize() / snd_soc_add_component() directly instead of using snd_soc_register_component(). In the same time, Component will be capsuled soon. Let's tidyup around here. All strange code can be gone if we have both below style. Normal case snd_soc_register_component(dev, ...); Want to setup case component = snd_soc_component_alloc(...); snd_soc_component_set_xxx(component, ...); snd_soc_component_set_xxx(component, ...); (A) snd_soc_register_component(component, ...); This patch-set adds new snd_soc_register_component() which allows to use component (A). Link: https://lore.kernel.org/r/87fr29esth.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87v7ayxk3s.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87zf04c1w5.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87qzkxjg53.wl-kuninori.morimoto.gx@renesas.com Link: https://patch.msgid.link/87y0f2rz8l.wl-kuninori.morimoto.gx@renesas.com

ASoC: SOF: ipc4-topology: Pipeline params improvements

2026-08-04T16:31:03+00:00

Peter Ujfalusi says: Improve handling of some corner cases that are not used by current topology designs, but can be crafted within the rules of a topology file. For example branching topologies, where a single input routed to multiple output endpoints. The already configured part of the graph places constraint on how the new branch can be configured. Handling of process modules also updated to be able to 'guess' what parameters can be changed by the module and allow flexible operation. Link: https://patch.msgid.link/20260730121729.18673-1-peter.ujfalusi@linux.intel.com

ASoC: SOF: ipc4-topology: Update the pipeline_params of prepared modules

2026-08-04T16:31:01+00:00

If the module in path has been already prepared on a branch type of topology, where the branching happens downstream: A1--> A2 ---> B1 --> B2 ... B-branch |-> C1 --> C2 ... C-branch In this case if B-branch is started then A1/A2 is prepared, but when C-branch starts we still need to refine the parameters up to C1 to arrive with a correct params to configure C1. This branching can happen with copiers process modules. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730121729.18673-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Correct the process module's output lookup

2026-08-04T16:31:01+00:00

The process module can change different parameters in the audio path and this change has to be properly evaluated and applied. In case of playback we are converting from multiple input formats to a single format (or just passing through without change), the output format lookup must be based on the input format. In case of capture, we are converting from a single input format to a format which is to be passed to the FE, we need to use the input parameters and the FE parameters to be able to find the correct format: for those parameters that are modified by the module instance we need to use the FE parameter while for the rest we use the input parameters. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730121729.18673-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Store the params change between input/output of a module

2026-08-04T16:31:00+00:00

Based on the input and output formats we can evaluate what param might be changed by the module instance. If there is a difference between the input rate/channels/format and the output rate/channels/format it means that the module can change one or multiple of the params. Store this information during init for later use. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730121729.18673-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

Merge remote-tracking branch 'asoc/for-7.3' into asoc-next

2026-08-03T12:18:29+00:00

ASoC: SOF: Use high-priority workqueue for PCM period elapsed

2026-07-31T22:21:09+00:00

The snd_sof_pcm_period_elapsed function currently schedules work on the system-wide workqueue. This can lead to potential delays or jitter in audio processing if the system workqueue is busy with other tasks. To improve real-time performance and ensure timely processing of PCM periods, we can use the system_highpri_wq instead of the default work queue. In performance testing, this change significantly reduced the observed scheduling delays. For instance, under load(stressapptest -M 15000 -m 60), the maximum delay dropped from 9ms on the system workqueue to 5ms on the dedicated high-priority workqueue. Suggested-by: Kai Vehmanen Signed-off-by: Yu-Hsuan Hsu Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260730130445.8277-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown