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

[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

USB-Audio: Add profile for MSI MPG X570S Carbon Max Wifi.
by GitHub pull_request - opened 29 Mar '22

29 Mar '22

alsa-project/alsa-ucm-conf pull request #143 was opened from lordhoto: This patch depends on Linux 5.17. This board features an Realtek ALC4080 chip. The various inputs and outputs are distributed over multiple hardware devices: * Input - hw:$card,0 loop back from speaker (called "Analog In") - hw:$card,1 line in at back panel - hw:$card,2 microphone from front AND back panel * Output - hw:$card,0 speaker output at back panel (up to 7.1) - hw:$card,1 headerphone output at front panel - hw:$card,2 could not figure this one out - hw:$card,3 guessed S/PDIF output (sadly no way to test) By default Mic and Line in are disabled. This confuses applications, thus I made the profile enable them by default. Without an UCM profile PulseAudio is not able to create output on the front panel nor record any microphone input. Signed-off-by: Johannes Schickel <lordhoto(a)gmail.com> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/143 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/143.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[RFC PATCH v2 0/6] Flexible codec clock configuration
by Sameer Pujar 29 Mar '22

29 Mar '22

Typically the codec drivers require setting up of Sysclk. Sometimes presence of internal PLL can provide more options of Sysclk configuration. Presently ASoC provides callbacks set_sysclk() and set_pll() in such cases. However it comes with following limitations considering generic machine drivers (simple-card or audio-graph-card): 1. The Sysclk source needs to be passed to set_sysclk() callback. Presently simple-card or audio-graph-card card rely on default source value (which is 0). If any other source needs to be used, it is currently not possible. 2. The same would be true for codec PLL configuration as well, though simple-card or audio-graph-card don't have support yet for the PLL configuration. Earlier attempt[0] to address above was not felt suitable. The suggestion was to use standard clock based bindings instead. This RFC series takes RT5659 as a reference and exposes clock relationships via DT. **This is not in the final shape yet**, but I wanted to get some valuable feedback to understand if the idea is right. If this appears fine, this can be extended to other codecs (wherever necessary). This does not completely remove the need of set_sysclk() callback because the clock requirement (MCLK * fs) would come from the machine driver. But machine driver need not worry about Sysclk source. It would be internally managed by Codec via DT clock relationships. [0] https://patchwork.kernel.org/project/alsa-devel/list/?series=438531&archive… Changelog: ========== v1 -> v2: --------- * New patch added to convert rt5659 binding doc to YAML format * New patch added to document audio-graph-port binding for rt5659 * New patch added to document clock binding enhancement for rt5659 Sameer Pujar (6): ASoC: dt-bindings: Convert rt5659 bindings to YAML schema ASoC: dt-bindings: Add audio-graph-port bindings to rt5659 ASoC: dt-bindings: Extend clock bindings of rt5659 ASoC: soc-pcm: tweak DPCM BE hw_param() call order ASoC: rt5659: Expose internal clock relationships ASoC: tegra: Get clock rate in consumer mode .../devicetree/bindings/sound/realtek,rt5659.yaml | 179 +++++++++++++++ Documentation/devicetree/bindings/sound/rt5659.txt | 89 -------- sound/soc/codecs/rt5659.c | 248 ++++++++++++++++++++- sound/soc/codecs/rt5659.h | 9 + sound/soc/soc-pcm.c | 60 ++++- sound/soc/tegra/tegra210_i2s.c | 25 ++- 6 files changed, 503 insertions(+), 107 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/realtek,rt5659.yaml delete mode 100644 Documentation/devicetree/bindings/sound/rt5659.txt -- 2.7.4

5 21

[PATCH] mediatek: mt8195: fix a missing check on list iterator
by Xiaomeng Tong 29 Mar '22

29 Mar '22

The bug is here: mt8195_etdm_hw_params_fixup(runtime, params); For the for_each_card_rtds(), just like list_for_each_entry(), the list iterator 'runtime' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'runtime' as a dedicated pointer to point to the found element. Cc: stable(a)vger.kernel.org Fixes: 3d00d2c07f04f ("ASoC: mediatek: mt8195: add sof support on mt8195-mt6359-rt1019-rt5682") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- .../mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c b/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c index 29c2d3407cc7..dc91877e4c3c 100644 --- a/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c +++ b/sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c @@ -814,7 +814,7 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, { struct snd_soc_card *card = rtd->card; struct snd_soc_dai_link *sof_dai_link = NULL; - struct snd_soc_pcm_runtime *runtime; + struct snd_soc_pcm_runtime *runtime = NULL, *iter; struct snd_soc_dai *cpu_dai; int i, j, ret = 0; @@ -824,16 +824,17 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, if (strcmp(rtd->dai_link->name, conn->normal_link)) continue; - for_each_card_rtds(card, runtime) { - if (strcmp(runtime->dai_link->name, conn->sof_link)) + for_each_card_rtds(card, iter) { + if (strcmp(iter->dai_link->name, conn->sof_link)) continue; - for_each_rtd_cpu_dais(runtime, j, cpu_dai) { + for_each_rtd_cpu_dais(iter, j, cpu_dai) { if (cpu_dai->stream_active[conn->stream_dir] > 0) { - sof_dai_link = runtime->dai_link; + sof_dai_link = iter->dai_link; break; } } + runtime = iter; break; } @@ -845,7 +846,8 @@ static int mt8195_dai_link_fixup(struct snd_soc_pcm_runtime *rtd, if (!strcmp(rtd->dai_link->name, "ETDM2_IN_BE") || !strcmp(rtd->dai_link->name, "ETDM1_OUT_BE")) { - mt8195_etdm_hw_params_fixup(runtime, params); + if (runtime) + mt8195_etdm_hw_params_fixup(runtime, params); } return ret; -- 2.17.1

2 1

[PATCH] soc: soc-dapm: fix two incorrect uses of list iterator
by Xiaomeng Tong 29 Mar '22

29 Mar '22

These two bug are here: list_for_each_entry_safe_continue(w, n, list, power_list); list_for_each_entry_safe_continue(w, n, list, power_list); After the list_for_each_entry_safe_continue() exits, the list iterator will always be a bogus pointer which point to an invalid struct objdect containing HEAD member. The funciton poniter 'w->event' will be a invalid value which can lead to a control-flow hijack if the 'w' can be controlled. The original intention was to break the outer list_for_each_entry_safe() loop if w->event is NULL, but forgot to *break* switch statement first. So just add a break to fix the bug. Cc: stable(a)vger.kernel.org Fixes: 163cac061c973 ("ASoC: Factor out DAPM sequence execution") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- sound/soc/soc-dapm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index b06c5682445c..2a5a64d21856 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1686,9 +1686,11 @@ static void dapm_seq_run(struct snd_soc_card *card, switch (w->id) { case snd_soc_dapm_pre: - if (!w->event) + if (!w->event) { list_for_each_entry_safe_continue(w, n, list, power_list); + break; + } if (event == SND_SOC_DAPM_STREAM_START) ret = w->event(w, @@ -1699,9 +1701,11 @@ static void dapm_seq_run(struct snd_soc_card *card, break; case snd_soc_dapm_post: - if (!w->event) + if (!w->event) { list_for_each_entry_safe_continue(w, n, list, power_list); + break; + } if (event == SND_SOC_DAPM_STREAM_START) ret = w->event(w, -- 2.17.1

2 2

[PATCH 00/14] ASoC: Intel: avs: Topology and path management
by Cezary Rojewski 29 Mar '22

29 Mar '22

A continuation of avs-driver initial series [1]. This chapter covers path management and topology parsing part which was ealier path of the main series. The two patches that represented these two subjects in the initial series, have been split into many to allow for easier review and discussion. AVS topology is split into two major parts: dictionaries - found within ASoC topology manifest - and path templates. Dictionaries job is to reduce the total amount of memory occupied by topology elements. Rather than having every pipeline and module carry its own information, each refers to specific entry in specific dictionary by provided (from topology file) indexes. In consequence, most struct avs_tplg_xxx are made out of pointers. Path templates are similar to path descriptions found in skylake-driver and they describe how given path shall look like in runtime - number of modules and pipelines that shape it and how they are laid out. A single path template is tied either to FE or BE and thus at most to a single, user-visible endpoint when speaking of FE. Path is a software representation of its ADSP firmware equivalent. It's a logical container for pipelines which are themselves containers - this time for modules i.e. processing units. Depending on the number of audio formats supported, each path template may carry one or more descriptions of given path. During runtime, when audio format is known, description matching said format is selected and used when instantiating path on ADSP firmware side through IPCs. Changes RFC -> v1: - Plenty of rewordings and spelling fixes as requested by Pierre - any sysfs-functionality-related left in RFC dropped, will be part of separate subject in the future - separated parsing of formatted strings into: "Support link_mask formatted string" patch, increasing series size to 14 patches [1]: https://lore.kernel.org/alsa-devel/20220207122108.3780926-1-cezary.rojewski… Cezary Rojewski (14): ASoC: Intel: avs: Declare vendor tokens ASoC: Intel: avs: Add topology parsing infrastructure ASoC: Intel: avs: Parse module-extension tuples ASoC: Intel: avs: Parse pplcfg and binding tuples ASoC: Intel: avs: Parse pipeline and module tuples ASoC: Intel: avs: Parse path and path templates tuples ASoC: Intel: avs: Add topology loading operations ASoC: Intel: avs: Support link_mask formatted string ASoC: Intel: avs: Declare path and its components ASoC: Intel: avs: Path creation and freeing ASoC: Intel: avs: Path state management ASoC: Intel: avs: Arm paths after creating them ASoC: Intel: avs: Prepare modules before bindings them ASoC: Intel: avs: Configure modules according to their type include/uapi/sound/intel/avs/tokens.h | 126 ++ sound/soc/intel/Kconfig | 2 + sound/soc/intel/avs/Makefile | 3 +- sound/soc/intel/avs/avs.h | 23 + sound/soc/intel/avs/path.c | 1008 ++++++++++++++++ sound/soc/intel/avs/path.h | 72 ++ sound/soc/intel/avs/topology.c | 1600 +++++++++++++++++++++++++ sound/soc/intel/avs/topology.h | 194 +++ 8 files changed, 3027 insertions(+), 1 deletion(-) create mode 100644 include/uapi/sound/intel/avs/tokens.h create mode 100644 sound/soc/intel/avs/path.c create mode 100644 sound/soc/intel/avs/path.h create mode 100644 sound/soc/intel/avs/topology.c create mode 100644 sound/soc/intel/avs/topology.h -- 2.25.1

2 15

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

28 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 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index c85ed7bc121e..67870c8d84a5 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; /* @@ -1639,7 +1640,8 @@ static void hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin, int ret; ret = snd_hda_power_up_pm(codec); - if (ret < 0 && pm_runtime_suspended(hda_codec_dev(codec))) + if ((ret < 0 && pm_runtime_suspended(dev)) || + (dev->power.runtime_status == RPM_SUSPENDING)) goto out; present = snd_hda_jack_pin_sense(codec, pin_nid, dev_id); -- 2.17.1

4 8

[PATCH 0/6] Add new HW variants and fix few minor issues
by Vitaly Rodionov 28 Mar '22

28 Mar '22

This series adds new HW variants for Dell's Dolphin and Warlock, and also fixies few very minor issues. Stefan Binding (5): ALSA: hda/cs8409: Fix Warlock to use mono mic configuration ALSA: hda/cs8409: Re-order quirk table into ascending order ALSA: hda/cs8409: Fix Full Scale Volume setting for all variants ALSA: hda/cs8409: Support new Warlock MLK Variants ALSA: hda/cs8409: Disable HSBIAS_SENSE_EN for Cyborg Vitaly Rodionov (1): ALSA: hda/cs8409: Add new Dolphin HW variants sound/pci/hda/patch_cs8409-tables.c | 68 +++++++++++++++++++++-------- sound/pci/hda/patch_cs8409.c | 47 +++++++++++--------- sound/pci/hda/patch_cs8409.h | 5 +++ 3 files changed, 83 insertions(+), 37 deletions(-) -- 2.25.1

2 7

[V3 1/2] ASoC: max98390: Add reset gpio control
by Steve Lee 28 Mar '22

28 Mar '22

Add reset gpio control to support RESET PIN connected to gpio. Signed-off-by: Steve Lee <steve.lee.analog(a)gmail.com> --- sound/soc/codecs/max98390.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c index 40fd6f363f35..05df9b85d9b0 100644 --- a/sound/soc/codecs/max98390.c +++ b/sound/soc/codecs/max98390.c @@ -1022,6 +1022,7 @@ static int max98390_i2c_probe(struct i2c_client *i2c, struct max98390_priv *max98390 = NULL; struct i2c_adapter *adapter = i2c->adapter; + struct gpio_desc *reset_gpio; ret = i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE @@ -1073,6 +1074,17 @@ static int max98390_i2c_probe(struct i2c_client *i2c, return ret; } + reset_gpio = devm_gpiod_get_optional(&i2c->dev, + "reset", GPIOD_OUT_LOW); + + /* Power on device */ + if (reset_gpio) { + usleep_range(1000, 2000); + /* bring out of reset */ + gpiod_set_value_cansleep(reset_gpio, 1); + usleep_range(1000, 2000); + } + /* Check Revision ID */ ret = regmap_read(max98390->regmap, MAX98390_R24FF_REV_ID, &reg); -- 2.17.1

3 5

Bug 215711 - snd_hda_intel not binding to codec
by Thorsten Leemhuis 28 Mar '22

28 Mar '22

Hi, this is your Linux kernel regression tracker. I noticed a regression report in bugzilla.kernel.org that afaics nobody acted upon since it was reported about a week ago, that's why I decided to forward it to the lists and the maintainers. To quote from https://bugzilla.kernel.org/show_bug.cgi?id=215711: > Created attachment 300588 [details] > SND_HDA_* excrept from kernel config > > On PCI device discovery the Intel HDA codec doesn't bind to appropriate codec (if that is the correct term). The device codec (Conexant) is loaded, but sound doesn't work. Reloading the main module (snd_hda_intel) fixes the issue: > > $ echo 1 > /sys/bus/pci/devices/0000:00:1b.0/remove > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > $ echo 1 > /sys/bus/pci/rescan > # dmesg output > [ 9218.563134] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 > [ 9218.563178] pci 0000:00:1b.0: reg 0x10: [mem 0xc0004000-0xc0007fff 64bit] > [ 9218.563344] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold > [ 9218.563818] pci 0000:00:1b.0: BAR 0: assigned [mem 0xc0004000-0xc0007fff 64bit] > [ 9218.563846] pci 0000:00:1e.0: PCI bridge to [bus 0e] > [ 9218.598927] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops 0xffffffff824a44e0) > [ 9218.609798] snd_hda_intel 0000:00:1b.0: Cannot probe codecs, giving up > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > snd 77824 7 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm > snd_hda_codec 118784 3 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel > snd_hda_codec_conexant 20480 0 > snd_hda_codec_generic 77824 1 snd_hda_codec_conexant > snd_hda_core 65536 4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec > snd_hda_intel 36864 0 > snd_hwdep 16384 1 snd_hda_codec > snd_intel_dspcfg 16384 1 snd_hda_intel > snd_pcm 110592 3 snd_hda_intel,snd_hda_codec,snd_hda_core > snd_timer 32768 1 snd_pcm > soundcore 16384 1 snd > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > $ modprobe -rv snd_hda_intel; modprobe -v snd_hda_intel > # dmesg output > [ 9230.886362] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops 0xffffffff824a44e0) > [ 9230.895721] snd_hda_codec_conexant hdaudioC0D0: CX20585: BIOS auto-probing. > [ 9230.896677] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20585: line_outs=1 (0x1f/0x0/0x0/0x0/0x0) type:speaker > [ 9230.896691] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.896700] snd_hda_codec_conexant hdaudioC0D0: hp_outs=2 (0x1c/0x19/0x0/0x0/0x0) > [ 9230.896707] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0 > [ 9230.896713] snd_hda_codec_conexant hdaudioC0D0: inputs: > [ 9230.896718] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x23 > [ 9230.896724] snd_hda_codec_conexant hdaudioC0D0: Mic=0x1b > [ 9230.896729] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x1a > [ 9230.908437] snd_hda_codec_generic hdaudioC0D3: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line > [ 9230.908454] snd_hda_codec_generic hdaudioC0D3: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.908461] snd_hda_codec_generic hdaudioC0D3: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) > [ 9230.908468] snd_hda_codec_generic hdaudioC0D3: mono: mono_out=0x0 > [ 9230.908473] snd_hda_codec_generic hdaudioC0D3: dig-out=0x5/0x0 > [ 9230.908477] snd_hda_codec_generic hdaudioC0D3: inputs: > [ 9230.916063] input: HDA Intel MID Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input52 > [ 9230.916216] input: HDA Intel MID Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input53 > [ 9230.916353] input: HDA Intel MID Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input54 > [ 9230.919563] input: HDA Intel MID Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input55 > [ 9230.919727] input: HDA Intel MID HDMI as /devices/pci0000:00/0000:00:1b.0/sound/card0/input56 > > $ lsmod | sort > Module Size Used by > configs 45056 0 > e1000e 225280 0 > grace 16384 1 lockd > irqbypass 16384 1 kvm > iwlwifi 274432 0 > kvm 569344 1 kvm_intel > kvm_intel 229376 0 > lockd 98304 1 nfs > mei 90112 1 mei_me > mei_me 28672 0 > nfs 184320 3 nfsv4 > nfsv4 380928 2 > snd 77824 7 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm > snd_hda_codec 118784 3 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel > snd_hda_codec_conexant 20480 1 > snd_hda_codec_generic 77824 2 snd_hda_codec_conexant > snd_hda_core 65536 4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_intel,snd_hda_codec > snd_hda_intel 36864 0 > snd_hwdep 16384 1 snd_hda_codec > snd_intel_dspcfg 16384 1 snd_hda_intel > snd_pcm 110592 3 snd_hda_intel,snd_hda_codec,snd_hda_core > snd_timer 32768 1 snd_pcm > soundcore 16384 1 snd > sunrpc 274432 9 nfsv4,lockd,nfs > uvcvideo 110592 0 > videobuf2_common 45056 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops > videobuf2_memops 16384 1 videobuf2_vmalloc > videobuf2_v4l2 24576 1 uvcvideo > videobuf2_vmalloc 16384 1 uvcvideo > > > 5.15.29, have observed it already at least on 5.10.27, HW is ThinkPad x201 (x220 as well). I'm marking it as regression, since it used to work in the distant past (5.4-ish at least iirc) Could somebody take a look into this? Or was this discussed somewhere else already? Or even fixed? Anyway, to get this tracked: #regzbot introduced: v5.4..v5.10 #regzbot from: Petr Cerny <bugzilla(a)black-net.org> #regzbot title: snd: snd_hda_intel not binding to codec #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215711 Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. -- Additional information about regzbot: If you want to know more about regzbot, check out its web-interface, the getting start guide, and the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md The last two documents will explain how you can interact with regzbot yourself if your want to. Hint for reporters: when reporting a regression it's in your interest to CC the regression list and tell regzbot about the issue, as that ensures the regression makes it onto the radar of the Linux kernel's regression tracker -- that's in your interest, as it ensures your report won't fall through the cracks unnoticed. Hint for developers: you normally don't need to care about regzbot once it's involved. Fix the issue as you normally would, just remember to include 'Link:' tag in the patch descriptions pointing to all reports about the issue. This has been expected from developers even before regzbot showed up for reasons explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'.

1 0