kernel/linux.git/include/sound, branch v5.10.257

ASoC: core: Do not call link_exit() on uninitialized rtd objects

2026-04-18T08:30:53+00:00

[ Upstream commit dd9f9cc1e6b9391140afa5cf27bb47c9e2a08d02 ] On init we have sequence: for_each_card_prelinks(card, i, dai_link) { ret = snd_soc_add_pcm_runtime(card, dai_link); ret = init_some_other_things(...); if (ret) goto probe_end: for_each_card_rtds(card, rtd) { ret = soc_init_pcm_runtime(card, rtd); probe_end: while on exit: for_each_card_rtds(card, rtd) snd_soc_link_exit(rtd); If init_some_other_things() step fails due to error we end up with not fully setup rtds and try to call snd_soc_link_exit on them, which depending on contents on .link_exit handler, can end up dereferencing NULL pointer. Reviewed-by: Cezary Rojewski Signed-off-by: Amadeusz Sławiński Link: https://lore.kernel.org/r/20230929103243.705433-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: 95bc5c225513 ("ASoC: soc-core: flush delayed work before removing DAIs and widgets") Signed-off-by: Sasha Levin

ASoC: soc-core: add snd_soc_runtime_get_dai_fmt()

2026-04-18T08:30:53+00:00

[ Upstream commit ba9e82a1c8919340bee0dd7f7cafb8749810aabe ] ASoC is using dai_link which specify DAI format (= dai_link->dai_fmt), and it is selected by "Sound Card" driver in corrent implementation. In other words, Sound Card *needs* to setup it. But, it should be possible to automatically selected from CPU and Codec driver settings. This patch adds new .auto_selectable_formats support at snd_soc_dai_ops. By this patch, dai_fmt can be automatically selected from each driver if both CPU / Codec driver had it. Automatically selectable *field* is depends on each drivers. For example, some driver want to select format "automatically", but want to select other fields "manually", because of complex limitation. Or other example, in case of both CPU and Codec are possible to be clock provider, but the quality was different. In these case, user need/want to *manually* select each fields from Sound Card driver. This .auto_selectable_formats can set priority. For example, no limitaion format can be HI priority, supported but has picky limitation format can be next priority, etc. It uses Sound Card specified fields preferentially, and try to select non-specific fields from CPU and Codec driver automatically if all drivers have .auto_selectable_formats. In other words, we can select all dai_fmt via Sound Card driver same as before. Link: https://lore.kernel.org/r/871rb3hypy.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871racbx0w.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87h7ionc8s.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Stable-dep-of: 95bc5c225513 ("ASoC: soc-core: flush delayed work before removing DAIs and widgets") Signed-off-by: Sasha Levin

ASoC: topology: use inclusive language for bclk and fsync

2026-04-18T08:30:53+00:00

[ Upstream commit f026c123001bcc15b78311495cec79a8b73c3cf2 ] Mirror suggested changes in alsa-lib. Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201112163100.5081-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: 95bc5c225513 ("ASoC: soc-core: flush delayed work before removing DAIs and widgets") Signed-off-by: Sasha Levin

ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer

2026-02-06T15:40:00+00:00

commit 47c27c9c9c720bc93fdc69605d0ecd9382e99047 upstream. Handle the error code from snd_pcm_buffer_access_lock() in snd_pcm_runtime_buffer_set_silence() function. Found by Alexandros Panagiotou Fixes: 93a81ca06577 ("ALSA: pcm: Fix race of buffer access at PCM OSS layer") Cc: stable@vger.kernel.org # 6.15 Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20260107213642.332954-1-perex@perex.cz Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: pcm: Fix race of buffer access at PCM OSS layer

2025-06-04T12:37:07+00:00

commit 93a81ca0657758b607c3f4ba889ae806be9beb73 upstream. The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: dmaengine: Synchronize dma channel after drop()

2024-07-27T08:40:19+00:00

[ Upstream commit e8343410ddf08fc36a9b9cc7c51a4e53a262d4c6 ] Sometimes the stream may be stopped due to XRUN events, in which case the userspace can call snd_pcm_drop() and snd_pcm_prepare() to stop and start the stream again. In these cases, we must wait for the DMA channel to synchronize before marking the stream as prepared for playback, as the DMA channel gets stopped by drop() without any synchronization. Make sure the ALSA core synchronizes the DMA channel by adding a sync_stop() hook. Reviewed-by: Peter Ujfalusi Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240611-asoc_next-v3-1-fcfd84b12164@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: soc-acpi: add helper to identify parent driver.

2024-06-16T11:32:10+00:00

[ Upstream commit 644eebdbbf1154c995d6319c133d7d5b898c5ed2 ] Intel machine drivers are used by parent platform drivers based on closed-source firmware (Atom/SST and catpt) and SOF-based ones. In some cases for ACPI-based platforms, the behavior of machine drivers needs to be modified depending on the parent type, typically for card names and power management. An initial solution based on passing a boolean flag as a platform device parameter was tested earlier. Since it looked overkill, this patch suggests instead a simple string comparison to identify an SOF parent device/driver. Suggested-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20201112223825.39765-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Stable-dep-of: 0cb3b7fd530b ("ASoC: Intel: Disable route checks for Skylake boards") Signed-off-by: Sasha Levin

ASoC: soc-card: Add storage for PCI SSID

2023-11-28T16:54:51+00:00

[ Upstream commit 47f56e38a199bd45514b8e0142399cba4feeaf1a ] Add members to struct snd_soc_card to store the PCI subsystem ID (SSID) of the soundcard. The PCI specification provides two registers to store a vendor-specific SSID that can be read by drivers to uniquely identify a particular "soundcard". This is defined in the PCI specification to distinguish products that use the same silicon (and therefore have the same silicon ID) so that product-specific differences can be applied. PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as invalid. So the usual pattern of zero-filling the struct and then assuming a zero value unset will not work. A flag is included to indicate when the SSID information has been filled in. Unlike DMI information, which has a free-format entirely up to the vendor, the PCI SSID has a strictly defined format and a registry of vendor IDs. It is usual in Windows drivers that the SSID is used as the sole identifier of the specific end-product and the Windows driver contains tables mapping that to information about the hardware setup, rather than using ACPI properties. This SSID is important information for ASoC components that need to apply hardware-specific configuration on PCI-based systems. As the SSID is a generic part of the PCI specification and is treated as identifying the "soundcard", it is reasonable to include this information in struct snd_soc_card, instead of components inventing their own custom ways to pass this information around. Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230912163207.3498161-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: soc-pcm: test if a BE can be prepared

2023-06-21T13:45:36+00:00

[ Upstream commit e123036be377ddf628226a7c6d4f9af5efd113d3 ] In the BE hw_params configuration, the existing code checks if any of the existing FEs are prepared, running, paused or suspended - and skips the configuration in those cases. This allows multiple calls of hw_params which the ALSA state machine supports. This check is not handled for the prepare stage, which can lead to the same BE being prepared multiple times. This patch adds a check similar to that of the hw_params, with the main difference being that the suspended state is allowed: the ALSA state machine allows a transition from suspended to prepared with hw_params skipped. This problem was detected on Intel IPC4/SoundWire devices, where the BE dailink .prepare stage is used to configure the SoundWire stream with a bank switch. Multiple .prepare calls lead to conflicts with the .trigger operation with IPC4 configurations. This problem was not detected earlier on Intel devices, HDaudio BE dailinks detect that the link is already prepared and skip the configuration, and for IPC3 devices there is no BE trigger. Link: https://github.com/thesofproject/sof/issues/7596 Signed-off-by: Ranjani Sridharan

ASoC: soc-dapm.h: fixup warning struct snd_pcm_substream not declared

2023-03-11T15:39:39+00:00

[ Upstream commit fdff966bfde7cf0c85562d2bfb1ff1ba83da5f7b ] Add struct snd_pcm_substream forward declaration Fixes: 078a85f2806f ("ASoC: dapm: Only power up active channels from a DAI") Signed-off-by: Lucas Tanure Reviewed-by: Charles Keepax Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230215132851.1626881-1-lucas.tanure@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin