kernel/linux.git/sound/soc/sof/intel, branch v6.18.21

ASoC: SOF: Intel: hda: Fix NULL pointer dereference

2026-03-04T12:20:08+00:00

[ Upstream commit 16c589567a956d46a7c1363af3f64de3d420af20 ] If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken. RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] Signed-off-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Mateusz Redzynia Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260204081833.16630-10-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

Merge tag 'asoc-fix-v6.18-merge-window' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2025-10-08T11:52:14+00:00

ASoC: Fixes for v6.18 A small pile of fixes, almost all for the Intel and SOF code surrounding management of the host buffer. We've also got one fix for Meson and new device IDs and quirk supporting the RT722VB.

ASoC: SOF: Intel: Read the LLP via the associated Link DMA channel

2025-10-03T11:39:48+00:00

It is allowed to mix Link and Host DMA channels in a way that their index is different. In this case we would read the LLP from a channel which is not used or used for other operation. Such case can be reproduced on cAVS2.5 or ACE1 platforms with soundwire configuration: playback to SDW would take Host channel 0 (stream_tag 1) and no Link DMA used Second playback to HDMI (HDA) would use Host channel 1 (stream_tag 2) and Link channel 0 (stream_tag 1). In this case reading the LLP from channel 2 is incorrect as that is not the Link channel used for the HDMI playback. To correct this, we should look up the BE and get the channel used on the Link side. Fixes: 67b182bea08a ("ASoC: SOF: Intel: hda: Implement get_stream_position (Linear Link Position)") Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20251002074719.2084-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda-pcm: Place the constraint on period time instead of buffer time

2025-10-02T14:03:32+00:00

Instead of constraining the ALSA buffer time to be double of the firmware host buffer size, it is better to set it for the period time. This will implicitly constrain the buffer time to a safe value (num_periods is at least 2) and prohibits applications to set smaller period size than what will be covered by the initial DMA burst. Fixes: fe76d2e75a6d ("ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraint") Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://patch.msgid.link/20251002135752.2430-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

Merge branch 'for-linus' into for-next

2025-09-28T06:34:58+00:00

Pull 6.17-devel branch for applying further changes cleanly. Signed-off-by: Taksahi Iwai

Support reading Subsystem ID from Device Tree

2025-09-23T08:28:45+00:00

Merge series from Stefan Binding : In PC systems using ACPI, the driver is able to read back an SSID from the _SUB property. This SSID uniquely identifies the system, which enables the driver to read the correct firmware and tuning for that system from linux-firmware. Currently there is no way of reading this property from device tree. Add an equivalent property in device tree to perform the same role.

Merge tag 'asoc-v6.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

2025-09-20T06:38:17+00:00

ASoC: Updates for v6.18 A relatively quiet release for ASoC, we've had a lot of maintainance work going on and several new drivers but really the most remarkable thing is that we removed a driver, the WL1273 driver used in some old Nokia systems that have had the underlying system support removed from the kernel. - Morimoto-san continues his work on cleanups of the core APIs and enforcement of abstraction layers. - Lots of cleanups and conversions of DT bindings. - Substantial maintainance work on the Intel AVS drivers. - Support for Qualcomm Glymur and PM4125, Realtek RT1321, Shanghai FourSemi FS2104/5S, Texas Instruments PCM1754. - Remove support for TI WL1273.

ASoC: codecs: pcm1754: add pcm1754 dac driver

2025-09-16T21:42:16+00:00

Merge series from Stefan Kerkmann : Add a CODEC driver for the TI PCM1754.

ASoC: Intel: hda-sdw-bpt: set persistent_buffer false

2025-09-15T11:47:08+00:00

The persistent_buffer agreement is false when hda_cl_prepare() is called. We should use the same value when hda_cl_cleanup() is called. Fixes: 5d5cb86fb46ea ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA") Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20250915024853.1153518-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown

ALSA: compress_offload: Add 64-bit safe timestamp infrastructure

2025-09-08T07:33:24+00:00

The copied_total field in struct snd_compr_tstamp is a 32-bit value that can overflow on long-running high-bitrate streams, leading to incorrect calculations for buffer availablility. This patch adds a 64-bit safe timestamping mechanism. A new UAPI struct, snd_compr_tstamp64, is added which uses 64-bit types for byte counters. The relevant ops structures across the ASoC and core compress code are updated to use this new struct. ASoC drivers are updated to use u64 counters. Internal timestamps being u64 now, a compatibility function is added to convert the 64-bit timestamp back to the 32-bit format for legacy ioctl callers. Reviewed-by: Miller Liang Tested-by: Joris Verhaegen Signed-off-by: Joris Verhaegen Reviewed-by: Srinivas Kandagatla Reviewed-by: Charles Keepax Acked-by: Mark Brown Acked-by: Vinod Koul Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250905091301.2711705-2-verhaegen@google.com