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

ASoC: SOF: ipc4-topology: Allow bytes controls without initial payload

2026-04-02T11:23:17+00:00

commit d40a198e2b7821197c5c77b89d0130cc90f400f5 upstream. It is unexpected, but allowed to have no initial payload for a bytes control and the code is prepared to handle this case, but the size check missed this corner case. Update the check for minimal size to allow the initial size to be 0. Cc: stable@vger.kernel.org Fixes: a653820700b8 ("ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls") Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Reviewed-by: Seppo Ingalsuo Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20260326075618.1603-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: ipc4-control: Keep the payload size up to date

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

[ Upstream commit ebcfdbe4add923dfb690e6fb9d158da87ae0b6bf ] When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data

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

[ Upstream commit c1876fc33c5976837e4c73719c7582617efc6919 ] The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls

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

[ Upstream commit a653820700b81c9e6f05ac23b7969ecec1a18e85 ] The size of the data behind of scontrol->ipc_control_data for bytes controls is: [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct [2] sizeof(struct sof_abi_hdr)) + payload The max_size specifies the size of [2] and it is coming from topology. Change the function to take this into account and allocate adequate amount of memory behind scontrol->ipc_control_data. With the change we will allocate [1] amount more memory to be able to hold the full size of data. Fixes: a382082ff74b ("ASoC: SOF: ipc4-topology: Add support for TPLG_CTL_BYTES") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: ipc4-control: If there is no data do not send bytes update

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

[ Upstream commit 2fa74713744dc5e908fff851c20f5f89fd665fb7 ] When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

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

ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET

2026-03-04T12:19:49+00:00

[ Upstream commit d96cb0b86d6e8bbbbfa425771606f6c1aebc318e ] There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: SOF: ipc4-topology: Convert FLOAT to S32 during blob selection

2026-01-02T11:57:24+00:00

commit 816f291fc23f325d31509d0e97873249ad75ae9a upstream. SSP/DMIC blobs have no support for FLOAT type, they are using S32 on data bus. Convert the format from FLOAT_LE to S32_LE to make sure that the correct format is used within the path. FLOAT conversion will be done on the host side (or within the path). Fixes: f7c41911ad74 ("ASoC: SOF: ipc4-topology: Add support for float sample type") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Seppo Ingalsuo Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20251215120648.4827-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: SOF: ipc4-topology: Prefer 32-bit DMIC blobs for 8-bit formats as well

2026-01-02T11:57:24+00:00

commit 26e455064983e00013c0a63ffe0eed9e9ec2fa89 upstream. With the introduction of 8-bit formats the DMIC blob lookup also needs to be modified to prefer the 32-bit blob when 8-bit format is used on FE. At the same time we also need to make sure that in case 8-bit format is used, but only 16-bit blob is available for DMIC then we will not try to look for 8-bit blob (which is invalid) as fallback, but for a 16-bit one. Fixes: c04c2e829649 ("ASoC: SOF: ipc4-topology: Add support for 8-bit formats") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Seppo Ingalsuo Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20251215120648.4827-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

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.