The stream descriptor status register reports FIFO and descriptor
errors, but these are currently cleared silently along with the rest
of the interrupt status. Log them, rate-limited, so DMA problems are
visible instead of only manifesting as audible glitches.
Observed on some AMD GPU HDMI audio controllers under specific low power
circumstances.
Signed-off-by: Arun Raghavan <arunr@valvesoftware.com>
Cc: Arun Raghavan <arun@arunraghavan.net>
Link: https://patch.msgid.link/20260803-master-v1-1-9bcedb736978@valvesoftware.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that ALC269_FIXUP_LIMIT_INT_MIC_BOOST is no longer chained to
ALC269_FIXUP_THINKPAD_ACPI, ALC269_FIXUP_STARLABS_LIMIT_INT_MIC_BOOST and
ALC269_FIXUP_LIMIT_INT_MIC_BOOST are both identical. Remove the former
and replace it with the latter to avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-6-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that ALC269_FIXUP_LIMIT_INT_MIC_BOOST is no longer chained to
ALC269_FIXUP_THINKPAD_ACPI, ALC233_FIXUP_INTEL_NUC8_BOOST and
ALC269_FIXUP_LIMIT_INT_MIC_BOOST are both identical. Remove the former
and replace it with the latter to avoid redundancy.
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260803091102.107570-5-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The UAC mixer of the Logitech PRO X 2 LIGHTSPEED has broken mixer
GET_CUR behavior but otherwise works fine.
Add a quirk table entry matching VID/PID=0x046d/0x0af7 and apply the
MIXER_GET_CUR_BROKEN quirk flag to make the mixer usable again.
Quirky device sample (after applying the quirk flag):
usb 3-2.1: New USB device found, idVendor=046d, idProduct=0af7, bcdDevice= 1.00
usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2.1: Product: PRO X 2 LIGHTSPEED
usb 3-2.1: Manufacturer: Logitech
usb 3-2.1: SerialNumber: 0000000000000000
usb 3-2.1: 2:0: broken mixer GET_CUR (-18944/0/256 => -2662)
usb 3-2.1: 6:0: broken mixer GET_CUR (-18944/0/256 => 0)
Fixes: 86aa1ea1f1 ("ALSA: usb-audio: Do not expose sticky mixers")
Suggested-by: Brian van den Berg <faxuser@proton.me>
Reported-by: Brian van den Berg <faxuser@proton.me>
Link: https://lore.kernel.org/all/370007e6-b73b-4bfc-8410-a860781c7ad7@proton.me/
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260731-uac-lg-pro-x-2-ls-v1-1-268eaefe66ab@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The firmware of the Minisforum AI X1 Pro leaves the headphone jack detector
reset bit asserted on its ALC245 codec. As a result, pin sense on NID 0x21
always reports the jack as absent.
Clear only the Reset HP JD bit during codec initialization. Preserve the
remaining coefficient bits. This makes pin sense and the generic HDA
auto-mute logic work normally. Apply the fixup at INIT to also reapply the
setting after codec reinitialization and resume.
Tested on a Minisforum AI X1 Pro with codec 0x10ec0245 and subsystem
0x1f4cb020 using Ubuntu 26.04 kernel 7.0.0-28-generic.
Signed-off-by: Jeremie Pardou <jrmi@jeremiez.net>
Link: https://patch.msgid.link/20260802194832.49393-1-jrmi@jeremiez.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The LG gram 16 (16Z90TR, SSID 1854:0554) drives its internal speakers
through Samsung-style smart amplifiers on an ALC298. Nothing initialises
them, so the internal speakers are silent after a cold boot, while
headphones, HDMI and the microphones work.
A warm reset leaves the amps initialised, which masks the problem:
rebooting gives working speakers, a cold boot does not, with a
bit-identical kernel log in both cases. Dumping the codec's processing
coefficients in the two states shows the difference confined to COEF
0x22/0x23/0x25/0x26. COEF 0x22, the amp select register written by
alc298_samsung_v2_init_amps(), reads 0x39 when the speakers work and
0x00 after a cold boot. 0x39 is the second entry of
alc298_samsung_v2_amp_desc_tbl[], so two amps are in use.
Verified with hda_model=alc298-samsung-amp-v2-2-amps, which selects the
same fixup: the internal speakers work from a cold boot and COEF 0x22
reads 0x39.
Signed-off-by: Aaron Fan <aaronfan404@gmail.com>
Link: https://patch.msgid.link/20260802055818.7389-1-aaronfan404@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS VivoBook M515DA/X515DAP (subsystem ID 1043:1e3e)
requires the ALC256_FIXUP_ASUS_MIC_NO_PRESENCE fixup to
enable the internal microphone.
Without this quirk, the internal microphone captures only
silence under Linux, while it works correctly under Windows.
The fix has been verified on real hardware.
Tested on an ASUS VivoBook M515DA/X515DAP running Linux Mint
22.3 with Ubuntu HWE kernel 7.0.0-28.
Signed-off-by: Mauricio Orozco <maudob@live.com>
Link: https://patch.msgid.link/20260730033506.8958-1-mauoro3@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
tas2781_read_acpi() gets a reference to the matching ACPI device and then
looks up its first physical device node. After taking a reference to the
physical device, it immediately drops the ACPI device reference.
However, every later failure jumps to an error path that drops the ACPI
device reference a second time. This unbalances the reference count and
may prematurely release the ACPI device.
In addition, acpi_get_first_physical_node() may return NULL. Without a
check, the driver passes the NULL physical device to the property helper
calls and may dereference it.
Return -ENODEV when no physical device is associated with the ACPI node,
and remove the duplicate acpi_dev_put() from the common error path.
Fixes: bb5f86ea50 ("ALSA: hda/tas2781: Add tas2781 hda SPI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/97EA8F29DA0D9AF7+20260731033554.949564-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In loopback_hrtimer_stop(), calling hrtimer_cancel() while holding
cable->lock triggers an AB-BA spinlock deadlock if the hrtimer softirq
is executing concurrently on another CPU:
1) CPU A runs loopback_trigger(STOP), acquires spin_lock(&cable->lock),
and calls hrtimer_cancel(). Since hrtimer_cancel() is synchronous,
it spins waiting for the executing callback to complete before
returning.
2) CPU B executes loopback_hrtimer_function(), which immediately tries
to acquire spin_lock(&cable->lock).
This mutual dependency leads to a CPU hard lockup and NMI watchdog
panic when multiple streams start and stop concurrently with small
period sizes.
Replace hrtimer_cancel() in loopback_hrtimer_stop() with the non-blocking
hrtimer_try_to_cancel(), matching the behavior of jiffies timers
(timer_delete vs timer_delete_sync). If try_to_cancel returns -1
because the handler is running, CPU A releases cable->lock cleanly.
When the running handler subsequently acquires cable->lock, it observes
that the stream is no longer in running state (cleared by trigger STOP)
and terminates without re-arming the timer. Synchronous hrtimer_cancel()
remains preserved in loopback_hrtimer_stop_sync() where cable->lock is
not held.
Fixes: bf08a5f698 ("ALSA: aloop: Add 'hrtimer' option to timer_source")
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Link: https://patch.msgid.link/20260731074255.1513402-1-yuhsuan@chromium.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Simplify the code to manage the firmware loading with auto-cleanup
with __free(firmware). A NULL clear is added at
cs35l41_request_firmware_file() for avoiding the double-free.
Note that the driver still keeps a few manual firmware releases
because it retries with different firmware files when one of firmware
pairs fails.
Only the code refactoring, no functional changes.
Cc: patches@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260729083735.120219-6-tiwai@suse.de
Clean up the code for managing the firmware loading in the 6fire
driver with __free(firmware) and __free(kfree), so that the loaded
firmware and the name string are cleaned up automatically.
Only the code refactoring, no functional changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260729083735.120219-2-tiwai@suse.de
get_jack_mode_name() tries to identify the (potential) index number of
the control element to be created, but this index number isn't
actually used, since the index is set automatically at instantiating
the controls.
Drop the unneeded index retrieval and calculation as a cleanup.
Along with the change, find_kctl_name() is no longer used, hence drop
this function as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260730084513.327992-2-tiwai@suse.de
On the ThinkBook 14 G8+ IPH (SSID 17aa:393e, ALC287) the F1 speaker mute
LED never lights up, while the F4 mic mute LED works.
Both LEDs are platform LEDs registered by lenovo-wmi-hotkey-utilities and
default to the audio-mute / audio-micmute triggers, so the speaker LED only
follows a control carrying SNDRV_CTL_ELEM_ACCESS_SPK_LED. No control on
this machine has that flag set, so snd_ctl_led never attaches anything and
/sys/class/sound/ctl-led/speaker/card0/list stays empty. The mic LED is
unaffected because MIC_LED is set from the SOF topology on the DMIC
control, which does not go through the codec fixups at all.
The pin configuration of this machine matches the ThinkPad pin quirk that
selects ALC285_FIXUP_THINKPAD_HEADSET_JACK - pin_config_match() masks out
the sequence/association nibbles, so 0x14=0x90170120 still matches the
0x90170110 in the table. That fixup chains into ALC269_FIXUP_THINKPAD_ACPI,
but hda_fixup_thinkpad_acpi() returns early because is_thinkpad() is false:
a ThinkBook exposes neither LEN0068/LEN0268 nor IBM0068. Therefore
snd_hda_gen_add_mute_led_cdev() is never called and spec->vmaster_mute_led
stays 0.
The vendor fallback SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo XPAD",
ALC269_FIXUP_LENOVO_XPAD_ACPI) would have handled this correctly - the
machine does expose LHK2019 and VPC2004, so is_ideapad() is true - but it
never runs: the pin quirk has already set codec->fixup_id, and
snd_hda_pick_fixup() returns immediately in that case.
Add an SSID quirk selecting a fixup that keeps everything the machine
currently gets (headset jack handling plus the X1 Gen7 DAC routing) and
additionally runs the ideapad ACPI setup. It chains into
ALC287_FIXUP_LENOVO_YOGA_PRO7, which already combines
alc285_fixup_thinkpad_x1_gen7 with ALC269_FIXUP_LENOVO_XPAD_ACPI, so the
resulting chain differs from the current one only by the added ideapad step
and cannot regress the analog output or the headset jack.
Tested on 7.1.5 on the affected machine: the speaker LED group is now
populated at probe time without any userspace help, and the F1 LED
follows the mute state. Compared against a boot with the previous fixup
selection, the mixer control list (names and numids) and the registered
jack input devices are identical.
Note that the underlying mismatch is not specific to this SSID. Any Lenovo
non-ThinkPad whose pins collide with a ThinkPad pin quirk loses its mute
LED the same way. Letting hda_fixup_thinkpad_acpi() fall back to the
ideapad check would cover the whole class at once, but that touches a
helper shared with every ThinkPad, so this patch only fixes the machine
that was actually tested.
Signed-off-by: Padhia Luo <lcj20010426@gmail.com>
Link: https://patch.msgid.link/20260730071453.19636-1-lcj20010426@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ASoC: Fixes for v7.2
This is a relatively large set of updates, the biggest batch of things
is Charles' fixes for the SDCA code which have been through a number of
iterations on the list and deal with a bunch of issues that have been
seen as we get more real world usage of SDCA. We also have the usual
device specific fix and quirk traffic that we tend to see, there's a
small pile of fixes for the tas2562 driver since I saw some bugs while
reviewing fixes sent by Haidar Lee but it's nothing too remarkable.
alc_read_coef_idx() and alc_read_coefex_idx() can return -1 on error
via snd_hda_codec_read(). Several codec initialization and shutdown
functions save these return values and later write them back to
hardware registers without checking for errors, potentially corrupting
COEF register state on a read failure.
Add error checks in:
- alc282_init() and alc282_shutup(): check coef78 before write-back
- alc285_hp_init(): check coef38/coef0d/coef36 before update, check
val before write-back, and break polling loop on error
- alc294_hp_init(): break polling loop on read error
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260730015302.253008-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Enable audio output through the AW88399 woofer amplifiers on Lenovo
Legion laptops by adding the necessary Realtek ALC287 fixups and
AW88399 per-model quirks.
Realtek fixups (alc269.c):
* ALC287_FIXUP_AW88399_I2C_2: registers the AW88399 as a two-instance
I2C companion codec using comp_generic_fixup, matching ACPI HID
"AWDZ8399".
* ALC287_FIXUP_LENOVO_LEGION_AW88399: forces DAC 0x02 for the bass
speaker pin 0x17, as the default DAC 0x06 lacks volume controls.
Also applies internal microphone boost calibration via
alc269_fixup_limit_int_mic_boost and disables unused pin 0x1d
to match the Windows driver's pin configuration.
Chained to ALC287_FIXUP_AW88399_I2C_2.
Per-model quirks (aw88399_hda.c):
* Channel swap: the I2C wiring on these Legion models is reversed
(0x34 is physically the right speaker, 0x35 is the left). The
quirk swaps the channel assignment to correct L/R audio.
* BSTS status bypass: the AW88399's boost-finished status bit (BSTS,
SYSST register bit 9) does not reliably assert on this hardware.
Register dumps during normal playback show both amplifiers
reporting BSTS=0 on both channels despite clean audio output.
The quirk sets the bsts_unreliable flag, introduced in
commit b4530a3e48 ("ASoC: aw88399: add per-instance BSTS status bypass flag"),
so the startup status check skips the BSTS requirement
on these devices.
The R9000P ADR10 entries use HDA_CODEC_QUIRK and are placed before
the existing SND_PCI_QUIRK for 17aa:38bb (Yoga S780-14.5 Air) to
ensure the codec SSID match takes priority over the shared PCI SSID,
following the pattern established by e.g.
commit 0f3a822ae2 ("ALSA: hda/realtek: Fix quirk matching for Legion Pro 7"),
commit dd074f04e0 ("ALSA: hda/realtek: Fix Legion 7 16ITHG6 speaker amp binding").
All other entries also use HDA_CODEC_QUIRK for consistency.
Supported models (Lenovo vendor ID 0x17aa):
* 0x3906: Legion Pro 7i 16IAX10H / Y9000P IAX10 (Intel)
* 0x3907: Legion Pro 7i 16IAX10H / Y9000P IAX10 (Intel)
* 0x3927: Legion R9000P ADR10 (AMD)
* 0x3928: Legion R9000P ADR10 (AMD)
* 0x3938: Legion Pro 7 16AFR10H (AMD)
* 0x3939: Legion Pro 7 16AFR10H (AMD)
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Co-developed-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/DS7PR19MB7724ACD7C8D1BE71451E1AEEFCCA2@DS7PR19MB7724.namprd19.prod.outlook.com
Add an HDA side codec driver for the AWINIC AW88399 smart amplifier,
enabling its use as a companion amplifier on HDA systems where the
chip is connected via I2C to the host and driven alongside a primary
HDA codec (such as Realtek ALC287).
The driver is structured after the existing side codec drivers:
* aw88399_hda_i2c.c: I2C bus driver matching ACPI HID "AWDZ8399" and
serial-multi-instantiate device name "aw88399-hda".
Creates the regmap and passes it to the shared probe function,
following the CS35L41/CS35L56/TAS2781 pattern.
* aw88399_hda.c: Core driver implementing HDA component binding,
playback hooks (using the shared library's start/stop functions),
ACPI subsystem ID retrieval, and runtime/system power management.
Includes per-model quirk infrastructure using ACPI subsystem ID
matching; the quirk table is empty in this patch and populated in
the next patch along with the corresponding Realtek fixups that
activate the driver.
The driver includes <sound/aw88399.h> for shared definitions and
depends on SND_SOC_AW88399_LIB for chip initialization, firmware
loading, and playback control, avoiding any dependency on the full
ASoC codec module.
Tested-by: Nadim Kobeissi <nadim@symbolic.software>
Tested-by: Xia Yun'an <imitoy@imitoy.top>
Tested-by: Munzir Taha <munzirtaha@gmail.com>
Co-developed-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Yakov Till <yakov.till@gmail.com>
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/DS7PR19MB77247D67E739956AA4611ACEFCCA2@DS7PR19MB7724.namprd19.prod.outlook.com
The RT5640 GPIO1/IRQ pin can be configured either as GPIO1 or as the
codec interrupt output.
Some boards, such as the Firefly-RK3399, do not connect the codec
interrupt output. This causes the following binding validation warning:
'interrupts' is a required property
Make the interrupts property optional to support such hardware
configurations.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260727185814.2599488-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_hda_add_new_path() returns NULL when no path exists between the
given NIDs, but olpc_xo_update_mic_pins() passes dc_mode_path
straight to snd_hda_activate_path() which dereferences it without
checking. Add the missing NULL guards, same as the local path
variable already has in the same function.
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260729070935.548050-2-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
