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

[PATCH] ASoC: max98088: add support for reg_4a_cfg_bypass reg
by Tommaso Merciai 16 May '22

16 May '22

Add mixer controls support for M98088_REG_4A_CFG_BYPASS register References: - https://datasheets.maximintegrated.com/en/ds/MAX98089.pdf p71, p113 Signed-off-by: Tommaso Merciai <tommaso.merciai(a)amarulasolutions.com> --- sound/soc/codecs/max98088.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c index 429717d4ac5a..f8ec2f164e08 100644 --- a/sound/soc/codecs/max98088.c +++ b/sound/soc/codecs/max98088.c @@ -486,6 +486,11 @@ static const struct snd_kcontrol_new max98088_snd_controls[] = { SOC_SINGLE("EQ1 Switch", M98088_REG_49_CFG_LEVEL, 0, 1, 0), SOC_SINGLE("EQ2 Switch", M98088_REG_49_CFG_LEVEL, 1, 1, 0), + SOC_SINGLE("SPK Bypass Switch", M98088_REG_4A_CFG_BYPASS, 0, 1, 0), + SOC_SINGLE("REC Bypass Switch", M98088_REG_4A_CFG_BYPASS, 1, 1, 0), + SOC_SINGLE("MIC2 Bypass Switch", M98088_REG_4A_CFG_BYPASS, 4, 1, 0), + SOC_SINGLE("INA Bypass Switch", M98088_REG_4A_CFG_BYPASS, 7, 1, 0), + SOC_ENUM("EX Limiter Mode", max98088_exmode_enum), SOC_ENUM("EX Limiter Threshold", max98088_ex_thresh_enum), -- 2.25.1

2 9

[PATCH] ALSA: usb-audio: Restore Rane SL-1 quirk
by Takashi Iwai 16 May '22

16 May '22

At cleaning up and moving the device rename from the quirk table to its own table, we removed the entry for Rane SL-1 as we thought it's only for renaming. It turned out, however, that the quirk is required for matching with the device that declares itself as no standard audio but only as vendor-specific. Restore the quirk entry for Rane SL-1 to fix the regression. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215887 Fixes: 5436f59bc5bc ("ALSA: usb-audio: Move device rename and profile quirks to an internal table") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/quirks-table.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 0ea39565e623..40a5e3eb4ef2 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3235,6 +3235,15 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +/* Rane SL-1 */ +{ + USB_DEVICE(0x13e5, 0x0001), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + } +}, + /* disabled due to regression for other devices; * see https://bugzilla.kernel.org/show_bug.cgi?id=199905 */ -- 2.35.3

1 0

[bug report] ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages
by Dan Carpenter 16 May '22

16 May '22

Hello Peter Ujfalusi, The patch 066c67624d8c: "ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages" from May 6, 2022, leads to the following Smatch static checker warning: sound/soc/sof/sof-client-ipc-msg-injector.c:95 sof_msg_inject_ipc4_dfs_read() warn: userbuf overflow? is '8' <= 'count' sound/soc/sof/sof-client-ipc-msg-injector.c 72 static ssize_t sof_msg_inject_ipc4_dfs_read(struct file *file, 73 char __user *buffer, 74 size_t count, loff_t *ppos) 75 { 76 struct sof_client_dev *cdev = file->private_data; 77 struct sof_msg_inject_priv *priv = cdev->data; 78 struct sof_ipc4_msg *ipc4_msg = priv->rx_buffer; 79 size_t remaining; 80 81 if (!ipc4_msg->header_u64 || !count || *ppos) 82 return 0; 83 84 remaining = sizeof(ipc4_msg->header_u64); 85 86 /* Only get large config have payload */ 87 if (SOF_IPC4_MSG_IS_MODULE_MSG(ipc4_msg->primary) && 88 (SOF_IPC4_MSG_TYPE_GET(ipc4_msg->primary) == SOF_IPC4_MOD_LARGE_CONFIG_GET)) 89 remaining += ipc4_msg->data_size; 90 91 if (count > remaining) 92 count = remaining; 93 94 /* copy the header first */ --> 95 if (copy_to_user(buffer, &ipc4_msg->header_u64, sizeof(ipc4_msg->header_u64))) 96 return -EFAULT; 97 98 *ppos += sizeof(ipc4_msg->header_u64); 99 remaining -= sizeof(ipc4_msg->header_u64); 100 101 if (!remaining) 102 return count; 103 104 if (remaining > ipc4_msg->data_size) 105 remaining = ipc4_msg->data_size; 106 107 /* Copy the payload */ 108 if (copy_to_user(buffer + *ppos, ipc4_msg->data_ptr, remaining)) ^^^^^^^^^^^^^^^ Potentially writing more than count bytes resulting in corrupting the user space memory. 109 return -EFAULT; 110 111 *ppos += remaining; 112 return count; 113 } regards, dan carpenter

2 1

snd_pcm_wait_nocheck - use more finer timeout for the the poll wait
by GitHub issues - edited 16 May '22

16 May '22

alsa-project/alsa-lib issue #228 was edited from takaswie: Axfer calls polling system call(i.e. poll(2), epoll(7), select(7)) without explicit timeout when running for IRQ-based scheduling model. In a case that driver achieves to control sound hardware for periodical hardware IRQ, the call can return due to any event queued by the driver in hardware IRQ context. However, in a case that driver fails to control it, the call cannot return. Especially, this situation easily occurs when developers work to support hardware newly. It's better to care for the situation. How to reproduce: 1. prepare sound hardware which driver fail to control for periodical hardware IRQ. 2. execute axfer for the driver/hardware with options to: * use IRQ-based scheduling model: `--sched-model=irq` * use polling system call: without `--test-nowait` 3. the running process blocks as a call of polling system call (defaultly poll(2) by snd_pcm_wait()) Issue URL : https://github.com/alsa-project/alsa-lib/issues/228 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

axfer: call of polling system call never return when driver fails to queue no period-wakeup event due to the lack of hw IRQ context
by GitHub issues - edited 16 May '22

16 May '22

alsa-project/alsa-lib issue #228 was edited from takaswie: Axfer calls polling system call(i.e. poll(2), epoll(7), select(7)) without explicit timeout when running for IRQ-based scheduling model. In a case that driver achieves to control sound hardware for periodical hardware IRQ, the call can return due to any event queued by the driver in hardware IRQ context. However, in a case that driver fails to control it, the call cannot return. Especially, this situation easily occurs when developers work to support hardware newly. It's better to care for the situation. How to reproduce: 1. prepare sound hardware which driver fail to control for periodical hardware IRQ. 2. execute axfer for the driver/hardware with options to: * use IRQ-based scheduling model: `--sched-model=irq` * use polling system call: without `--test-nowait` 3. the running process blocks as a call of polling system call (defaultly poll(2) by snd_pcm_wait()) Issue URL : https://github.com/alsa-project/alsa-lib/issues/228 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machine
by Andy Chi 16 May '22

16 May '22

* The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Andy Chi <andy.chi(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 33c439578a61..3a1500e487eb 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9091,6 +9091,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8995, "HP EliteBook 855 G9", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x89a4, "HP ProBook 440 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89a6, "HP ProBook 450 G9", ALC236_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x89aa, "HP EliteBook 630 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ac, "HP EliteBook 640 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89ae, "HP EliteBook 650 G9", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x89c3, "Zbook Studio G9", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED), -- 2.25.1

2 1

[PATCH net-next] ALSA: ice1724: return void from snd_vt1724_chip_init()
by Lu Wei 16 May '22

16 May '22

Return int in snd_vt1724_chip_init() is useless since it always returns 0. Signed-off-by: Lu Wei <luwei32(a)huawei.com> --- sound/pci/ice1712/ice1724.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index 6fab2ad85bbe..dfef468ad6dc 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2347,7 +2347,7 @@ static void snd_vt1724_chip_reset(struct snd_ice1712 *ice) msleep(10); } -static int snd_vt1724_chip_init(struct snd_ice1712 *ice) +static void snd_vt1724_chip_init(struct snd_ice1712 *ice) { outb(ice->eeprom.data[ICE_EEP2_SYSCONF], ICEREG1724(ice, SYS_CFG)); outb(ice->eeprom.data[ICE_EEP2_ACLINK], ICEREG1724(ice, AC97_CFG)); @@ -2369,8 +2369,6 @@ static int snd_vt1724_chip_init(struct snd_ice1712 *ice) * since they cause machine lockups */ outb(VT1724_MULTI_FIFO_ERR, ICEMT1724(ice, DMA_INT_MASK)); - - return 0; } static int snd_vt1724_spdif_build_controls(struct snd_ice1712 *ice) @@ -2506,8 +2504,8 @@ static int snd_vt1724_create(struct snd_card *card, snd_vt1724_chip_reset(ice); if (snd_vt1724_read_eeprom(ice, modelname) < 0) return -EIO; - if (snd_vt1724_chip_init(ice) < 0) - return -EIO; + + snd_vt1724_chip_init(ice); return 0; } @@ -2702,11 +2700,7 @@ static int snd_vt1724_resume(struct device *dev) return 0; snd_vt1724_chip_reset(ice); - - if (snd_vt1724_chip_init(ice) < 0) { - snd_card_disconnect(card); - return -EIO; - } + snd_vt1724_chip_init(ice); if (ice->pm_resume) ice->pm_resume(ice); -- 2.17.1

1 0

Weaknesses in alsa_info on new Ubuntu systems
by GitHub issues - opened 15 May '22

15 May '22

alsa-project/alsa-utils issue #146 was opened from mhampl: There are some weaknesses on current Ubuntu systems (e.g. release 22.04) where the alsa_info scripts does not deliver the desired information: The command "tree" is no more provided by default (but can be installed in addition) This results in the error message "./alsa-info.sh: line 661: tree: command not found" and causes missing output in "Sysfs card info" The command "dmesg" requires administrative authorizations (e.g. "sudo dmesg | grep ...") This results in the error message "dmesg: read kernel buffer failed: Operation not permitted" and causes missing output in "ALSA/HDA dmesg" Issue URL : https://github.com/alsa-project/alsa-utils/issues/146 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Missing documentation
by GitHub issues - opened 15 May '22

15 May '22

alsa-project/alsa-lib issue #227 was opened from fedeb95: Hi, this probably isn't the right place, but I couldn't find anything specific for documentation bugs. The links under https://www.alsa-project.org/wiki/ALSA_Driver_Documentation currently give a 404. Issue URL : https://github.com/alsa-project/alsa-lib/issues/227 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

chore: Unify Travis CI process to GitHub Actions
by GitHub pull_request - opened 15 May '22

15 May '22

alsa-project/alsa-lib pull request #226 was opened from Korilakkuma: [Travis are now recommending removing the sudo tag](https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-mi…. Request URL : https://github.com/alsa-project/alsa-lib/pull/226 Patch URL : https://github.com/alsa-project/alsa-lib/pull/226.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0