kernel/linux.git/sound/soc, branch v7.2-rc7

ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables

2026-08-05T12:34:37+00:00

Peter Ujfalusi says: reg_defaults must be sorted by ascending register address as regcache_lookup_reg() locates the entries in it with bsearch(), see commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). These three tables have entries which are out of order, so the binary search does not find part of them. For those registers regcache_reg_needs_sync() cannot compare the cached value against the default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. The patches only reorder the existing entries, the text of every entry is kept verbatim and no default value is changed. Each table was verified by evaluating the register addresses and replaying lib/bsearch.c on them. Entries not reachable by the binary search, per table: cs35l41_reg 2 (of 47) cs35l45_defaults 36 (of 73) cs4265_reg_defaults 3 (of 16) For cs35l45 this is nearly half of the table: the DSP1_RX*_RATE and DSP1_TX*_RATE registers sit in the middle of it while their addresses are far above everything else, which cuts the search off from the whole 0x4c40 - 0xf010 range. Found by an audit of all reg_defaults tables under sound/, the SoundWire codec drivers are fixed by a separate series. Link: https://patch.msgid.link/20260805082413.26174-1-peter.ujfalusi@linux.intel.com

ASoC: cs4265: sort the register default table

2026-08-05T12:34:36+00:00

reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs4265_reg_defaults[] lists CS4265_INT_MASK (0x0e), CS4265_STATUS_MODE_MSB (0x0f) and CS4265_STATUS_MODE_LSB (0x10) after CS4265_SPDIF_CTL1 (0x11) and CS4265_SPDIF_CTL2 (0x12), so the binary search does not find those three entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: fb6f806967f6 ("ASoC: Add support for the CS4265 CODEC") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: cs35l45: sort the register default table

2026-08-05T12:34:35+00:00

reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l45_defaults[] lists the DSP1_RX*_RATE and DSP1_TX*_RATE registers (0x02b80080 - 0x02b802b8) in the middle of the table, ahead of entries with much lower addresses, so the binary search does not find 36 of its 73 entries. regcache_reg_needs_sync() then cannot compare those against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 74b14e2850a3 ("ASoC: cs35l45: DSP Support") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: cs35l41: sort the register default table

2026-08-05T12:34:34+00:00

reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). cs35l41_reg[] lists CS35L41_BSTCVRT_PEAK_CUR (0x3808) after CS35L41_BSTCVRT_COEFF (0x3810) and CS35L41_BSTCVRT_SLOPE_LBST (0x3814), so the binary search does not find those two entries. regcache_reg_needs_sync() then cannot compare them against their default and reports that a sync is needed, so they are written to the device on every regcache_sync() even when they were never touched. Sort the table by register address. Fixes: 5f2f539901b0 ("ASoC: cs35l41: Correct handling of some registers in the cache") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Charles Keepax Reviewed-by: Richard Fitzgerald Link: https://patch.msgid.link/20260805082413.26174-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: amd: yc: Add DMI quirk for MSI Raider A18 HX A7VHG

2026-08-05T11:52:55+00:00

Add a DMI quirk for the MSI Raider A18 HX A7VHG fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221574 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260805091600.318018-2-zhangheng@kylinos.cn Signed-off-by: Mark Brown

ASoC: amd: yc: Add DMI quirk for Xiaomi RedmiBook 16 2025

2026-08-05T11:52:54+00:00

Add a DMI quirk for the Xiaomi RedmiBook 16 2025 (AMD) fixing the issue where the internal microphone was not detected. Link: https://github.com/thesofproject/linux/issues/5860 Signed-off-by: Zhang Heng Link: https://patch.msgid.link/20260805091600.318018-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown

ASoC: rt5645: Make the Kconfig symbol user selectable

2026-08-03T18:45:03+00:00

SND_SOC_RT5645 has no prompt, so it can only be turned on by a machine driver that selects it. Every such driver is x86, MediaTek or Rockchip, which leaves the codec unreachable on any other platform. The part has a devicetree binding of its own, Documentation/devicetree/bindings/sound/realtek,rt5645.yaml, and nothing in the driver is machine specific, so a board that describes it with simple-audio-card or audio-graph-card should be able to build it. Today there is no configuration in which that is possible. Give the symbol a prompt, matching SND_SOC_RT5640 immediately above it. The machine drivers that select it are unaffected. Signed-off-by: Rudi Heitbaum Link: https://patch.msgid.link/anCcciWmO6QOLTsl@5e001e58230e Signed-off-by: Mark Brown

ASoC: codecs: lpass-{tx,wsa}-macro: fix enum kcontrol accesses

2026-08-01T00:02:01+00:00

Dawid Wróbel says: Both drivers access enumerated controls through value.integer.value[0] instead of value.enumerated.item[0]. The same bug was fixed in rx-macro and va-macro in 2022 (bcfe5f76cc40, 0ea5eff7c606); tx-macro and wsa-macro were missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check, and every read of the affected controls fails with -EINVAL. Reproduced and fixed on a Xiaomi Mi Pad 5 Pro (SM8250) for tx-macro. wsa-macro is compile-tested only — that codec is not instantiated on this hardware. Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-0-6d091c736116@dawidwrobel.com

ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses

2026-08-01T00:01:59+00:00

EAR SPKR PA Gain" and the four "WSA RX* Mux" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL. Fixes: 809bcbcecebf ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro") Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Assisted-by: Claude:claude-fable-5 Cc: stable@vger.kernel.org Signed-off-by: Dawid Wróbel Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-2-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown

ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses

2026-08-01T00:01:58+00:00

The "DEC0 MODE" to "DEC7 MODE" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type") and commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array out of bounds for enum type"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow Fixes: c39667ddcfc5 ("ASoC: codecs: lpass-tx-macro: add support for lpass tx macro") Assisted-by: Claude:claude-fable-5 Cc: stable@vger.kernel.org Signed-off-by: Dawid Wróbel Reviewed-by: Srinivas Kandagatla Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-1-6d091c736116@dawidwrobel.com Signed-off-by: Mark Brown