March 2022 - Alsa-devel - mailman.alsa-project.org

Focusrite Scarlett 8i6 silent input stream
by ZTube 30 Mar '22

30 Mar '22

I'm trying to get my Focusrite Scarlett 8i6 to run with alsa, however while the sound output to the device works fine, the input does not and merely delivers a silent stream. Since I can't find any reason for the input stream to be completely silent I suspect this might be a driver bug. $ arecord -D hw:0,0 -f S32_LE -r 48000 -c 10 | aplay just results in complete silence I'd be happy to provide more logs/detail if needed. Any idea what might be going on? Thanks, ZTube [alsa-info.sh] https://paste.debian.net/1236037/

3 2

[syzbot] possible deadlock in __snd_pcm_lib_xfer
by syzbot 30 Mar '22

30 Mar '22

Hello, syzbot found the following issue on: HEAD commit: 8515d05bf6bc Add linux-next specific files for 20220328 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=15c0acc7700000 kernel config: https://syzkaller.appspot.com/x/.config?x=530c68bef4e2b8a8 dashboard link: https://syzkaller.appspot.com/bug?extid=6e5c88838328e99c7e1c compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14433ca5700000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=163bb77d700000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+6e5c88838328e99c7e1c(a)syzkaller.appspotmail.com ====================================================== WARNING: possible circular locking dependency detected 5.17.0-next-20220328-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor329/3588 is trying to acquire lock: ffff8880243c1d28 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0xa1/0x170 mm/memory.c:5300 but task is already holding lock: ffff88801afef230 (&runtime->buffer_mutex){+.+.}-{3:3}, at: wait_for_avail sound/core/pcm_lib.c:1913 [inline] ffff88801afef230 (&runtime->buffer_mutex){+.+.}-{3:3}, at: __snd_pcm_lib_xfer+0xbca/0x1e20 sound/core/pcm_lib.c:2263 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&runtime->buffer_mutex){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:600 [inline] __mutex_lock+0x12f/0x12f0 kernel/locking/mutex.c:733 snd_pcm_hw_params+0xc9/0x18a0 sound/core/pcm_native.c:705 snd_pcm_kernel_ioctl+0x164/0x310 sound/core/pcm_native.c:3410 snd_pcm_oss_change_params_locked+0x14e2/0x3a70 sound/core/oss/pcm_oss.c:976 snd_pcm_oss_change_params sound/core/oss/pcm_oss.c:1116 [inline] snd_pcm_oss_mmap+0x442/0x550 sound/core/oss/pcm_oss.c:2929 call_mmap include/linux/fs.h:2085 [inline] mmap_region+0xba5/0x14a0 mm/mmap.c:1791 do_mmap+0x863/0xfa0 mm/mmap.c:1582 vm_mmap_pgoff+0x1b7/0x290 mm/util.c:519 ksys_mmap_pgoff+0x40d/0x5a0 mm/mmap.c:1628 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&mm->mmap_lock#2){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3096 [inline] check_prevs_add kernel/locking/lockdep.c:3219 [inline] validate_chain kernel/locking/lockdep.c:3834 [inline] __lock_acquire+0x2ac6/0x56c0 kernel/locking/lockdep.c:5060 lock_acquire kernel/locking/lockdep.c:5672 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5637 __might_fault mm/memory.c:5301 [inline] __might_fault+0x104/0x170 mm/memory.c:5294 _copy_to_user+0x25/0x140 lib/usercopy.c:28 copy_to_user include/linux/uaccess.h:160 [inline] default_read_copy+0x10f/0x180 sound/core/pcm_lib.c:2013 __snd_pcm_lib_xfer+0x1517/0x1e20 sound/core/pcm_lib.c:2282 snd_pcm_oss_read3+0x1c4/0x400 sound/core/oss/pcm_oss.c:1292 snd_pcm_oss_read2+0x300/0x3f0 sound/core/oss/pcm_oss.c:1503 snd_pcm_oss_read1 sound/core/oss/pcm_oss.c:1550 [inline] snd_pcm_oss_read+0x620/0x7a0 sound/core/oss/pcm_oss.c:2788 vfs_read+0x1ef/0x5d0 fs/read_write.c:480 ksys_read+0x127/0x250 fs/read_write.c:620 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&runtime->buffer_mutex); lock(&mm->mmap_lock#2); lock(&runtime->buffer_mutex); lock(&mm->mmap_lock#2); *** DEADLOCK *** 1 lock held by syz-executor329/3588: #0: ffff88801afef230 (&runtime->buffer_mutex){+.+.}-{3:3}, at: wait_for_avail sound/core/pcm_lib.c:1913 [inline] #0: ffff88801afef230 (&runtime->buffer_mutex){+.+.}-{3:3}, at: __snd_pcm_lib_xfer+0xbca/0x1e20 sound/core/pcm_lib.c:2263 stack backtrace: CPU: 0 PID: 3588 Comm: syz-executor329 Not tainted 5.17.0-next-20220328-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 check_noncircular+0x25f/0x2e0 kernel/locking/lockdep.c:2176 check_prev_add kernel/locking/lockdep.c:3096 [inline] check_prevs_add kernel/locking/lockdep.c:3219 [inline] validate_chain kernel/locking/lockdep.c:3834 [inline] __lock_acquire+0x2ac6/0x56c0 kernel/locking/lockdep.c:5060 lock_acquire kernel/locking/lockdep.c:5672 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5637 __might_fault mm/memory.c:5301 [inline] __might_fault+0x104/0x170 mm/memory.c:5294 _copy_to_user+0x25/0x140 lib/usercopy.c:28 copy_to_user include/linux/uaccess.h:160 [inline] default_read_copy+0x10f/0x180 sound/core/pcm_lib.c:2013 __snd_pcm_lib_xfer+0x1517/0x1e20 sound/core/pcm_lib.c:2282 snd_pcm_oss_read3+0x1c4/0x400 sound/core/oss/pcm_oss.c:1292 snd_pcm_oss_read2+0x300/0x3f0 sound/core/oss/pcm_oss.c:1503 snd_pcm_oss_read1 sound/core/oss/pcm_oss.c:1550 [inline] snd_pcm_oss_read+0x620/0x7a0 sound/core/oss/pcm_oss.c:2788 vfs_read+0x1ef/0x5d0 fs/read_write.c:480 ksys_read+0x127/0x250 fs/read_write.c:620 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f72068ad0f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff51e1f1c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f72068ad0f9 RDX: 0000000000000ff2 RSI: 0000000020000780 RDI: 0000000000000004 RBP: 00007f72068710e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7206871170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

2 1

[PATCH] ALSA: hda: Avoid unsol event during RPM suspending
by Mohan Kumar 30 Mar '22

30 Mar '22

There is a corner case with unsol event handling during codec runtime suspending state. When the codec runtime suspend call initiated, the codec->in_pm atomic variable would be 0, currently the codec runtime suspend function calls snd_hdac_enter_pm() which will just increments the codec->in_pm atomic variable. Consider unsol event happened just after this step and before snd_hdac_leave_pm() in the codec runtime suspend function. The snd_hdac_power_up_pm() in the unsol event flow in hdmi_present_sense_via_verbs() function would just increment the codec->in_pm atomic variable without calling pm_runtime_get_sync function. As codec runtime suspend flow is already in progress and in parallel unsol event is also accessing the codec verbs, as soon as codec suspend flow completes and clocks are switched off before completing the unsol event handling as both functions doesn't wait for each other. This will result in below errors [ 589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching to polling mode: last cmd=0x505f2f57 [ 589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5, last cmd=0x505f2f57 [ 589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5, last cmd=0x505f2f57 To avoid this, the unsol event flow should not perform any codec verb related operations during RPM_SUSPENDING state. Signed-off-by: Mohan Kumar <mkumard(a)nvidia.com> --- sound/pci/hda/patch_hdmi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index c85ed7bc121e..3e086eebf88d 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1625,6 +1625,7 @@ static void hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin, struct hda_codec *codec = per_pin->codec; struct hdmi_spec *spec = codec->spec; struct hdmi_eld *eld = &spec->temp_eld; + struct device *dev = hda_codec_dev(codec); hda_nid_t pin_nid = per_pin->pin_nid; int dev_id = per_pin->dev_id; /* @@ -1638,8 +1639,13 @@ static void hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin, int present; int ret; +#ifdef CONFIG_PM + if (dev->power.runtime_status == RPM_SUSPENDING) + return; +#endif + ret = snd_hda_power_up_pm(codec); - if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec))) + if (ret < 0 && pm_runtime_suspended(dev)) goto out; present = snd_hda_jack_pin_sense(codec, pin_nid, dev_id); -- 2.17.1

2 1

[PATCH v2] ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020
by Kai-Heng Feng 30 Mar '22

30 Mar '22

Commit 5aec98913095 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") is to solve recording issue met on AL236, by matching codec variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256. This match can be too broad and Mi Notebook Pro 2020 is broken by the patch. Instead, use codec ID to be narrow down the scope, in order to make ALC256 unaffected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484 Fixes: 5aec98913095 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- v2: Fix wrong comparison, || -> && sound/pci/hda/patch_realtek.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4c33cb57963db..aace474a899de 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3617,8 +3617,8 @@ static void alc256_shutup(struct hda_codec *codec) /* If disable 3k pulldown control for alc257, the Mic detection will not work correctly * when booting with headset plugged. So skip setting it for the codec alc257 */ - if (spec->codec_variant != ALC269_TYPE_ALC257 && - spec->codec_variant != ALC269_TYPE_ALC256) + if (codec->core.vendor_id != 0x10ec0236 && + codec->core.vendor_id != 0x10ec0257) alc_update_coef_idx(codec, 0x46, 0, 3 << 12); if (!spec->no_shutup_pins) -- 2.34.1

2 1

[PATCH 0/2] rawmidi/meson: fix miscellaneous bugs
by GitHub pull_request - opened 30 Mar '22

30 Mar '22

alsa-project/alsa-gobject pull request #65 was opened from takaswie: This patchset fixes unintended two items below. * argument name against convention in this project * line break inner identifier in meson.build ``` Takashi Sakamoto (2): rawmidi: fix argument names with suffix '_id' meson: fix unintended line break for identifier src/rawmidi/query.c | 12 ++++++------ src/rawmidi/query.h | 2 +- src/seq/meson.build | 3 +-- 3 files changed, 8 insertions(+), 9 deletions(-) ``` Request URL : https://github.com/alsa-project/alsa-gobject/pull/65 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/65.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

Fix support for sof-essx8336
by GitHub pull_request - opened 30 Mar '22

30 Mar '22

alsa-project/alsa-ucm-conf pull request #144 was opened from mchehab: There are a couple of issues at the support for sof-essx8336, causing it to fail working. This PR fix them. Tested on Huawei Matebook D15. Before the fix, the device was appearing as "sysdefault:0" instead of "hw:0", and there were several other problems. After the fix: - the device is now identified as hw:0; - calling alsamixer without `-Dsysdefault:0` (or `-Dhw:0`) now shows a mixer (instead of showing nothing); - The HDMI volume controls now appear; - Using `alsaucm load` now works fine. There are still a couple of things to be fixed, but I suspect that at least some of them would require firmware (or driver?) changes: - the internal microphone is not working yet; - the headphone/headset doesn't work. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/144 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/144.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Nhlt plugin and simple plugin interface
by GitHub pull_request - edited 29 Mar '22

29 Mar '22

alsa-project/alsa-utils pull request #129 was edited from juimonen: Initial something... I need to figure out: - where to specify which plugins to load/run (nhlt now hard coded) - where to install the plugins - how to get the to-be-loaded plugin names and where - is the "hidden-visibility" gcc flag ok to hide other than .so entrypoint Request URL : https://github.com/alsa-project/alsa-utils/pull/129 Patch URL : https://github.com/alsa-project/alsa-utils/pull/129.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ASoC: SOF: topology: use new sound control LED layer
by Jaroslav Kysela 29 Mar '22

29 Mar '22

Use the new sound control LED layer instead the direct ledtrig_audio_set() call - see 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer"). Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Bard Liao <yung-chuan.liao(a)linux.intel.com> Cc: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/control.c | 33 --------------------------------- sound/soc/sof/topology.c | 10 ++++++++++ 2 files changed, 10 insertions(+), 33 deletions(-) diff --git a/sound/soc/sof/control.c b/sound/soc/sof/control.c index de1778c4002b..3b5718a3516d 100644 --- a/sound/soc/sof/control.c +++ b/sound/soc/sof/control.c @@ -15,36 +15,6 @@ #include "sof-priv.h" #include "sof-audio.h" -static void update_mute_led(struct snd_sof_control *scontrol, - struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) -{ - int temp = 0; - int mask; - int i; - - mask = 1U << snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); - - for (i = 0; i < scontrol->num_channels; i++) { - if (ucontrol->value.integer.value[i]) { - temp |= mask; - break; - } - } - - if (temp == scontrol->led_ctl.led_value) - return; - - scontrol->led_ctl.led_value = temp; - -#if IS_REACHABLE(CONFIG_LEDS_TRIGGER_AUDIO) - if (!scontrol->led_ctl.direction) - ledtrig_audio_set(LED_AUDIO_MUTE, temp ? LED_OFF : LED_ON); - else - ledtrig_audio_set(LED_AUDIO_MICMUTE, temp ? LED_OFF : LED_ON); -#endif -} - int snd_sof_volume_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -121,9 +91,6 @@ int snd_sof_switch_put(struct snd_kcontrol *kcontrol, struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(scomp); const struct sof_ipc_tplg_ops *tplg_ops = sdev->ipc->ops->tplg; - if (scontrol->led_ctl.use_led) - update_mute_led(scontrol, kcontrol, ucontrol); - if (tplg_ops->control->switch_put) return tplg_ops->control->switch_put(scontrol, ucontrol); diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 9b11e9795a7a..267a781494da 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -773,6 +773,7 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, struct snd_soc_tplg_mixer_control *mc = container_of(hdr, struct snd_soc_tplg_mixer_control, hdr); int tlv[TLV_ITEMS]; + unsigned int mask; int ret; /* validate topology data */ @@ -821,6 +822,15 @@ static int sof_control_load_volume(struct snd_soc_component *scomp, goto err; } + if (scontrol->led_ctl.use_led) { + mask = scontrol->led_ctl.direction ? SNDRV_CTL_ELEM_ACCESS_MIC_LED : + SNDRV_CTL_ELEM_ACCESS_SPK_LED; + scontrol->access &= ~SNDRV_CTL_ELEM_ACCESS_LED_MASK; + scontrol->access |= mask; + kc->access &= ~SNDRV_CTL_ELEM_ACCESS_LED_MASK; + kc->access |= mask; + } + dev_dbg(scomp->dev, "tplg: load kcontrol index %d chans %d\n", scontrol->comp_id, scontrol->num_channels); -- 2.34.1

2 2

[PATCH 0/6] ASRC support on Tegra186 and later
by Sameer Pujar 29 Mar '22

29 Mar '22

This series adds support for Asynchronous Sample Rate Converter (ASRC) module on Tegra186 and later generations of SoCs. ASRC is a client of AHUB. The driver and DT support is added to make it work with Tegra audio graph card. The module can be plugged into audio path using ALSA mixer controls. ASRC supports two modes of operation, where it gets the ratio info from SW and ratio detector module. Presently the support is added for SW mode. Sameer Pujar (6): ASoC: tegra: Add binding doc for ASRC module ASoC: tegra: Add Tegra186 based ASRC driver ASoC: tegra: AHUB routes for ASRC module arm64: defconfig: Build Tegra ASRC module arm64: tegra: Add ASRC device on Tegra186 and later arm64: tegra: Enable ASRC on various platforms .../bindings/sound/nvidia,tegra186-asrc.yaml | 81 ++ .../bindings/sound/nvidia,tegra210-ahub.yaml | 4 + arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 223 +++++ arch/arm64/boot/dts/nvidia/tegra186.dtsi | 7 + arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 223 +++++ .../arm64/boot/dts/nvidia/tegra194-p3509-0000.dtsi | 223 +++++ arch/arm64/boot/dts/nvidia/tegra194.dtsi | 8 + .../dts/nvidia/tegra234-p3737-0000+p3701-0000.dts | 223 +++++ arch/arm64/boot/dts/nvidia/tegra234.dtsi | 8 + arch/arm64/configs/defconfig | 1 + sound/soc/tegra/Kconfig | 12 + sound/soc/tegra/Makefile | 2 + sound/soc/tegra/tegra186_asrc.c | 1045 ++++++++++++++++++++ sound/soc/tegra/tegra186_asrc.h | 113 +++ sound/soc/tegra/tegra210_ahub.c | 82 +- 15 files changed, 2254 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml create mode 100644 sound/soc/tegra/tegra186_asrc.c create mode 100644 sound/soc/tegra/tegra186_asrc.h -- 2.7.4

2 9

[PATCH] ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020
by Kai-Heng Feng 29 Mar '22

29 Mar '22

Commit 5aec98913095 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") is to solve recording issue met on AL236, by matching codec variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256. This match can be too broad and Mi Notebook Pro 2020 is broken by the patch. Instead, use codec ID to be narrow down the scope, in order to make ALC256 unaffected. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484 Fixes: 5aec98913095 ("ALSA: hda/realtek - ALC236 headset MIC recording issue") Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4c33cb57963db..0d5e6cfa44888 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3617,8 +3617,8 @@ static void alc256_shutup(struct hda_codec *codec) /* If disable 3k pulldown control for alc257, the Mic detection will not work correctly * when booting with headset plugged. So skip setting it for the codec alc257 */ - if (spec->codec_variant != ALC269_TYPE_ALC257 && - spec->codec_variant != ALC269_TYPE_ALC256) + if (codec->core.vendor_id != 0x10ec0236 || + codec->core.vendor_id != 0x10ec0257) alc_update_coef_idx(codec, 0x46, 0, 3 << 12); if (!spec->no_shutup_pins) -- 2.34.1

3 2