linux.git/sound/soc/codecs, branch v7.2

ASoC: tac5xx2-sdw: select REGMAP_SOUNDWIRE_MBQ

2026-08-11T13:49:28+00:00

 "select REGMAP_SOUNDWIRE_MBQ" to fix build error:
 ERROR: modpost: "__devm_regmap_init_sdw_mbq"
  [sound/soc/codecs/snd-soc-tac5xx2-sdw.ko] undefined!

Signed-off-by: Niranjan H Y 
Link: https://patch.msgid.link/20260807151623.3005-1-niranjan.hy@ti.com
Signed-off-by: Mark Brown

ASoC: rt1320: run the initialisation preset on the first hardware init

2026-08-10T14:46:13+00:00

rt1320_io_init() applies the vendor initialisation preset only when the
amplifier's SDCA function status has FUNCTION_NEEDS_INITIALIZATION set:

	if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION)) {

Its two sibling drivers guard the same write differently, also running
the preset on the first hardware init:

  rt712-sdca.c:  if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) ||
                     (!rt712->first_hw_init)) {
  rt722-sdca.c:  if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) ||
                     (!rt722->first_hw_init)) {

On the Microsoft Surface Pro 11 (Intel) the RT1320 never sets that bit.
Its function status reads back 0x41 on every boot, cold or warm:

  rt1320-sdca sdw:0:0:025d:1320:01: rt1320_io_init amp func_status=0x41

which is NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET: the function reports
that it has been reset and does not consider itself in need of
initialisation. Bit 5 is never set, so the preset never runs,
rt1320_vc_preset() and the MCU patch load are skipped, and the amplifier
is left unprogrammed. rt712 and rt722 would have run it via their
first_hw_init fallback.

Add the same fallback. With it rt1320_vc_preset() executes and the
amplifier reports RT1320_KR0_INT_READY=0x1f where previously it did not.

Signed-off-by: Sergey Lebedev 
Link: https://patch.msgid.link/20260804225853.31585-2-lsa.uz@pm.me
Signed-off-by: Mark Brown

ASoC: rt5645: Perform the initial jack detect at probe

2026-08-10T13:07:22+00:00

The only initial jack detect is the rt5645_irq(0, rt5645) at the end of
rt5645_set_jack_detect(). A card described with simple-audio-card has no
machine driver to call that, so jack state is only ever sampled from an
edge on hp-detect-gpios.

A headphone already in the socket at boot is therefore never noticed, and
the card is silent with every mixer control set correctly.
rt5645_jack_detect() is what force enables the "LDO2" and "Mic Det Power"
supplies that the "HP amp" widget depends on, and what programs
RT5645_CHARGE_PUMP away from its reset value, so without it "HP amp"
cannot power up. Unplugging and replugging the jack is the only way to
recover.

Do the detect at the end of the component probe when the driver owns a
hp-detect GPIO and the codec's own jack detect is unused, which is the
case that has no other trigger. A machine driver calling
rt5645_set_jack_detect() later just repeats it.

Signed-off-by: Rudi Heitbaum 
Link: https://patch.msgid.link/anNU3tOUR7rOReSB@5e001e58230e
Signed-off-by: Mark Brown

ASoC: tas2781: fix clang build error for goto bypassing cleanup variable

2026-08-10T12:27:44+00:00

Remove invalid goto exit paths that jump across guard(mutex) cleanup
variable initialization, replace them with direct kfree(src) and return,
to fix the s390 clang build error in acoustic_ctl_write().

Fixes: d75d38dc4604 ("ASoC: tas2781: Add a debugfs node for acoustic tuning")
Signed-off-by: Shenghao Ding 
Link: https://patch.msgid.link/20260807000304.826-1-shenghao-ding@ti.com
Signed-off-by: Mark Brown

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: 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