lwn.git/sound/hda/controllers/intel.c, branch master

ALSA: hda/intel: Make sure to cancel irq-pending work at closing PCM stream

2026-05-20T05:50:45+00:00

The pending irq work might be still floating while the assigned stream has been already closed, which may lead to UAF, especially when another async work for fasync is involved. For addressing this, extend the hda_controller_ops for allowing the extra cleanup procedure that is specific to the controller driver, and make sure to cancel and sync the pending irq work at each PCM close before releasing the resources. Reported-by: Jake Lamberson Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260519121157.28477-2-tiwai@suse.de

ALSA: hda: Move irq pending work into hda-intel stream

2026-05-20T05:50:45+00:00

Currently, the delayed IRQ handling for PCM streams is managed in a single work embedded in hda_intel, but this is basically a per-stream thing. Due to the single work, we can't cancel the work properly at closing each stream, for example. For making the IRQ pending work to be stream-based, this patch changes the following: - An extended version of azx_dev (i.e. the hd-audio stream object) is defined for snd-hda-intel - The irq_pending flag and irq_pending_work are moved to hda_intel_stream, so that they can be hda-intel stream specific - The stream creation and assignment are refactored so that snd-hda-intel can handle individually; the snd-hda-intel specific workaround for stream tags is also moved to snd-hda-intel itself instead of the common code - The irq pending work is canceled properly at free / shutdown While we're at it, changed the bit field flag to bool, as the bit field doesn't help much in our case. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260519121157.28477-1-tiwai@suse.de

ALSA: hda/intel: Move firmware loading into the probe work

2026-04-16T08:33:06+00:00

The hda-intel driver uses request_firmware_nowait() for loading its patch, and tries to continue the probe directly from the fw loader callback. This works in principle, but it has a few drawbacks: - The driver may be released before the firmware callback completes - Having two ways of async probe makes the code flow unnecessarily complex The former issue is more severe, as it may potentially lead to a UAF, and there is no explicit way to cancel the pending firmware worker for now. This patch changes the firmware loading to be performed rather in the common probe work without *_nowait(). Then the pending work can be easily canceled, and the code becomes more straightforward. A nice bonus is that, by moving into the probe work, the firmware doesn't need any longer to be cached, hence we can get rid of struct azx.fw field, and release the firmware immediately after parsing it, too. Fixes: 5cb543dba986 ("ALSA: hda - Deferred probing with request_firmware_nowait()") Link: https://patch.msgid.link/20260415135526.1813126-1-tiwai@suse.de Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2026-04-09T06:32:17+00:00

Pull 7.0-devel branch for further development of HD-audio codec quirks. Signed-off-by: Takashi Iwai

ALSA: hda/intel: enforce stricter period-size alignment for Intel NVL

2026-04-08T12:09:33+00:00

Intel ACE4 based products set more strict constraints on HDA BDLE start address and length alignment. Modify capability flags to drop AZX_DCAPS_NO_ALIGN_BUFSIZE for Intel Nova Lake platforms. Fixes: 7f428282fde3 ("ALSA: hda: controllers: intel: add support for Nova Lake") Signed-off-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Liam Girdwood Cc: Link: https://patch.msgid.link/20260408084514.24325-2-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2026-04-01T12:43:00+00:00

Pull 7.0 devel branch for further cleanups of ctxfi driver & co. Signed-off-by: Takashi Iwai

ALSA: hda: intel: Drop obsolete probe-work unlock workaround

2026-03-29T09:07:04+00:00

Commit ab949d519601 ("ALSA: hda - Fix deadlock of controller device lock at unbinding") added a temporary device_unlock()/device_lock() pair around probe-work cancellation to avoid a deadlock between controller unbind and codec probe. That deadlock depended on the driver core taking both a device lock and its parent lock during bind and unbind. Since commit 8c97a46af04b ("driver core: hold dev's parent lock when needed") and follow-up fixes, the parent lock is only taken when bus->need_parent_lock is set. The HDA bus does not set that flag, so codec binding no longer locks the controller device as the codec's parent. Keep cancel_delayed_work_sync(), since the async probe/remove race still needs to be serialized, but drop the stale unlock/relock workaround and its outdated FIXME comment. Keeping it around only opens an unnecessary unlocked window inside azx_remove(). Signed-off-by: Cássio Gabriel Link: https://patch.msgid.link/20260328-hda-intel-drop-obsolete-probe-workaround-v1-1-bc43aeafc98b@gmail.com Signed-off-by: Takashi Iwai

ALSA: hda/intel: Add MSI X870E Tomahawk to denylist by DMI ID

2026-03-28T09:32:53+00:00

This motherboard uses USB audio instead, causing this driver to complain about "no codecs found!". Add it to the denylist to silence the warning. The first attempt only matched on the PCI device, but this caused issues for some laptops, so DMI match against the board as well. Signed-off-by: Stuart Hayhurst Link: https://patch.msgid.link/20260327155737.21818-2-stuart.a.hayhurst@gmail.com Signed-off-by: Takashi Iwai

Revert "ALSA: hda/intel: Add MSI X870E Tomahawk to denylist"

2026-03-27T09:54:04+00:00

commit 30b3211aa2416 ("ALSA: hda/intel: Add MSI X870E Tomahawk to denylist") was added to silence a warning, but this effectively reintroduced commit df42ee7e22f03 ("ALSA: hda: Add ASRock X670E Taichi to denylist") which was already reported to cause problems and reverted in commit ee8f1613596ad ("Revert "ALSA: hda: Add ASRock X670E Taichi to denylist"") Revert it yet again. Cc: stable@vger.kernel.org Reported-by: Juhyun Song Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221274 Cc: Stuart Hayhurst Signed-off-by: Mario Limonciello Link: https://patch.msgid.link/20260326190542.524515-1-mario.limonciello@amd.com Signed-off-by: Takashi Iwai

ALSA: hda/intel: increase default bdl_pos_adj for Nvidia controllers

2026-02-25T14:56:57+00:00

The default bdl_pos_adj of 32 for Nvidia HDA controllers is insufficient on GA102 (and likely other recent Nvidia GPUs) after S3 suspend/resume. The controller's DMA timing degrades after resume, causing premature IRQ detection in azx_position_ok() which results in silent HDMI/DP audio output despite userspace reporting a valid playback state and correct ELD data. Increase bdl_pos_adj to 64 for AZX_DRIVER_NVIDIA, matching the value already used by Intel Apollo Lake for the same class of timing issue. Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221069 Suggested-by: Charalampos Mitrodimas Signed-off-by: Panagiotis Foliadis Link: https://patch.msgid.link/20260225-nvidia-audio-fix-v1-1-b1383c37ec49@posteo.net Signed-off-by: Takashi Iwai