summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)Author
2026-04-27ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful writesCássio Gabriel
snd_us16x08_comp_put() and snd_us16x08_eq_put() update their software stores before sending the USB write. If the transfer fails, later get callbacks report a value the hardware never accepted. Build the outgoing message from the current store plus the pending value, then commit the store only after a successful write. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-4-5a3bd4a673ae@gmail.com
2026-04-27ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch put ↵Cássio Gabriel
callbacks Several US-16x08 mixer put callbacks log failed control URBs but still return success to userspace. That hides device write failures even though the requested value was not applied. Return the negative write error instead in the route, master, bus, channel, and EQ switch put callbacks. Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-3-5a3bd4a673ae@gmail.com
2026-04-27ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()Cássio Gabriel
scarlett_ctl_enum_put() ignores the return value from snd_usb_set_cur_mix_value() and reports success whenever the requested enum value differs from the current one. If the SET_CUR request fails, the callback still returns success even though neither the hardware state nor the cached mixer value changed. Fixes: 76b188c4b370 ("ALSA: usb-audio: Scarlett mixer interface for 6i6, 18i6, 18i8 and 18i20") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-2-5a3bd4a673ae@gmail.com
2026-04-27ALSA: usb-audio: Propagate write errors in generic mixer put callbacksCássio Gabriel
mixer_ctl_feature_put(), mixer_ctl_procunit_put(), and mixer_ctl_selector_put() ignore failures from their SET_CUR helper routines and report the control as changed whenever the requested value differs from the current one. If the device rejects the write, userspace still sees success although the hardware state did not change. Propagate write failures instead, using filter_error() so ignore_ctl_error keeps the same semantics as the existing get paths. Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260419-usb-write-error-propagation-v1-1-5a3bd4a673ae@gmail.com
2026-04-27ALSA: opti9xx: restore snd-miro state after resumeCássio Gabriel
snd-miro has no PM callbacks, so system resume leaves the OPTi master-control registers and the board-specific ACI mixer state unrestored. Like snd-opti9xx, the driver needs to reprogram the OPTi routing registers before bringing the codec back. snd-miro also keeps mixer state in the ACI block, so the codec resume callback alone is not enough here. Save the ACI mixer state on suspend, reinitialize the OPTi and ACI state on resume, replay the saved ACI values, and then resume the WSS codec. Hook the PM handlers into both the ISA and PnP paths. Also initialize miro->card on the ISA path for the existing dev_*() logging and keep the cached solo-mode value aligned with the value written to hardware. PCM20 radio tuner state remains outside this driver's PM scope. Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260413-alsa-miro-pm-v1-1-07cc1ce3463c@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-27ASoC: Add TAS67524 quad-channel Class-D amplifier driverMark Brown
Sen Wang <sen@ti.com> says: This series adds support for the TI TAS675x (TAS6754, TAS67524) quad-channel automotive Class-D amplifiers. The devices have an integrated DSP and load diagnostics, and are controlled over I2C. Patch 1 adds the dt-binding, patch 2 the codec driver, patch 3 the ALSA mixer controls documentation, and patch 4 adds the MAINTAINERS entry. Tested on AM62D-EVM with a TAS67CD-AEC daughter card. For setup & test procedures, refer to the GitHub repository. GitHub: https://github.com/SenWang125/tas67-linux
2026-04-27ASoC: codecs: Add TAS67524 quad-channel audio amplifier driverSen Wang
The TAS675x (TAS6754, TAS67524) are quad-channel, digital-input Class-D amplifiers with an integrated DSP, controlled over I2C. They support I2S and TDM serial audio interfaces. Signed-off-by: Sen Wang <sen@ti.com> Link: https://patch.msgid.link/20260416232640.3084132-3-sen@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tegra210: simplify ADX/AMX byte map get/put logicMark Brown
Piyush Patle <piyushpatle228@gmail.com> says: The Tegra210 ADX and AMX drivers both keep their "Byte Map N" ALSA control state as a byte-packed u32 map[] array along with a separate byte_mask[] bitmap. This is because the control range exposed to userspace is [0, 256], where 256 is the "disabled" sentinel and does not fit in a byte, so the two arrays have to be cross-checked on every get()/put(). This series stores each slot as a u16 holding the user-visible value directly, turning get_byte_map() into a direct return and put_byte_map() into a compare-and-store. The hardware-facing packed RAM word and the IN_BYTE_EN / OUT_BYTE_EN enable masks are computed on the fly inside each write_map_ram() callback, which is the only place that needs to know the hardware layout. The byte_mask[] field is kept in the driver struct but allocated dynamically in probe() using devm_kcalloc() with soc_data->byte_mask_size, and zeroed + recomputed on each write_map_ram() call. There is no userspace-visible ABI change. Control declarations, ranges, initial values and handling of out-of-range writes is preserved by treating values outside [0, 255] as disabled (256), matching previous behavior. As a side effect each patch also fixes a latent bug in put_byte_map() where an enabled-to-enabled value change was not persisted. The packed RAM word construction is also updated to ensure the shift operates on a u32 value, avoiding potential undefined behavior due to signed integer promotion. Addresses TODO comments left in tegra210_{adx,amx}_get_byte_map().
2026-04-27ASoC: tegra210_amx: simplify byte map get/put logicPiyush Patle
The byte-map controls ("Byte Map N") already expose a value range of [0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the "disabled" sentinel. The driver stored this state as a byte-packed u32 map[] array plus a separate byte_mask[] bitmap tracking which slots were enabled, because 256 does not fit in a byte. As a result get_byte_map() had to consult byte_mask[] to decide whether to report the stored byte or 256, and put_byte_map() had to keep the two arrays in sync on every write. Store each slot as a u16 holding the control value directly (0..255 enabled, 256 disabled). This is the native representation for what userspace already sees, so get_byte_map() becomes a direct return and put_byte_map() becomes a compare-and-store. The hardware-facing packed RAM word and the OUT_BYTE_EN mask are now derived on the fly inside tegra210_amx_write_map_ram() from the slot array, which is the only place that needs to know about the hardware layout. The byte_mask buffer is allocated in probe() using devm_kcalloc() with soc_data->byte_mask_size, so it scales to any SoC variant without depending on chip-specific constants. It is zeroed and recomputed each time write_map_ram() is called. A new TEGRA_AMX_SLOTS_PER_WORD constant replaces the literal '4' used for byte slots per RAM word, and BITS_PER_BYTE / BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and '32' shifts. Slots are initialised to 256 in probe() so the default reported value stays "disabled", matching previous behaviour. Values written from userspace that fall outside [0, 255] are clamped to 256 ("disabled") exactly as before -- no userspace-visible change. As a side effect this also fixes a latent bug in the previous put_byte_map(): because it compared the enable mask rather than the stored byte, changing a slot from one enabled value to another enabled value (e.g. 42 -> 99) would early-return without persisting the new value, and the next CFG_RAM flush would still program the old byte. The new implementation compares the stored value itself, so this case is now handled correctly. Addresses TODO left in tegra210_amx_get_byte_map(). Signed-off-by: Piyush Patle <piyushpatle228@gmail.com> Link: https://patch.msgid.link/20260410200530.171323-3-piyushpatle228@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tegra210_adx: simplify byte map get/put logicPiyush Patle
The byte-map controls ("Byte Map N") already expose a value range of [0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the "disabled" sentinel. The driver stored this state as a byte-packed u32 map[] array plus a separate byte_mask[] bitmap tracking which slots were enabled, because 256 does not fit in a byte. As a result get_byte_map() had to consult byte_mask[] to decide whether to report the stored byte or 256, and put_byte_map() had to keep the two arrays in sync on every write. Store each slot as a u16 holding the control value directly (0..255 enabled, 256 disabled). This is the native representation for what userspace already sees, so get_byte_map() becomes a direct return and put_byte_map() becomes a compare-and-store. The hardware-facing packed RAM word and the IN_BYTE_EN mask are now derived on the fly inside tegra210_adx_write_map_ram() from the slot array, which is the only place that needs to know about the hardware layout. The byte_mask buffer is allocated in probe() using devm_kcalloc() with soc_data->byte_mask_size, so it scales to any SoC variant without depending on chip-specific constants. It is zeroed and recomputed each time write_map_ram() is called. A new TEGRA_ADX_SLOTS_PER_WORD constant replaces the literal '4' used for byte slots per RAM word, and BITS_PER_BYTE / BITS_PER_TYPE() from <linux/bits.h> replace the literal '8' and '32' shifts. Slots are initialised to 256 in probe() so the default reported value stays "disabled", matching previous behaviour. Values written from userspace that fall outside [0, 255] are clamped to 256 ("disabled") exactly as before -- no userspace-visible change. As a side effect this also fixes a latent bug in the previous put_byte_map(): because it compared the enable mask rather than the stored byte, changing a slot from one enabled value to another enabled value (e.g. 42 -> 99) would early-return without persisting the new value, and the next CFG_RAM flush would still program the old byte. The new implementation compares the stored value itself, so this case is now handled correctly. Addresses TODO left in tegra210_adx_get_byte_map(). Signed-off-by: Piyush Patle <piyushpatle228@gmail.com> Link: https://patch.msgid.link/20260410200530.171323-2-piyushpatle228@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: dt-bindings: fsl-sai: Document RX/TX BCLK swap supportMark Brown
Marek Vasut <marex@nabladev.com> says: ASoC: dt-bindings: fsl-sai: Document RX/TX BCLK swap support Link: https://patch.msgid.link/20260404183547.46509-1-marex@nabladev.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: fsl_sai: Add RX/TX BCLK swap supportMarek Vasut
Add support for setting the Bit Clock Swap bit in CR2 register via new "fsl,sai-bit-clock-swap" DT property. This bit swaps the bit clock used by the transmitter or receiver in asynchronous mode, i.e. makes transmitter use RX_BCLK and TX_SYNC, and vice versa, makes receiver use TX_BCLK and RX_SYNC. Signed-off-by: Marek Vasut <marex@nabladev.com> Link: https://patch.msgid.link/20260404183547.46509-2-marex@nabladev.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: ES8389: convert to devm_clk_get_optional() to get clockLi Jian
When enabling ES8390 via ACPI description, es8389 would fail to obtain a clock source, causing the driver to fail to initialize. This was not an issue with older kernels, but since commit abae8e57e49a ("clk: generalize devm_clk_get() a bit"), devm_clk_get() would return an error pointer when a clock source was not detected (instead of falling back to a static clock), causing the driver to fail early. Use devm_clk_get_optional() instead to return to the previous behaviour, allowing the use of a static clock source. Cc: stable@vger.kernel.org Signed-off-by: Li Jian <lazycat-xiao@foxmail.com> Link: https://patch.msgid.link/tencent_7C78374FB9F4B3A37101E5C719715D8BC40A@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: SOF: topology: allow user to add topologiesMark Brown
Bard Liao <yung-chuan.liao@linux.intel.com> says: This series adds a module parameter array to allow users to load specific feature topologies.
2026-04-27ASoC: SOF: topology: allow user to add topologiesBard Liao
Currently, the function topology provides the basic audio function. The commit allow the users add their topologies to the topology list. So they can add their own features. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20260421091351.4056377-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: sof-function-topology-lib: add virtual loop dai supportBard Liao
The virtual loop dai link is created by the machine driver and no topology is needed for the dai link. Handle it to avoid the dai_link is not supported error. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20260421091351.4056377-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: samsung: Use guard() for spin locksMark Brown
phucduc.bui@gmail.com <phucduc.bui@gmail.com> says: This series simplifies spinlock management across several Samsung ASoC drivers by adopting the guard() macro. All patches are strictly code refactoring with no functional changes intended.
2026-04-27ASoC: samsung: spdif: Use guard() for spin locksbui duc phuc
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125646.156599-6-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: samsung: pcm: Use guard() for spin locksbui duc phuc
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125646.156599-5-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: samsung: odroid: Use guard() for spin locksbui duc phuc
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125646.156599-4-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: samsung: idma: Use guard() for spin locksbui duc phuc
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125646.156599-3-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: samsung: i2s: Use guard() for spin locksbui duc phuc
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125646.156599-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: codecs: wcd937x: fix AUX PA sequencing and mixer controlsAjay Kumar Nandam
Enable AUX PA sequencing during AUX DAC DAPM events and keep the AUX-specific RX supplies enabled while the path is active. Add the missing AUX-related mixer controls, including CLSH PA and DSD left/right switches, so AUX playback can be routed from userspace. Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com> Link: https://patch.msgid.link/20260420180221.785113-1-ajay.nandam@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tegra: Remove stale snd-soc-tegra-utils composite module definitionSasha Levin
kconfiglint reports two warnings for sound/soc/tegra/Makefile: M002: composite module 'snd-soc-tegra-utils' defined but not in any obj-* M008: composite module 'snd-soc-tegra-utils': tegra_asoc_utils.o has no source file The composite module definition `snd-soc-tegra-utils-y += tegra_asoc_utils.o` references a source file that no longer exists and defines a module that is never included in any obj-* target. The tegra_asoc_utils module was originally introduced in commit a3cd50deef7b ("ASoC: Tegra: Move utilities to separate module") by Stephen Warren in 2011 to provide shared clock/rate utility functions for Tegra machine drivers. At that time, the Makefile had both the composite definition (`snd-soc-tegra-utils-objs`) and the build target (`obj-$(CONFIG_SND_TEGRA_SOC) += snd-soc-tegra-utils.o`). In 2021, commit 8c1b3b159300 ("ASoC: tegra: Squash utils into common machine driver") by Dmitry Osipenko merged tegra_asoc_utils.c into tegra_asoc_machine.c, deleting both the .c and .h files. That commit correctly removed the obj-* build target line but overlooked the composite module definition line (`snd-soc-tegra-utils-objs += tegra_asoc_utils.o`). The orphaned line persisted unnoticed and was even mechanically updated in 2024 by commit 51a50d6ad727 ("ASoC: tegra: Use *-y instead of *-objs in Makefile") by Takashi Iwai, which converted it from `-objs` to `-y` syntax as part of a treewide cleanup — inadvertently refreshing a stale definition. Remove the orphaned composite module definition since it serves no purpose: the source file was deleted, the obj-* target was already removed, and the functionality now lives in tegra_asoc_machine.c. Assisted-by: Claude:claude-opus-4-6 kconfiglint Signed-off-by: Sasha Levin <sashal@kernel.org> Link: https://patch.msgid.link/20260426000249.54799-1-sashal@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: rt722-sdca: add FU06 Playback Switch for speaker mute controlAaron Ma
The rt722-sdca codec driver exposes FU06 Playback Volume but no corresponding mute switch. Without a user-facing ALSA switch, UCM cannot attach the speaker mute LED via snd_ctl_led, and PipeWire cannot drive hardware mute. Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260423101338.1040131-1-aaron.ma@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tas2770: Fix order of operations for temperature calculationJames Calligeros
The order of operations to derive the temperature from the temp register values was wrong, since 1000 / 16 is not an integer. This resulted in the calculated temperature value deviating from the value represented by the registers slightly, which was most obvious when the registers were zeroed (-92.265 *C vs the expected -93.000 *C). Scale the reading before dividing the whole thing by 16 to correct this. Fixes: ff73e2780169 ("ASoC: tas2770: expose die temp to hwmon") Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-3-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tas2764: Mark die temp register as volatileJames Calligeros
Reading the temperature register always returns the first value read from the chip due to regcache. Mark TAS2764_TEMP as volatile to prevent returning stale, cached values when reading the die temp. Fixes: 186dfc85f9a8 ("ASoC: tas2764: expose die temp to hwmon") Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Link: https://patch.msgid.link/20260425-tas27xx-hwmon-fixes-v1-1-83c13b8e8f54@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: tlv320aic3x: Add multi endpoint supportMarek Vasut
Support multiple endpoints on TLV320AIC3xxx codec port when used in of_graph context. This patch allows to share the codec port between two CPU DAIs. Custom STM32MP255C board uses TLV320AIC3104 audio codec. This codec is connected to two serial audio interfaces, which are configured either as rx or tx. However, when the audio graph card parses the codec nodes, it expects to find DAI interface indexes matching the endpoints indexes. The current patch forces the use of DAI id 0 for both endpoints, which allows to share the codec DAI between the two CPU DAIs for playback and capture streams respectively. Signed-off-by: Marek Vasut <marex@nabladev.com> Link: https://patch.msgid.link/20260411130542.19777-1-marex@nabladev.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: SOF: Intel: add an empty adr_linkBard Liao
An empty adr_link is expected to terminate the for (adr_link = mach_params->links; adr_link->num_adr; adr_link++) loop. Allocate link_num + 1 links to add an empty adr_link. Fixes: 5226d19d4cae5 ("ASoC: SOF: Intel: use sof_sdw as default SDW machine driver") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260424105031.114053-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: amd: acp: Add DMI quirk for Valve Steam Deck OLEDGuilherme G. Piccoli
Commit 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") introduced a change that "broke" Steam Deck's audio probe, in the OLED model, as observed in the following dmesg snippet: [...] snd_sof_amd_vangogh 0000:04:00.5: Topology: ABI 3:26:0 Kernel ABI 3:23:1 sof_mach nau8821-max: ASoC: physical link acp-bt-codec (id 2) not exist sof_mach nau8821-max: ASoC: topology: could not load header: -22 snd_sof_amd_vangogh 0000:04:00.5: tplg amd/sof-tplg/sof-vangogh-nau8821-max.tplg component load failed -22 snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22 snd_sof_amd_vangogh 0000:04:00.5: ASoC error (-22): at snd_soc_component_probe() on 0000:04:00.5 sof_mach nau8821-max: ASoC: failed to instantiate card -22 sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max) sof_mach nau8821-max: probe with driver sof_mach failed with error -22 [...] Notice the quotes in "broke": it's not really a bug in such commit, but instead a problem with a topology file from Steam Deck OLED. This was discussed to great extent in [1], and Cristian proposed a pretty simple and functional change that resolved the issue for the Deck's issue. That change, though, would break other devices, so it wasn't accepted upstream. And the proper suggested solution (fix the topology) was never implemented, so Valve's kernel (and anyone that wants to boot the mainline on Steam Deck OLED) is carrying that fix downstream. So, we propose hereby a different approach: a DMI quirk, as many already present in the sound drivers, to address this issue solely on Steam Deck OLED, not breaking other devices and as a bonus, allowing simple patch up in case eventually the topology file gets fixed (we'd just need to check against any DMI info reflecting that or the topology/FW versions). The motivation of such upstream quirk is related to users that want to test latest kernel trees on their devices and get no only non-working sound device, but seems some games (like Ori and the Blind Forest) can't properly work without a proper functional audio device. Example of such report can be seen at [2]. Cc: Mark Brown <broonie@kernel.org> Cc: Robert Beckett <bob.beckett@collabora.com> Cc: Umang Jain <uajain@igalia.com> Fixes: 671dd2ffbd8b ("ASoC: amd: acp: Add new cpu dai and dailink creation for I2S BT instance") Link: https://lore.kernel.org/r/20231209205351.880797-11-cristian.ciocaltea@collabora.com/ [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=218677 [2] Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://patch.msgid.link/20260423183505.116445-1-gpiccoli@igalia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: atmel: Change manual bitfield manipulation to use FIELD_PREP()Gabriel Jacob Perin
Co-developed-by: Carlos Alberto Marques Rabelo <carlos.albmr@usp.br> Signed-off-by: Carlos Alberto Marques Rabelo <carlos.albmr@usp.br> Signed-off-by: Gabriel Jacob Perin <gabrieljp@usp.br> Link: https://patch.msgid.link/20260421193113.1060213-1-gabrieljp@usp.br Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: apple: mca: Use guard() for mutex locksbui duc phuc
Clean up the code using guard() for mutex locks. Merely code refactoring, and no behavior change. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260423125154.156257-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: ops: Log unknown controls in snd_soc_limit_volume()Mark Brown
When we fail to look up the control name in snd_soc_limit_volume() we don't log anything, the error code isn't particularly descriptive and checking the return value of the function at all is a bit erratic among the callers. Since there is no reason why anyone should ever be attempting to limit the volume of a nonexistant control add a log message in the core to improve usability. Link: https://patch.msgid.link/20260422-asoc-limit-volume-error-v2-1-2e2ced321229@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and ↵João
typo correction Replace manual bitfield manipulations with FIELD_GET() and FIELD_PREP() in order to improve code readability, security and manageability. Also correcting GENAMSK typo for GENMASK. Signed-off-by: João Marinho <joao.bcc@usp.br> Co-developed-by: Micael Vinicius <micael0208@usp.br> Signed-off-by: Micael Vinicius <micael0208@usp.br> Link: https://patch.msgid.link/20260420203218.15060-1-joao.bcc@usp.br Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-27ASoC: fsl_micfil: Add DC output remover controlShengjiu Wang
Add support for the DC output remover feature available on i.MX93 and newer platforms. This allows users to configure the output DC removal filter with cut-off frequencies of 20Hz, 13.3Hz, 40Hz, or bypass it entirely. The control is exposed as an ALSA mixer control and defaults to bypass mode. It is only available on platforms with the use_verid flag set (i.MX93+). Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20260420085344.2081805-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-24Merge tag 'sound-fix-7.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are the rest of small updates for 7.1-rc1. All small fixes mostly for device-specific issues or regressions. Core: - Fix a potential data race in fasync handling USB-audio: - New device support: Line6 POD HD PRO, NexiGo N930W webcam - Fixes for Audio Advantage Micro II SPDIF switch and E-MU sample rates - Limit UAC2 rate parsing to prevent potential overflows HD-Audio: - Device-specific quirks for HP, Acer, and Honor laptops - Fix for TAS2781 SPI device abnormal sound - Move Intel firmware loading into probe work to avoid stalling ASoC: - New support for TI TAS5832 - Fixes for SoundWire SDCA/DisCo boolean parsing - Driver-specific fixes for Intel SOF, ES8311, RT1320, and PXA2xx Misc: - Fixes for resource leaks and data races in 6fire, caiaq, als4000, and pcmtest drivers" * tag 'sound-fix-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (41 commits) Revert "ALSA: pcmtest: fix reference leak on failed device registration" ASoC: tas2781: Add tas5832 support ASoC: dt-bindings: ti,tas2781: Add TAS5832 support ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch ALSA: usb-audio: Avoid false E-MU sample-rate notifications ASoC: sdw_utils: cs42l43: allow spk component names to be combined ASoC: qcom: x1e80100: limit speaker volumes ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa2xxx ALSA: pcmtest: Fix resource leaks in module init error paths ALSA: usb-audio/line6: Add support for POD HD PRO ALSA: hda/realtek: Add LED fixup for HP EliteBook 6 G2a Laptops ASoC: SDCA: Fix reading of mipi-sdca-control-deferrable regmap: sdw-mbq: Allow defers on undeferrable controls Revert "ALSA: usb-audio: Add quirk for SmartlinkTechnology M01" ALSA: als4000: Fix capture trigger chip->mode race ALSA: core: Fix potential data race at fasync handling ALSA: hda/tas2781: Fix sound abnormal issue on some SPI device ALSA: hda/realtek: add quirk for Acer Nitro 16 AN16-41 ALSA: caiaq: Fix control_put() result and cache rollback ALSA: pcmtest: fix reference leak on failed device registration ...
2026-04-23Revert "ALSA: pcmtest: fix reference leak on failed device registration"Takashi Iwai
We'd like to address the problem rather in the error code path of platform_device_register() itself instead of leaving it all callers, since less than 1% of all callers of over 100 platform_device_register() do call platform_device_put() properly as of now. For making the work easier, revert the previous change commit 4ff036f95238 ("ALSA: pcmtest: fix reference leak on failed device registration") again. Link: https://lore.kernel.org/20260415193138.3861297-1-lgs201920130244@gmail.com Link: https://patch.msgid.link/20260423075211.3977366-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-23Merge tag 'asoc-fix-v7.1-merge-window' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.1 A fairly small collection of fixes, device IDs and quirks that came in during the merge window, the most remarkable of which is one for SDCA boolean firmware flags which is remarkable mainly because it is partially in regmap.
2026-04-22ASoC: dt-bindings: ti,tas2781: Add TAS5832 supportMark Brown
Baojun Xu <baojun.xu@ti.com> says: Link: https://patch.msgid.link/20260414015441.2439-1-baojun.xu@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-22ASoC: tas2781: Add tas5832 supportBaojun Xu
TAS5832 is in same family with TAS5827/28/30. Signed-off-by: Baojun Xu <baojun.xu@ti.com> Link: https://patch.msgid.link/20260414015441.2439-2-baojun.xu@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-22ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switchCássio Gabriel
snd_microii_spdif_switch_put() returns 0 when the requested vendor register value differs from the cached one. This comparison was inverted by the resume-support conversion, so real SPDIF switch toggles are ignored while no-op writes still issue SET_CUR and report success. Return early only when the requested value matches the cached one. Fixes: 288673beae6c ("ALSA: usb-audio: Add resume support for MicroII SPDIF ctls") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260421-microii-spdif-switch-fix-v1-1-5c50dc28b88f@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-22ALSA: usb-audio: Avoid false E-MU sample-rate notificationsCássio Gabriel
snd_emuusb_set_samplerate() unconditionally notifies the E-MU SampleRate Extension Unit control after issuing SET_CUR. If snd_usb_mixer_set_ctl_value() fails, the control value has not changed, yet snd_usb_mixer_notify_id() still invalidates the cache and emits a value-change event to userspace. Notify the control only after a successful write. Fixes: 7d2b451e65d2 ("ALSA: usb-audio - Added functionality for E-mu 0404USB/0202USB/TrackerPre") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260421-alsa-emuusb-samplerate-notify-v1-1-8b63bbc1d7f1@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-22ASoC: sdw_utils: cs42l43: allow spk component names to be combinedMaciej Strozek
Move handling of cs42l43-spk component string into SOF mechanism [1] which will allow it to be aggregated with other speakers. Likewise handle the cs35l56-bridge special case which should not be combined to keep compatibility with UCM. Link: https://github.com/thesofproject/linux/pull/5445 [1] Link: https://github.com/alsa-project/alsa-ucm-conf/pull/747 Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Suggested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Aaron Ma <aaron.ma@canonical.com> Link: https://patch.msgid.link/20260420114823.194226-1-mstrozek@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-22ASoC: qcom: x1e80100: limit speaker volumesTobias Heider
Limit the digital gain and PA volumes to a combined -3 dB in the machine driver to reduce the risk of speaker damage until we have active speaker protection in place (or higher safe levels have been established). Based on commit c481016bb4f8 ("ASoC: qcom: sc8280xp: limit speaker volumes") which addressed the same issue on the sc8280x SoC with some minor changes as explained below. The Digital Volume behaves almost identical to sc8280x since both use the same lpass-wsa-macro, but x1e80100 has two sets of controls prefixed with WSA and WSA2. For PA x1e80100 machines use wsa884x amplifiers which expose a linear scale from -9 dB to 9 dB with a 1.5 dB step size giving us 0 dB = -9 dB + 6 * 1.5 dB. On x1e80100 there are two different speaker topologies we need to handle: 2-Speakers: SpkrLeft, Spkr Right 4-Speakers: WooferLeft, WooferRight, TweeterLeft, TweeterRight Signed-off-by: Tobias Heider <tobias.heider@canonical.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260422-x1e80100-audio-limit-v2-1-333258b97697@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-21ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa2xxxSpencer Payton
The mute LED on this laptop uses ALC245 but requires a quirk to work. This patch enables the existing ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device. Tested my Victus 15-fa2xxx (PCI SSID 103c:8dcd). The LED behaviour works as intended. Cc: stable@vger.kernel.org Signed-off-by: Spencer Payton <spayton681@gmail.com> Link: https://patch.msgid.link/20260421084918.14685-1-spayton681@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-21ALSA: pcmtest: Fix resource leaks in module init error pathsCássio Gabriel
pcmtest allocates its pattern buffers and creates its debugfs tree before registering the platform device and driver, but mod_init() does not release those resources when a later init step fails. As a result, a debugfs directory creation failure leaks the pattern buffers, while platform_device_register() and platform_driver_register() failures leave both the pattern buffers and the debugfs tree behind. The recent fix for failed device registration only dropped the embedded device reference. Add the missing cleanup for the debugfs tree and pattern buffers in the remaining module init error paths. Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260421-alsa-pcmtest-init-unwind-v1-1-03fe0c423dbb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-21ALSA: usb-audio/line6: Add support for POD HD PROPhil Willoughby
The POD HD PRO is the rackmount version of the POD 500, with most of the same behaviors. As with some of the other rackmount POD devices it will not send captured audio to the host unless the host is sending playback audio, so it has LINE6_CAP_IN_NEEDS_OUT in addition to the POD 500 flags. Tested-By: Phil Willoughby <willerz@gmail.com> Signed-off-by: Phil Willoughby <willerz@gmail.com> Link: https://patch.msgid.link/20260420152405.7230-1-willerz@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-21ALSA: hda/realtek: Add LED fixup for HP EliteBook 6 G2a LaptopsChris Chiu
The HP EliteBook 6 G2a laptops requires specific LED control method ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF to work. Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Link: https://patch.msgid.link/20260421023429.3723154-1-chris.chiu@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-04-20ASoC: Correct bug parsing DisCo booleansMark Brown
Charles Keepax <ckeepax@opensource.cirrus.com> says: MIPI DisCo uses the unfortunate convention of allowing boolean properties to be present but having a zero value. Opposed to the normal convention of simply not specifying the property. Fix an issue in the SDCA code where mipi-sdca-control-deferrable is not parsed correctly. However, we also have some shipping ACPIs where these properties are not specified correctly. Update the MBQ regmap to attempt defers albeit with a warning in the case where a control attempts to defer but is not marked at such. There is little down side to this as if defer is genuinely not supported then the control will just return the same error again.
2026-04-20ASoC: SDCA: Fix reading of mipi-sdca-control-deferrableCharles Keepax
The discussion in [1] highlighted that the SDCA code shouldn't be using fwnode_property_read_bool() for DisCo controls, as the spec allows setting the value to zero meaning the property should not be used. Correct a small bug in the SDCA code that will mark such controls as deferrable. Link: https://lore.kernel.org/linux-sound/20260311142153.2201761-1-rf@opensource.cirrus.com/ [1] Fixes: 42b144cb6a2d ("ASoC: SDCA: Add SDCA Control parsing") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260413124621.1345315-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>