A fairly big batch of fixes that came in during the merge window.
There's a lot of quirks for x86 systems and a bunch of driver specific
fixes, the most critical being the fixes for Tegra's register
definitions. It turned out that they had been relying on the regmap
default handling bugs that were fixed in v7.2 and so audio was fairly
badly broken, unfortunately the issue wasn't noticed in time for
release.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqQONIACgkQJNaLcl1U
h9Dzbgf+OYlkheBcs0+Go3wKN+5JEQBCQl3vjbAbR9bq2XXEUTR5SNIIjAgG7YfS
XRFc91Nfx9mwqW8y128ITZ09Ao1xQKjSrzaa0WxSIjR2gx2WJMMhwGdFNvH/fehf
JKoIRXJ4qYXalfrrqXiTMFJHfSaZxDoDbMg+2Wipqi/xOuWWO+1eDNW0dnmkF422
stpXIShNh7ljlcBgpH6ts3ZpkPkwRcVOpFrBsqtbFcTAlw1XbMwjHAPYVSHm03wt
5dpIZd4b2XA51zqH3z8RTlX+0U2xDilAMU3K74qyzxKPAi9I8FahoKPu5H7kMa77
6ly9hBSmcOWnRb9mXfhY8GxXaxXDIA==
=T5wt
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.3-merge-window' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
A fairly big batch of fixes that came in during the merge window.
There's a lot of quirks for x86 systems and a bunch of driver specific
fixes, the most critical being the fixes for Tegra's register
definitions. It turned out that they had been relying on the regmap
default handling bugs that were fixed in v7.2 and so audio was fairly
badly broken, unfortunately the issue wasn't noticed in time for
release.
The kcontrol LED state layer tries to track the all associated
kcontrol elements with naive assumptions that they are readable.
But one can create a write-only element that has no get callback (even
a user element can do it), and this may lead to a NULL dereference at
the call chain of snd_ctl_led_notify(), as found by syzkaller.
For avoiding the Oops, add a sanity check of the kcontrol's info and
get callbacks, and just skip the invalid kcontrols before assigning
the kctl to the LED layer.
Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com
Fixes: 22d8de62f1 ("ALSA: control - add generic LED trigger module as the new control layer")
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de
Rename the function to cx_process_headset_detect_plug_type() to reflect
that it only reports the detected plug type, and move the pin control
write into cx_update_headset_mic_vref() so that node 0x19 is always set
to enable the headset mic with the 80% VREF whenever the mic is
present, regardless of the type detection result.
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260826115344.2128835-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches
e->items, but it lets item[1] be equal to it. Both go on to
snd_soc_enum_item_to_val(), which indexes e->values with no bound of
its own, so an enum with a value table reads one element past the end.
The indexing arrived with the MUX consolidation, which relaxed the
item[1] check in the same hunk. The value MUX handler it deleted used
>= there, and the snd_soc_put_enum_double() in soc-ops.c still does.
Only adav80x pairs a value table with two shifts, and its second
channel looks accidental, but the control does report two values.
Writing three into it reads off the end of adav80x_mux_values. The
core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which
defaults off.
Fixes: 3727b49684 ("ASoC: dapm: Consolidate MUXs and value MUXs")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260825125745.932832-1-sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The BIOS on the HP OmniBook X Flip 16-cc0xxx (board 8EA2) reports
acp-audio-config-flag = FLAG_AMD_LEGACY_ONLY_DMIC. This binds the
legacy ACP driver and registers a PDM-only card, so the SoundWire
links are never scanned and the two TAS2783 speaker amplifiers and
RT712-VB codec do not enumerate.
Add a DMI entry for board 8EA2 to the ACP70 ACPI flag override table
so the firmware-provided flag is overridden and snd_pci_ps probes
instead.
On the affected system, an otherwise identical upstream kernel
without this entry binds snd_acp_pci, enumerates no SoundWire slave
devices and exposes no internal speaker PCM. With the entry added,
snd_pci_ps binds, both TAS2783 amplifiers and the RT712-VB enumerate
over SoundWire, and the amd-soundwire card exposes the internal
speaker playback PCM.
Developed with AI assistance. ChatGPT helped analyze the ACP and
SoundWire behavior, structure the controlled A/B testing, and draft
the patch changelog. All hardware measurements, kernel builds,
reboots and playback tests were performed by the submitter. The
submitter has reviewed the change, understands it and takes
responsibility for it.
Assisted-by: ChatGPT:GPT-5.6 Sol
Signed-off-by: Sehat Mahde <hskmahde@gmail.com>
Link: https://patch.msgid.link/20260825224640.13662-1-hskmahde@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add matching DMI table entry for the ES83xx machine driver, so the
HUAWEI HVY-WXX9 / M1060 board (MateBook D16 2021, Ryzen 5 4600H) can
successfully probe its ES8316 codec via the acp3x-es83xx machine
driver, consistent with the existing M1010/M1020/M1040 entries for
the same board name.
Signed-off-by: Mehmet Aysel <mehmet4ysel@gmail.com>
Link: https://patch.msgid.link/20260825092432.56292-2-mehmet4ysel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add DMI match table entry for HUAWEI HVY-WXX9 board, product version
M1060, a MateBook D16 2021 (Ryzen 5 4600H) revision not covered by the
existing M1010/M1020/M1040 entries. This board uses the same
FLAG_AMD_LEGACY / ACP_PCI_DEV_ID configuration as the other HVY-WXX9
variants.
Signed-off-by: Mehmet Aysel <mehmet4ysel@gmail.com>
Link: https://patch.msgid.link/20260825092432.56292-1-mehmet4ysel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The DMA channel request code currently warns about legacy DMA failures
when the channel name is not present in dma-names. This can report a
firmware lookup failure as a legacy DMA failure.
Furthermore, failures from the legacy DMA path are already reported by
find_candidate(), making these warnings redundant.
Only warn when the channel name is present in dma-names but the request
fails, avoiding misleading and duplicate error messages.
Fixes: 9167f26047 ("ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly")
Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/all/aoyBuho270dTWYBL@jupiter.universe/
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260825081949.55537-1-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
HP Laptop 15-fd0039nt (SSID 103c:8bb6) needs a quirk to control the
speaker mute LED via VREF100 on NID 0x1a (active-high).
This patch replaces the previous ALC236_FIXUP_HP_MICMUTE_LED_ONLY
with ALC236_FIXUP_HP_15_FD0XXX, which covers both mic mute (GPIO0)
and speaker mute (NID 0x1a) LEDs.
Use spec->no_shutup_pins instead of a custom shutup hook, as suggested
by Takashi Iwai.
Fixes: e711ebfadc ("ALSA: hda/realtek: Add quirk for HP Laptop 15-fd0039nt")
Tested-by: Habil Eren Türker <habilerenturker@hotmail.com>
Signed-off-by: Habil Eren Türker <habilerenturker@hotmail.com>
Link: https://patch.msgid.link/20260825084125.4103-1-habilerenturker@hotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A failed system resume can leave the card unusable until reboot.
usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or
snd_usb_mixer_resume() fails. The error path skips the out: block, which
restores D0 and decrements chip->num_suspended_intf.
The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in
snd_power_ref_and_wait(). USB core logs an interface resume callback error.
It does not retry that callback, so a later callback cannot complete the
skipped cleanup.
usb_audio_suspend() increments num_suspended_intf before returning success.
A system-resume callback must consume the system-suspend count even if a
component resume fails. Otherwise, the stranded count skews later suspend
and resume cycles.
Do not apply this cleanup to runtime-resume errors. Runtime PM can retry
-EAGAIN or -EBUSY without another suspend callback. The count must continue
to describe that suspended interface. Other runtime-resume errors latch
runtime_error in the PM core and do not cause an immediate callback retry.
Both parts of the system-resume error path are longstanding. Commit
88a8516a21 ("ALSA: usbaudio: implement USB autosuspend") introduced
err_out past the D0 restore. Commit 862b2509d1 ("ALSA: usb-audio: Fix
inconsistent card PM state after resume") later moved
num_suspended_intf-- into the out: block. The error path now skips both
operations.
No third-party code is needed to reach the error path.
snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the
result of usb_submit_urb() for devices that have a mixer status URB. Its
mixer->private_resume hook can also fail through scarlett2_init_notify().
snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It
can return -EPIPE or -EIO when the device stalls the request.
Route a component error through out: only when system_suspend is nonzero.
Continue to return runtime-resume errors through err_out. Later component
resume stages remain skipped. The original error still reaches USB core.
A later transfer can fail if the device did not recover.
I reproduced the system-resume failure on an Audient iD14 MkI with an
out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched
core left control readers in uninterruptible sleep in
snd_power_ref_and_wait() until a reboot. With this patch, the same failure
restored control access. A second system suspend and resume also succeeded
after I disabled fault injection.
Assisted-by: Claude:claude-opus-5
Assisted-by: Antigravity:gemini-3.1-pro-high
Assisted-by: Codex:gpt-5.6-sol
Fixes: 88a8516a21 ("ALSA: usbaudio: implement USB autosuspend")
Fixes: 862b2509d1 ("ALSA: usb-audio: Fix inconsistent card PM state after resume")
Cc: <stable@vger.kernel.org>
Signed-off-by: Will Porter <mrwillporter@gmail.com>
Link: https://patch.msgid.link/20260824225757.26749-1-mrwillporter@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The internal microphone on Lenovo IdeaPad Slim 3 15ABR8 (subsystem
17aa:3862) exhibits severe distortion at default gain levels. The
Capture Volume is fixed at 63 (max) and cannot be lowered without
explicit userspace intervention. The existing fixup
ALC269_FIXUP_LIMIT_INT_MIC_BOOST limits the gain range and resolves
the issue.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221891
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260824123752.525173-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails.
The return value was passed to request_irq() without checking for
failure.
Check the return value before passing it to request_irq().
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260824100730.31601-1-phucduc.bui@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The M-Audio Venom (0763:2084) does not answer any GET_CUR request
of its feature units, hanging up the USB microcontroller and
"responding" with timeouts. So the mixer building lasts around 47
seconds, and the device does not stream at all.
The same GET_CUR requests issued through libusb (with no kernel
driver bound) complete correctly and blazingly fast. So it seems
to only happen during the initial probe.
I defined an explicit composite quirk to bypass the mixer creation,
as it is not needed (the synth already comes with volume controls).
With both this and the device flag applied, the synth works
flawlessly.
Signed-off-by: Federico Valentín Andrade <fandrade@frba.utn.edu.ar>
Link: https://patch.msgid.link/20260824140211.17003-3-fandrade@frba.utn.edu.ar
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The M-Audio Venom (0763:2084) is an USB Audio Class 1 compliant
synth with an integrated audio interface, it does not implement
GET_CUR on SAMPLING_FREQ_CONTROL, hanging up if requested on
endpoint 0.
The first class request issued by the driver after enumeration is
a GET_CUR on endpoint 0x02, freezing the device's USB microcontroller.
Timing out on every transfer afterwards with -ETIMEDOUT, such as
SET_INTERFACE, so neither the mixer nor any streaming interface is set up.
Analyzing a USBPcap capture of the Windows driver I found it never
requests the sampling frequency, as the synth exposes a single
discrete of 44100Hz on both streaming interfaces, thus asking for it
is unnecessary.
So I applied get_sample_rate to avoid this check, and
disable_autosuspend because the synth doesn't come back from being
suspended.
Signed-off-by: Federico Valentín Andrade <fandrade@frba.utn.edu.ar>
Link: https://patch.msgid.link/20260824140211.17003-2-fandrade@frba.utn.edu.ar
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_usbmidi_novation_output() lays out a two-byte header at
transfer_buffer[0..1] and passes &transfer_buffer[2] together with a
length of ep->max_transfer - 2 to snd_rawmidi_transmit():
count = snd_rawmidi_transmit(ep->ports[0].substream,
&transfer_buffer[2],
ep->max_transfer - 2);
ep->max_transfer comes from the output endpoint's wMaxPacketSize via
usb_maxpacket(). A malformed or malicious device can advertise a bulk
OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this
value downwards - so ep->max_transfer becomes 1 and the count argument
becomes -1.
snd_rawmidi_transmit() passes the negative count on to
__snd_rawmidi_transmit_peek(), where "if (count1 > count) count1 = count"
leaves count1 negative; get_aligned_size() keeps it negative for a
byte-stream substream, so the following memcpy(buffer, ..., count1) runs
with a (size_t)-1 length and writes far past the transfer buffer, which
was allocated with usb_alloc_coherent(ep->max_transfer).
This is the same class of bug that was fixed for snd_usbmidi_akai_output()
in commit 0970274613 ("ALSA: usb-audio: fix OOB write in
snd_usbmidi_akai_output()"); the novation output routine was left
unguarded. Bail out when the endpoint cannot hold the two-byte header
plus at least one payload byte.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Marouane El Moufid <eun0us@espilon.net>
Link: https://patch.msgid.link/178749334830.543645.13722252148340572274@espilon.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the iD14 MkI USB ID to the existing audient_id14_map. This
names feature unit 12 Monitor Mix Playback Volume.
Live meter A/B testing on MkI USB ID 2708:0002 reproduced the same
asymmetric attenuation seen on MkII. At ALSA value 104, the right
channel was 23.07 dB below the left. At 127, both channels were equal.
The misleading Speaker Playback Volume name causes PipeWire to adopt
FU12 as the stream master. Reuse the existing map to keep the control
available while preventing that selection.
Hardware-tested on Bazzite 7.2.0-ogc4.1.fc44.x86_64 with this change
backported. ALSA exposed Monitor Mix Playback Volume after module load
and USB reconnect. PipeWire volume changes from 100% to 35% and back
left all four FU12 values at 127. Channel-isolated left/right playback
remained balanced after reconnect.
Build-tested with CONFIG_SND_USB_AUDIO=m using the focused sound/usb
target.
Assisted-by: Codex:gpt-5
Signed-off-by: Will Porter <mrwillporter@gmail.com>
Link: https://patch.msgid.link/20260823015353.686080-1-mrwillporter@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Logitech PRO X Wireless is a wireless headset with a hotpluggable
microphone.
Its Playback mixer's GET_CUR somehow becomes broken when the microphone
is detached, so set QUIRK_FLAG_MIXER_GET_CUR_OK to prevent the mixer
behavior from depending on whether the microphone is attached.
Meanwhile, the Playback mixer's minimum value doesn't work properly,
thus set QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE to prevent userspace audio
stack from using the minimum mixer value to tune volume (setting it
when muted is OK).
Reported-by: Alexander Niemeyer <adventureFAN@gmx.de>
Closes: https://msgid.link/6262cbbd-d1f2-4c9d-a1c7-9c5d12636f4b@gmx.de
Closes: https://msgid.link/7984832b-86f6-4934-bfc0-1ed70218973a@gmx.de
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-4-a8cbe572edff@rong.moe
The default behavior of sticky check now becomes what
QUIRK_FLAG_MIXER_GET_CUR_BROKEN originally does, so the quirk flag is no
longer needed.
On some devices, whether their GET_CUR being sticky depends on whether
hotpluggable components are present. When the hotpluggable components
are missing on probe, their GET_CUR behavior is classified as broken.
Therefore, reverse QUIRK_FLAG_MIXER_GET_CUR_BROKEN as
QUIRK_FLAG_MIXER_GET_CUR_OK, so that it can be set to prevent the
heuristics from gating GET_CUR.
Note that even if the quirk flag is set, init_cur_mix_raw() should still
initialize the mixer value to cval->min, otherwise restoring the bogus
saved value on the first channel could lead to unbalanced channels.
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-3-a8cbe572edff@rong.moe
Currently, a mixer is disabled when its GET_CUR is sticky, causing
userspace to fall back to soft mixers, unless
QUIRK_FLAG_MIXER_GET_CUR_BROKEN is set. This leads to issues on some
wireless headphones with broken GET_CUR but effective SET_CUR, which use
poorly-performed lossy codecs and are prone to audible distortion at low
volume. They have to set the quirk flag to reeanble the mixer.
Considering that users can always opt into soft mixers if they need it,
i.e., when SET_CUR is stubbed, demote the severity of sticky GET_CUR by
marking GET_CUR as broken and only provide mixer values from the cache.
The mixer itself is still registered.
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-2-a8cbe572edff@rong.moe
QUIRK_FLAG_ALWAYS_SET_RATE was introduced into usb-audio before without
appropriate documentation, so add it.
There is an odd colon in its comments, so remove it too.
As this is often forgotten, also add a reminder to the end of the
enumeration.
Fixes: 786f91da85 ("ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS")
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260823-uac-demote-sticky-check-v1-1-a8cbe572edff@rong.moe
The SMSL USB DAC with USB ID 152a:85dd produces an audible pop
when snd-usb-audio performs its redundant probe-time interface setup.
It also pops when returning from runtime suspend.
Skip the probe-time interface setup and disable runtime autosuspend for
this device. Both flags have been verified through the quirk_flags module
parameter.
Keep QUIRK_FLAG_DSD_RAW in the device entry because the exact match takes
precedence over the generic 0x152a vendor entry from which the device
currently inherits that flag.
Signed-off-by: Edward Blair <edward.blair@gmail.com>
Link: https://patch.msgid.link/20260822114110.1069541-1-edward.blair@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Intel Hades Canyon systems with an ALC700 codec, analog audio can
become unusable after rebooting from Windows into Linux.
The affected system uses codec subsystem ID 8086:2073. In the broken
state, Realtek coefficient 0x1b has value 0x4a4b. Setting bit 0x0400
changes it to 0x4e4b and immediately restores normal analog playback.
The BIOS also sets this bit after disabling and re-enabling onboard
audio, while Windows may leave it cleared. Linux currently does not
restore it during codec initialization.
Add a machine-specific fixup for Intel Hades Canyon which sets only
bit 0x0400 of coefficient 0x1b during HDA_FIXUP_ACT_INIT.
The fix has been verified across Windows -> Linux reboots on an Intel
NUC8i7HNB with an ALC700 codec.
Signed-off-by: Csaba Budai <ilyr73@gmail.com>
Link: https://patch.msgid.link/20260821102514.11194-1-ilyr73@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA both select
SND_SOC_MPC5200_AC97 without ensuring its dependency on PPC_BESTCOMM is
met. This causes unmet dependencies such as:
WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97
Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_BESTCOMM [=n]
Selected by [m]:
- SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y]
In v1, Rosen pointed out that the import of "mpc5200_dma.h" is actually
unnecessary, and Arnd suggested that the 'select' of SND_SOC_MPC5200_AC97
be changed to 'depends on'.
This resolves all 3 unmet dependencies.
These unmet dependency bugs were detected by kconfirm, a static analysis tool
for Kconfig.
Fixes: a9262c4fd4 ("ASoC: Support for AC97 on Phytec pmc030 base board.")
Fixes: 6ffee43ecf ("ASoC: Fabric bindings for STAC9766 on the Efika")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260821175410.179631-1-julianbraha@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
* At boot time, when the registers are accessed by asoc
layer while trying to enable a DAPM path, while the device
is still being attached, -EBUSY error will be thown by
regmap_read and regmap_udpate_bits. Because the regmap will
be in cache only mode. Add default values for these registers
so that, the cached values are returned instead of error.
* Also remove writing default values once again for first
attach.
Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20260820115114.1203-3-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename gain and volume macros to match the hardware intent. Currently,
both TAC_SDCA_CHANNEL_GAIN and TAC_SDCA_CHANNEL_VOLUME are defined as 0x02.
Keep only TAC_SDCA_CHANNEL_VOLUME and reposition TAC_SDCA_CHANNEL_GAIN to
0x0B. Remove the now-redundant TAC_SDCA_MASTER_GAIN alias (also 0x0B),
replacing its single use with TAC_SDCA_CHANNEL_GAIN.
Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20260820115114.1203-2-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
* With component_name set in the codec_info_list DAI entries,
"amixer -D hw:<card> info" includes the 'spk' identifier for
each tac5xx2 speaker component. This allows userspace to
identify the speaker codec at runtime and enables UCM
card matching for the tac5xx2 family.
* Set component_name for the speaker, mic, and UAJ DAI
entries for all tac5xx2 family variants.
Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Link: https://patch.msgid.link/20260820115114.1203-1-niranjan.hy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Jon Hunter <jonathanh@nvidia.com> says:
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra I2S and MIXER drivers
and after this commit was added, this underlying issue now causes audio
tests that exercise the I2S and MIXER drivers to fail. This series fixes
the issue in the I2S and MIXER drivers and also fixes warning observed
with the ADMAIF and MBDRC drivers that have unsorted reg_defaults.
Link: https://patch.msgid.link/20260821153734.158426-1-jonathanh@nvidia.com
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue with the Tegra MBDRC driver and
now the following warning is observed:
tegra210-ope 2908000.processing-engine: Driver needs fixing: Unsorted
reg_defaults, sorting the copy
This warning occurs because register defaults in the structure
tegra210_mbdrc_reg_defaults are not specified in ascending order which
is required by regmap. Fix this by sorting the register defaults
according to their address. Note that in order to do this it is
necessary to replace the macro MBDRC_FILTER_REG_DEFAULTS with a per
register macro MBDRC_FILTER_PARAM_REG_DEFAULTS.
Fixes: 7358a803c7 ("ASoC: tegra: Add Tegra210 based OPE driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-5-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra ADMAIF driver and now
the following warning is observed:
tegra210-admaif 290f000.admaif: Driver needs fixing: Unsorted
reg_defaults, sorting the copy
This warning occurs because register defaults in the structures
tegra186_admaif_reg_defaults and tegra264_admaif_reg_defaults are not
specified in ascending order which is required by regmap. Fix this by
sorting the register defaults according to their address. Note that in
order to do this it is necessary to split the macro ADMAIF_REG_DEFAULTS
into separate RX and TX macros to the RX and TX registers.
Fixes: f74028e159 ("ASoC: tegra: Add Tegra210 based ADMAIF driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-4-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra MIXER driver where
the register default for the TEGRA210_MIXER_ENABLE is specified as 1,
but the hardware default is actually 0. After this commit was added the
MIXER driver is no longer working and so fix this by correcting the
default value for this register and explicitly configuring the
MIXER_ENABLE register when runtime resuming the MIXER device.
Fixes: 05bb3d5ec6 ("ASoC: tegra: Add Tegra210 based Mixer driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-3-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 4b05ccb17f ("regcache: Sort the local copy of an unsorted
reg_defaults array") exposed an issue in the Tegra I2S driver where the
register default for the TEGRA210_I2S_ENABLE is specified as 1, but the
hardware default is actually 0. After this commit was added the I2S
driver is no longer working and so fix this by correcting the default
value for this register and explicitly configuring the I2S_ENABLE
register when runtime resuming the I2S device.
The I2S_ENABLE register offset is different on Tegra264 devices than
other Tegra devices and so add a 'enable_reg' variable to the SoC data
structure to specify the offset for different SoC devices.
Fixes: c0bfa98349 ("ASoC: tegra: Add Tegra210 based I2S driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260821153734.158426-2-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Reorder the HDA_CODEC_QUIRK entries for 0x17aa:0x38a7 and 0x17aa:0x38a8
so that the AMD variant (TAS2781) is matched before the Intel variant's
PCI SSID (0x386f) which uses a different amplifier. This ensures the
correct fixup (ALC287_FIXUP_TAS2781_I2C) is applied to the AMD model,
restoring internal speaker functionality.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820130644.76093-2-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Lenovo Yoga Pro 9 16IAH10 (PCI SSID 17aa:3846, codec SSID 17aa:3920)
uses a TAS2781 smart amplifier driven via the ALC287 codec. On this
machine the bass speaker pin (NID 0x17) is by default routed to DAC 0x03,
which has no volume amplifier capability, resulting in the right-side
woofer being barely audible while only the tweeter plays. The Windows
driver configures NID 0x17 to DAC 0x02, which is shared with the main
speaker and carries proper amp control.
Currently this machine has no PCI SSID quirk, so it falls through to the
codec SSID fallback and matches the existing 0x17aa:0x3920 entry intended
for the Yoga S990-16, applying only the TAS2781 I2C init without the DAC
routing fix.
Add a dedicated quirk for PCI SSID 17aa:3846 that forces NID 0x17 to DAC
0x02 via alc285_fixup_speaker2_to_dac1() and chains to
ALC287_FIXUP_TXNW2781_I2C so the TAS2781 amplifier initialization is
preserved.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820130644.76093-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_mtpav_output_timer() rearms chip->timer while holding
chip->spinlock and accesses the card-private mtpav state.
snd_mtpav_free() currently takes the same lock and calls
timer_delete() when the timer is active. This only removes a
pending timer; it does not wait for a callback that is already
running and does not prevent the callback from rearming the timer.
A callback running on another CPU can therefore continue after
snd_mtpav_free() releases the lock and access the card-private
state while the card is being torn down. It can also rearm the
timer after timer_delete() has returned.
Call timer_shutdown_sync() without holding chip->spinlock. This
waits for any running callback to finish and prevents further
rearming before the card-private mtpav state is released.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260820112749.9195-1-runyu.xiao@seu.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both the CTIA and OMTP branches of cx_process_headset_plugin() write the
same value to the headset-mic pin, differing only in the debug message.
Merge the two branches into a single one, leaving the codec write
unchanged.
No functional change.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260820073744.521680-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds a quirk for the HP Laptop 15-fd0039nt (SSID 103c:8bb6)
to fix the micmute LED functionality.
The micmute LED is controlled via GPIO 0 with active-low polarity.
Tested-by: Habil Eren Türker <habilerenturker@hotmail.com>
Signed-off-by: Habil Eren Türker <habilerenturker@hotmail.com>
Link: https://patch.msgid.link/20260819170919.3172-1-habilerenturker@hotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_ice1712_probe() performs multiple initialization steps after
snd_card_new(), but directly returns on failures from later steps
without releasing the ALSA card, causing resource leaks when
probing fails.
Use snd_devm_card_new() together with scope-based cleanup
via __free(snd_card_unref), and clear the card pointer after
successful registration to keep it alive.
Fixes: ca642da4b3 ("ALSA: ice1712: Allocate resources with device-managed APIs")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260820014117.14044-1-vulab@iscas.ac.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Andrey Golovko <andrey.golovko@gmail.com> says:
v1 was a single patch that powered the SDCA Function up in the port
PRE_PREP callback:
https://lore.kernel.org/all/20260813001500.9218-1-andrey.golovko@gmail.com/
Mark asked whether that does the right thing when userspace restarts the
stream with SNDRV_PCM_IOCTL_RESUME instead of preparing it, and pointed
out that a stream can also be suspended while prepared; Vijendar agreed.
The answer to the first question is no, and it is reproducible on this
machine, so v2 adds a patch to fix that path. The second case turns out
to be a wider gap that neither patch closes; it is described at the end.
Measured on an ASUS ProArt PX13 HN7306EAC (AMD ACP7.0, two TAS2783 on
SDW1). A test program plays a 440/660 Hz tone straight to the hw
device, the machine goes through an s2idle cycle, and on -ESTRPIPE the
program calls snd_pcm_resume() only - never snd_pcm_prepare(). The tone
is measured through the internal microphone against the noise floor of
the same run, and the peripheral registers are read out of band.
With v1 alone (broonie/sound for-next + v1):
before suspend after snd_pcm_resume()
DP1 PrepareCtrl 0x1 / 0x2 0x0 / 0x0
PDE23 req / act 0x0 / 0x0 0x3 / 0x3
tone 440 / 660 Hz +65.5 / +75.2 dB -1.7 / +1.8 dB
snd_pcm_resume() returned 0 and the PCM stayed RUNNING, so nothing in
the stack reported a failure - the speakers were simply silent. The
ports were never prepared again, so the PRE_PREP callback v1 relies on
was never reached.
With this series:
before suspend after snd_pcm_resume()
DP1 PrepareCtrl 0x1 / 0x2 0x1 / 0x2
PDE23 req / act 0x0 / 0x0 0x0 / 0x0
tone 440 / 660 Hz +73.7 / +88.3 dB +73.7 / +88.5 dB
ChannelEn also moved to the other bank across the cycle, as it should
when the ports are prepared afresh.
The ordinary path is unaffected. The same test recovering with
snd_pcm_prepare() instead of snd_pcm_resume(), on the same build, gives
+79.8 / +86.9 dB after the cycle with the ports prepared and the bank
switched back.
This also explains the negative test Robin Everaars reported for v1 on
the same board earlier today: playback opened without an error, both
amplifiers stayed attached, and the speakers were silent - which is what
this path looks like from userspace.
The case this series does not cover
===================================
A stream that is suspended while merely PREPARED never sees a trigger at
all: snd_pcm_do_suspend() returns early when the stream is not running,
and snd_pcm_do_resume() returns early unless the suspended state was
RUNNING or DRAINING. Userspace then calls snd_pcm_start(), the ports
are enabled, and the peripheral has lost its port state without anything
in the path noticing. Patch 1 cannot help there - the SoundWire stream
is still SDW_STREAM_PREPARED, so sdw_prepare_stream() is a no-op by
design - and neither can the codec, which has no way to tell the core
that its ports went away.
The bus does know: the peripheral goes UNATTACHED and comes back
uninitialized. Making that invalidate the prepared state of the streams
it takes part in looks like the right place to me, but it is a core
change and I have not written it. Say if it belongs in this series.
Link: https://patch.msgid.link/20260813194000.10412-1-andrey.golovko@gmail.com
A Data Port cannot complete channel preparation while the SDCA Function
is powered down: the peripheral raises the channel's bit in
DPn_PrepareStatus and never clears it.
tas_sdw_hw_params() takes care of that for a stream that is being set
up, and the retry loop there says so - "ensure power on so that port
prepare succeeds". Port preparation, however, also happens on a stream
that is merely re-prepared, without hw_params() running again. That is
what userspace does after a suspend in which the peripheral lost power:
snd_pcm_prepare() reaches .prepare and sdw_prepare_stream(), the port is
prepared afresh, but PDE23 is still at the PS3 reset default because
nothing wrote it since the device came back.
The result is silence with no error anywhere. The codec sets
simple_ch_prep_sm, so sdw_prep_deprep_slave_port() skips the
NOT_PREPARED poll, and a port that never prepares is indistinguishable
from a healthy one.
Power the Function up in the PRE_PREP callback, immediately before the
PrepareCtrl write it already performs, so that preparation has what it
needs on every path that prepares a port.
Measured on an ASUS ProArt PX13 (AMD ACP7.0, two TAS2783): after s2idle
with ~100 s of S0i3 residency, DPn_PrepareStatus stays at the channel
mask and there is no audio; writing PDE23 PS0 and re-issuing the prepare
clears it within 1 ms and audio returns.
Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com>
Link: https://patch.msgid.link/20260813194000.10412-3-andrey.golovko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A peripheral loses its Data Port configuration when the controller is
power-gated during system suspend, so the ports have to be prepared
again before the stream can be enabled. That happens on its own when
userspace calls snd_pcm_prepare() after SNDRV_PCM_STATE_SUSPENDED, but
an application is also allowed to restart the stream with
SNDRV_PCM_IOCTL_RESUME on a card that advertises SNDRV_PCM_INFO_RESUME,
as the AMD ACP platforms do. That path only reaches the trigger
callback, sdw_enable_stream() writes the channels of ports that were
never prepared, and playback silently produces nothing: the PCM keeps
running, no error is reported anywhere, and the speakers stay quiet
until the stream is torn down and set up again.
Prepare the stream on SNDRV_PCM_TRIGGER_RESUME, before enabling it.
The SoundWire core expects exactly this: sdw_prepare_stream() accepts a
disabled stream and then reapplies the bus parameters without
recomputing them, which it documents as the resume case.
Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com>
Link: https://patch.msgid.link/20260813194000.10412-2-andrey.golovko@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Creative Sound Blaster Play! 3 (041e:324d) exposes a Feature Unit
volume control with a range of -44.00 dB .. 0.00 dB over raw values
0..88, but raw value 0 is in fact a hard mute rather than -44.00 dB.
Tested on hardware.
Signed-off-by: Chad Talbott <chad.talbott@gmail.com>
Link: https://patch.msgid.link/20260819003237.452807-1-chad.talbott@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
pcxhr_probe() requests pcxhr_threaded_irq() before initializing
mgr->lock, even though the threaded handler takes that mutex.
Initialize the manager locks before request_threaded_irq() so an
early interrupt cannot run against uninitialized mutex state during
probe.
Fixes: 9bef72bdb2 ("ALSA: pcxhr: Use nonatomic PCM ops")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260818144717.2269918-1-runyu.xiao@seu.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rename `tegra_machine_event` to `loongson_asoc_machine_event` and
`loongson_aosc_dapm_widgets` to `loongson_asoc_dapm_widgets` to
accurately reflect the hardware platform. Update all references
accordingly.
No functional change is introduced.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
Reviewed-by: Keguang Zhang <keguang.zhang@gmail.com>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://patch.msgid.link/20260818092052.3596347-1-zhoubinbin@loongson.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
