September 2025 - Alsa-devel - mailman.alsa-project.org

Internal microphone (Conexant SN6140) nonfunctional on Lenovo IdeaPad Slim 5 16AKP10 83HY after alsa-ucm-conf 1.2.14+
by GitHub issues - edited 12 Sep '25

12 Sep '25

alsa-project/alsa-ucm-conf issue #612 was edited from JayJaber: The internal microphone on a Lenovo IdeaPad Slim 5 16AKP10 83HY with Conexant SN6140 codec behaves as follows: On alsa-ucm-conf 1.2.14 and newer: - Family 17h/19h/1ah HD Audio Controller Digital Microphone appears as a recording device but does not record. Only a small bit of static is audible at the start and end of recordings. - Family 17h/19h/1ah HD Audio Controller Stereo Microphone appears as inactive/unplugged. When headphones are plugged in, it becomes active and the headphone microphone works under that device. After downgrading to alsa-ucm-conf 1.2.13-2: - Both Family 17h/19h/1ah HD Audio Controller Internal Stereo Microphone and Family 17h/19h/1ah HD Audio Controller Digital Microphone appear as active recording devices without headphones plugged in. - Digital Microphone still does not record usable audio, only a small bit of static at the beginning and end. - Internal Stereo Microphone works correctly for the built-in mic when headphones are not plugged in. Plugging in headphones causes the headphone microphone to be used under the Internal Stereo Microphone device. Summary: The Digital Microphone is detected but never records usable audio. On 1.2.13-2, the Internal Stereo Microphone routes audio correctly from the built-in mic, so recording works, but the Digital Microphone itself remains nonfunctional. On 1.2.14+: - Digital Microphone appears but remains completely nonfunctional. - Stereo Microphone shows as inactive/unplugged until headphones are connected, making the internal microphone unusable. - Headphone microphone routing works correctly. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/612 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Internal microphone (Conexant SN6140) detected but shows inactive/unplugged on Lenovo IdeaPad Slim 5 16AKP10 83HY after alsa-ucm-conf 1.2.14
by GitHub issues - edited 12 Sep '25

12 Sep '25

alsa-project/alsa-ucm-conf issue #612 was edited from JayJaber: The internal microphone on a Lenovo IdeaPad Slim 5 16AKP10 83HY with Conexant SN6140 codec behaves as follows: On alsa-ucm-conf 1.2.14 and newer: - Family 17h/19h/1ah HD Audio Controller Digital Microphone appears as a recording device but does not record. Only a small bit of static is audible at the start and end of recordings. - Family 17h/19h/1ah HD Audio Controller Stereo Microphone appears as inactive/unplugged. When headphones are plugged in, it becomes active and the headphone microphone works under that device. After downgrading to alsa-ucm-conf 1.2.13-2: - Both Family 17h/19h/1ah HD Audio Controller Internal Stereo Microphone and Family 17h/19h/1ah HD Audio Controller Digital Microphone appear as active recording devices without headphones plugged in. - Digital Microphone still does not record usable audio, only a small bit of static at the beginning and end. - Internal Stereo Microphone works correctly for the built-in mic when headphones are not plugged in. Plugging in headphones causes the headphone microphone to be used under the Internal Stereo Microphone device. Summary: The Digital Microphone is detected but never records usable audio. On 1.2.13-2, the Internal Stereo Microphone routes audio correctly from the built-in mic, so recording works, but the Digital Microphone itself remains nonfunctional. On 1.2.14+: - Digital Microphone appears but remains completely nonfunctional. - Stereo Microphone shows as inactive/unplugged until headphones are connected, making the internal microphone unusable. - Headphone microphone routing works correctly. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/612 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Re: [EXTERNAL] Re: [PATCH v4 2/6] ASoC: ops: add snd_soc_get_volsw_clamped
by Mark Brown 11 Sep '25

11 Sep '25

On Thu, Sep 11, 2025 at 05:21:14PM +0000, Holalu Yogendra, Niranjan wrote: > > From: Mark Brown <broonie(a)kernel.org> > > Why is this a separate API, what is the situation where we would want to > > report an invalid value from a control? I was thinking of just adding > > this to the existing operations rather than adding separate ones that > > need to be explicitly set. > Since few of the drivers as still using the original API, and was not sure if > everyone wanted to clamp the register value, did not want to disturb the > original API snd_soc_get_volsw. Per my analysis, if register read fails due to In what situation would anything want to report an invalid value? > some issue (like IO) and, for some reason if register value was modified > to have the value greater than mc->max value, the volume is report erroneously. > Are you thinking that this patch could be dropped and clamp the value to max in > 'soc_get_volsw' (as in 1st patch) and use the same API ? Please suggest. Yes, everything should report valid values. I/O errors should be propagated as errors.

1 0

[PATCH v1] ALSA: hda/tas2781: Fix a potential race condition that causes a NULL pointer in case no efi.get_variable exsits
by Shenghao Ding 11 Sep '25

11 Sep '25

A a potential race condition reported by one of my customers that leads to a NULL pointer dereference, where the call to efi.get_variable should be guarded with efi_rt_services_supported() to ensure that function exists. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- sound/hda/codecs/side-codecs/tas2781_hda.c | 5 +++++ sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda.c b/sound/hda/codecs/side-codecs/tas2781_hda.c index 536940c78f00..96e6d82dc69e 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda.c @@ -193,6 +193,11 @@ int tas2781_save_calibration(struct tas2781_hda *hda) efi_status_t status; int i; + if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) { + dev_err(p->dev, "%s: NO EFI FOUND!\n", __func__); + return -EINVAL; + } + if (hda->catlog_id < LENOVO) efi_guid = tasdev_fct_efi_guid[hda->catlog_id]; diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index 008dbe1490a7..4dea442d8c30 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -317,6 +317,11 @@ static int tas2563_save_calibration(struct tas2781_hda *h) unsigned int attr; int ret, i, j, k; + if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) { + dev_err(p->dev, "%s: NO EFI FOUND!\n", __func__); + return -EINVAL; + } + cd->cali_dat_sz_per_dev = TAS2563_CAL_DATA_SIZE * TASDEV_CALIB_N; /* extra byte for each device is the device number */ -- 2.43.0

2 1

Re: [PATCH v4 2/6] ASoC: ops: add snd_soc_get_volsw_clamped
by Mark Brown 11 Sep '25

11 Sep '25

On Thu, Sep 11, 2025 at 09:26:59PM +0530, Niranjan H Y wrote: > Add API snd_soc_get_volsw_clamped to read > the volume from device. This similar to > existing API snd_soc_get_volsw. But has > additional step to clamp the value to max value > if the register value is larger than max value. Why is this a separate API, what is the situation where we would want to report an invalid value from a control? I was thinking of just adding this to the existing operations rather than adding separate ones that need to be explicitly set.

1 0

Internal microphone (Conexant SN6140) detected but shows inactive/unplugged on Lenovo IdeaPad Slim 5 16AKP10 83HY after alsa-ucm-conf 1.2.14
by GitHub issues - edited 11 Sep '25

11 Sep '25

alsa-project/alsa-ucm-conf issue #612 was edited from JayJaber: On a Lenovo IdeaPad Slim 5 16AKP10 83HY with Conexant SN6140 codec, the internal microphone works correctly with alsa-ucm-conf 1.2.13-2, but with 1.2.14 and newer it is detected but shows up as inactive/unplugged. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/612 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Internal microphone (Conexant SN6140) detected but shows inactive/unplugged on Lenovo IdeaPad Slim 5 16AKP10 83HY after alsa-ucm-conf 1.2.14
by GitHub issues - edited 11 Sep '25

11 Sep '25

alsa-project/alsa-ucm-conf issue #612 was edited from JayJaber: On a Lenovo IdeaPad Slim 5 16AKP10 83HY with Conexant SN6140 codec, the internal microphone works correctly with alsa-ucm-conf 1.2.13-2, but with 1.2.14 and newer it is not detected and shows up as inactive/unplugged. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/612 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Internal microphone (Conexant SN6140) not detected on Lenovo IdeaPad Slim 5 16AKP10 83HY after alsa-ucm-conf 1.2.14
by GitHub issues - opened 11 Sep '25

11 Sep '25

alsa-project/alsa-ucm-conf issue #612 was opened from JayJaber: On a Lenovo IdeaPad Slim 5 16AKP10 83HY with Conexant SN6140 codec, the internal microphone works correctly with alsa-ucm-conf 1.2.13-2, but with 1.2.14 and newer it is not detected and shows up as inactive/unplugged. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/612 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[tiwai-sound:test/auto-cleanup 208/210] sound/sparc/amd7930.c:357:45: error: 'flags' undeclared
by kernel test robot 10 Sep '25

10 Sep '25

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git test/auto-cleanup head: f29244cff0185975fee4f55293cca61cfd83af3e commit: db8ed7441c876cac679db2869b87b26633c89bde [208/210] ALSA: sparc/amd7930: Use guard() for spin locks config: sparc64-randconfig-002-20250910 (https://download.01.org/0day-ci/archive/20250911/202509110130.PlGyYo4k-lkp@…) compiler: sparc64-linux-gcc (GCC) 12.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250911/202509110130.PlGyYo4k-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509110130.PlGyYo4k-lkp@intel.com/ All errors (new ones prefixed by >>): sound/sparc/amd7930.c: In function 'amd7930_enable_ints': >> sound/sparc/amd7930.c:357:45: error: 'flags' undeclared (first use in this function) 357 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ sound/sparc/amd7930.c:357:45: note: each undeclared identifier is reported only once for each function it appears in In file included from include/linux/module.h:17, from sound/sparc/amd7930.c:33: >> include/linux/cleanup.h:291:17: error: too many arguments to function 'class_spinlock_irqsave_constructor' 291 | class_##_name##_constructor | ^~~~~~ include/linux/cleanup.h:401:9: note: in expansion of macro 'CLASS' 401 | CLASS(_name, __UNIQUE_ID(guard)) | ^~~~~ sound/sparc/amd7930.c:357:9: note: in expansion of macro 'guard' 357 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ include/linux/cleanup.h:477:33: note: declared here 477 | static inline class_##_name##_t class_##_name##_constructor(_type *l) \ | ^~~~~~ include/linux/cleanup.h:496:1: note: in expansion of macro '__DEFINE_LOCK_GUARD_1' 496 | __DEFINE_LOCK_GUARD_1(_name, _type, _lock) | ^~~~~~~~~~~~~~~~~~~~~ include/linux/spinlock.h:585:1: note: in expansion of macro 'DEFINE_LOCK_GUARD_1' 585 | DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t, | ^~~~~~~~~~~~~~~~~~~ sound/sparc/amd7930.c: In function 'amd7930_disable_ints': sound/sparc/amd7930.c:365:45: error: 'flags' undeclared (first use in this function) 365 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ >> include/linux/cleanup.h:291:17: error: too many arguments to function 'class_spinlock_irqsave_constructor' 291 | class_##_name##_constructor | ^~~~~~ include/linux/cleanup.h:401:9: note: in expansion of macro 'CLASS' 401 | CLASS(_name, __UNIQUE_ID(guard)) | ^~~~~ sound/sparc/amd7930.c:365:9: note: in expansion of macro 'guard' 365 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ include/linux/cleanup.h:477:33: note: declared here 477 | static inline class_##_name##_t class_##_name##_constructor(_type *l) \ | ^~~~~~ include/linux/cleanup.h:496:1: note: in expansion of macro '__DEFINE_LOCK_GUARD_1' 496 | __DEFINE_LOCK_GUARD_1(_name, _type, _lock) | ^~~~~~~~~~~~~~~~~~~~~ include/linux/spinlock.h:585:1: note: in expansion of macro 'DEFINE_LOCK_GUARD_1' 585 | DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t, | ^~~~~~~~~~~~~~~~~~~ -- amd7930.c: In function 'amd7930_enable_ints': amd7930.c:357:45: error: 'flags' undeclared (first use in this function) 357 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ amd7930.c:357:45: note: each undeclared identifier is reported only once for each function it appears in In file included from include/linux/module.h:17, from amd7930.c:33: >> include/linux/cleanup.h:291:17: error: too many arguments to function 'class_spinlock_irqsave_constructor' 291 | class_##_name##_constructor | ^~~~~~ include/linux/cleanup.h:401:9: note: in expansion of macro 'CLASS' 401 | CLASS(_name, __UNIQUE_ID(guard)) | ^~~~~ amd7930.c:357:9: note: in expansion of macro 'guard' 357 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ include/linux/cleanup.h:477:33: note: declared here 477 | static inline class_##_name##_t class_##_name##_constructor(_type *l) \ | ^~~~~~ include/linux/cleanup.h:496:1: note: in expansion of macro '__DEFINE_LOCK_GUARD_1' 496 | __DEFINE_LOCK_GUARD_1(_name, _type, _lock) | ^~~~~~~~~~~~~~~~~~~~~ include/linux/spinlock.h:585:1: note: in expansion of macro 'DEFINE_LOCK_GUARD_1' 585 | DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t, | ^~~~~~~~~~~~~~~~~~~ amd7930.c: In function 'amd7930_disable_ints': amd7930.c:365:45: error: 'flags' undeclared (first use in this function) 365 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ >> include/linux/cleanup.h:291:17: error: too many arguments to function 'class_spinlock_irqsave_constructor' 291 | class_##_name##_constructor | ^~~~~~ include/linux/cleanup.h:401:9: note: in expansion of macro 'CLASS' 401 | CLASS(_name, __UNIQUE_ID(guard)) | ^~~~~ amd7930.c:365:9: note: in expansion of macro 'guard' 365 | guard(spinlock_irqsave)(&amd->lock, flags); | ^~~~~ include/linux/cleanup.h:477:33: note: declared here 477 | static inline class_##_name##_t class_##_name##_constructor(_type *l) \ | ^~~~~~ include/linux/cleanup.h:496:1: note: in expansion of macro '__DEFINE_LOCK_GUARD_1' 496 | __DEFINE_LOCK_GUARD_1(_name, _type, _lock) | ^~~~~~~~~~~~~~~~~~~~~ include/linux/spinlock.h:585:1: note: in expansion of macro 'DEFINE_LOCK_GUARD_1' 585 | DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t, | ^~~~~~~~~~~~~~~~~~~ vim +/flags +357 sound/sparc/amd7930.c 353 354 /* Enable chip interrupts. The amd->lock is not held. */ 355 static __inline__ void amd7930_enable_ints(struct snd_amd7930 *amd) 356 { > 357 guard(spinlock_irqsave)(&amd->lock, flags); 358 sbus_writeb(AMR_INIT, amd->regs + AMD7930_CR); 359 sbus_writeb(AM_INIT_ACTIVE, amd->regs + AMD7930_DR); 360 } 361 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

Re: [PATCH v3 1/4] ASoc: tas2783A: Add soundwire based codec driver
by Mark Brown 10 Sep '25

10 Sep '25

On Wed, Sep 10, 2025 at 05:49:14PM +0530, Niranjan H Y wrote: > new file mode 100644 > index 000000000..ddadfb7c5 > --- /dev/null > +++ b/sound/soc/codecs/tas2783-sdw.c > @@ -0,0 +1,1417 @@ > +#if !IS_ENABLED(CONFIG_SND_SOC_TAS2783_UTIL) > +static void tas25xx_register_misc(struct sdw_slave *peripheral) {} > +static void tas25xx_deregister_misc(void) {} > +#endif This config symbol doesn't exist already and isn't defined by the patch. If it did exist I'd expect these stubs to be in a header file rather than a C file. What's going on here? > +static s32 tas2783_digital_getvol(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_component *component = > + snd_soc_kcontrol_component(kcontrol); > + struct tas2783_prv *tas_dev = > + snd_soc_component_get_drvdata(component); > + struct soc_mixer_control *mc = > + (struct soc_mixer_control *)kcontrol->private_value; > + s32 val, ret; > + > + ret = regmap_read(tas_dev->regmap, mc->reg, &val); > + if (ret < 0) > + return ret; > + > + ucontrol->value.integer.value[0] = > + tas_clamp(val, mc->max, mc->invert); It feels like rather than define a custom read operation it'd be better to make this clamping part of the generic ASoC ops if it's needed - the code is totally generic and you could see something similar for any device that has a limited set of values that are valid. Presumably your device happens to trigger this in some common situation but anything could be affected and we should handle it generically. > +static s32 tas2783_digital_putvol(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + val = tas_clamp(ucontrol->value.integer.value[0], > + mc->max, mc->invert); This appears to be the only non-standard part of this function but the generic implementation should already deal with invalid inputs. > + ret = regmap_write(tas_dev->regmap, mc->reg, val); > + if (ret) > + dev_dbg(tas_dev->dev, "put vol %d into %x %x\n", > + val, mc->reg, ret); > + > + return ret; This won't return 1 on change, mixer-test will tell you that (and spot a bunch of other errors). > +static const struct snd_kcontrol_new tas2783_snd_controls[] = { > + SOC_SINGLE_RANGE_EXT_TLV("Amp Gain Volume", TAS2783_AMP_LEVEL, > + 1, 0, 20, 0, tas2783_amp_getvol, > + tas2783_amp_putvol, tas2781_amp_tlv), Just Amp Volume.

1 0