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

[PATCH] ALSA: hda: update the power_state during the direct-complete
by Hui Wang 02 Jun '21

02 Jun '21

The patch_realtek.c needs to check if the power_state.event equals PM_EVENT_SUSPEND, after using the direct-complete, the suspend() and resume() will be skipped if the codec is already rt_suspended, in this case, the patch_realtek.c will always get PM_EVENT_ON even the system is really resumed from S3. We could set power_state to PMSG_SUSPEND in the prepare(), if other PM functions are called before complete(), those functions will override power_state; if no other PM functions are called before complete(), we could know the suspend() and resume() are skipped since only S3 pm functions could be skipped by direct-complete, in this case set power_state to PMSG_RESUME in the complete(). This could guarantee the first time of calling hda_codec_runtime_resume() after complete() has the correct power_state. Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete optimization") Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/hda_codec.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index a31009afc025..5462f771c2f9 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -2917,6 +2917,7 @@ static int hda_codec_runtime_resume(struct device *dev) #ifdef CONFIG_PM_SLEEP static int hda_codec_pm_prepare(struct device *dev) { + dev->power.power_state = PMSG_SUSPEND; return pm_runtime_suspended(dev); } @@ -2924,6 +2925,10 @@ static void hda_codec_pm_complete(struct device *dev) { struct hda_codec *codec = dev_to_hda_codec(dev); + /* If no other pm-functions are called between prepare() and complete() */ + if (dev->power.power_state.event == PM_EVENT_SUSPEND) + dev->power.power_state = PMSG_RESUME; + if (pm_runtime_suspended(dev) && (codec->jackpoll_interval || hda_codec_need_resume(codec) || codec->forced_resume)) pm_request_resume(dev); -- 2.25.1

2 1

[syzbot] UBSAN: shift-out-of-bounds in snd_timer_user_ccallback
by Dongliang Mu 02 Jun '21

02 Jun '21

> Hello, > > syzbot found the following issue on: > > HEAD commit: 5ff2756a Merge tag 'nfs-for-5.13-2' of git://git.linux-nfs.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=17872d5bd00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=770708ea7cfd4916 > dashboard link: https://syzkaller.appspot.com/bug?extid=d102fa5b35335a7e544e > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+d102fa...(a)syzkaller.appspotmail.com > > ================================================================================ > UBSAN: shift-out-of-bounds in sound/core/timer.c:1376:23 > shift exponent 105 is too large for 32-bit type 'int' > CPU: 1 PID: 10368 Comm: syz-executor.1 Not tainted 5.13.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 > __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 > snd_timer_user_ccallback.cold+0x19/0x1e sound/core/timer.c:1376 > > snd_timer_notify1+0x243/0x3b0 sound/core/timer.c:525 The root cause of this bug is in the snd_timer_notify1 [1]. At the end of this function, it calls "ts->ccallback(ts, event + 100, &tstamp, resolution)". Here the variable event is 5. It adds 100 and is passed as 2nd argument of snd_timer_user_ccallback. >From the variable naming, the 2nd argument should an event, and in the range of event enumeration. In fact, 105 (event + 100) is out of this range. I don't quite understand the meaning of adding 100. Any thought here? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sou… -- My best regards to you. No System Is Safe! Dongliang Mu

4 4

[PATCH RESEND] ALSA: timer: Fix master timer notification
by Takashi Iwai 02 Jun '21

02 Jun '21

snd_timer_notify1() calls the notification to each slave for a master event, but it passes a wrong event number. It should be +10 offset, corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with +100 offset. Casually this was spotted by UBSAN check via syzkaller. Reported-by: syzbot+d102fa5b35335a7e544e(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/timer.c b/sound/core/timer.c index 6898b1ac0d7f..92b7008fcdb8 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -520,9 +520,10 @@ static void snd_timer_notify1(struct snd_timer_instance *ti, int event) return; if (timer->hw.flags & SNDRV_TIMER_HW_SLAVE) return; + event += 10; /* convert to SNDRV_TIMER_EVENT_MXXX */ list_for_each_entry(ts, &ti->slave_active_head, active_list) if (ts->ccallback) - ts->ccallback(ts, event + 100, &tstamp, resolution); + ts->ccallback(ts, event, &tstamp, resolution); } /* start/continue a master timer */ -- 2.26.2

1 0

[PATCH][next] ASoC: rk817: remove redundant assignment to pointer node
by Colin King 02 Jun '21

02 Jun '21

From: Colin Ian King <colin.king(a)canonical.com> The pointer node is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/codecs/rk817_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rk817_codec.c b/sound/soc/codecs/rk817_codec.c index 17e672b85ee5..0d7cc26ded57 100644 --- a/sound/soc/codecs/rk817_codec.c +++ b/sound/soc/codecs/rk817_codec.c @@ -457,7 +457,7 @@ static const struct snd_soc_component_driver soc_codec_dev_rk817 = { static void rk817_codec_parse_dt_property(struct device *dev, struct rk817_codec_priv *rk817) { - struct device_node *node = dev->parent->of_node; + struct device_node *node; node = of_get_child_by_name(dev->parent->of_node, "codec"); if (!node) { -- 2.31.1

3 2

no sound via HDMI
by reinerschrutz＠web.de 02 Jun '21

02 Jun '21

Hi, missing sound via monitor and HDMI cable following ubuntuusers "HDA" article I found: 0[generic ] - HD-Audio Generic HD-Audio Generic at 0xfcc 88000 irg 62 1[generic_1 ] - HD-Audio Generic HD-Audio Generic at 0xfcc 88000 irq 63 looking for a pci device I found: 05:00.1 Audio device Advanced Micro Devices, Inc. [AMD/ATI] Device 1637 05:00.6 Audio device Advanced Mirco Devices, Inc. [AMD] Family 17h (Models 10h 1fh) HD Audio Controller Codec found: ATI R6xx HDMI My system: Asus Prime A520M-K, AMD Ryzen 7 Pro 4750G, 8x 3,6 GHz, 16 GD DDR4 RAM, 500 GB Samsung 870 EVO Advanced Linux Sound Architecture - Driver Cofiguration Guide said to give notice. Thanks. Stefan Ocken

1 0

[PATCH] ASoC: rk817: fix a warning in rk817_probe()
by Chris Morgan 02 Jun '21

02 Jun '21

From: Chris Morgan <macromorgan(a)hotmail.com> The return value of snd_soc_component_write() is stored but not evaluated and this results in a warning when W=1 is set. Stop storing the return value to be consistent with all other calls of snd_soc_component_write() and to remove the warning. Fixes: 0d6a04da9b25 ("ASoC: Add Rockchip rk817 audio CODEC support") Signed-off-by: Chris Morgan <macromorgan(a)hotmail.com> --- sound/soc/codecs/rk817_codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/codecs/rk817_codec.c b/sound/soc/codecs/rk817_codec.c index 17e672b85ee5..fd3a5ba034a9 100644 --- a/sound/soc/codecs/rk817_codec.c +++ b/sound/soc/codecs/rk817_codec.c @@ -415,12 +415,11 @@ static int rk817_probe(struct snd_soc_component *component) { struct rk817_codec_priv *rk817 = snd_soc_component_get_drvdata(component); struct rk808 *rk808 = dev_get_drvdata(component->dev->parent); - int ret; snd_soc_component_init_regmap(component, rk808->regmap); rk817->component = component; - ret = snd_soc_component_write(component, RK817_CODEC_DTOP_LPT_SRST, 0x40); + snd_soc_component_write(component, RK817_CODEC_DTOP_LPT_SRST, 0x40); rk817_init(component); -- 2.25.1

2 1

[PATCH 0/3] ALSA: firewire-motu: media clock recovery for sph-aware devices
by Takashi Sakamoto 02 Jun '21

02 Jun '21

Hi, In a commit f9e5ecdfc2c2 ("ALSA: firewire-lib: add replay target to cache sequence of packet"), I categorize devices supported by drivers in ALSA firewire stack in terms of the way to deliver effective sampling transfer frequency. This patchset is for the devices in group 3. The devices are known to have problems when ALSA firewire-motu driver handles. Many of them generate sound with noise. In the worst case, it generates no sound. The devices interpret presentation time to decide playback timing. Unlike the syt-aware devices, the devices interpret the presentation time in source packet header (SPH) per data block, instead of the presentation time in syt field of CIP header. Current implementation of the driver processes the sequence of outgoing packet by computation according to nominal sampling transfer frequency. However, the ideal sequence is not adequate to the devices, actually. With this patchset, the drivers are going to replay the sequence of incoming packets for media clock recovery, instead of nominal sampling transfer frequency. For the detail of sequence replay, please refer to a commit 39c2649c71d8 ("ALSA: firewire-lib: replay sequence of incoming packets for outgoing packets"). The sequence replay is done by two levels; the sequence of the number of data blocks per packet, and the sequence of SPH per data blocks in the packet. Takashi Sakamoto (3): ALSA: firewire-motu: use macro for magic numbers relevant to IEC 61883-1 ALSA: firewire-motu: cache event ticks in source packet header per data block ALSA: firewire-motu: sequence replay for source packet header sound/firewire/motu/amdtp-motu.c | 136 +++++++++++++++--------------- sound/firewire/motu/motu-stream.c | 27 +++++- sound/firewire/motu/motu.h | 14 ++- 3 files changed, 104 insertions(+), 73 deletions(-) -- 2.27.0

2 4

[PATCH v2] ALSA: control led: fix memory leak in snd_ctl_led_register
by Dongliang Mu 02 Jun '21

02 Jun '21

The snd_ctl_led_sysfs_add and snd_ctl_led_sysfs_remove should contain the refcount operations in pair. However, snd_ctl_led_sysfs_remove fails to decrease the refcount to zero, which causes device_release never to be invoked. This leads to memory leak to some resources, like struct device_private. In addition, we also free some other similar memory leaks in snd_ctl_led_init/snd_ctl_led_exit. Fix this by replacing device_del to device_unregister in snd_ctl_led_sysfs_remove/snd_ctl_led_init/snd_ctl_led_exit. Note that, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device will call kobject_release and delay the release of kobject, which will cause use-after-free when the memory backing the kobject is freed at once. Reported-by: syzbot+08a7d8b51ea048a74ffb(a)syzkaller.appspotmail.com Fixes: a135dfb5de1 ("ALSA: led control - add sysfs kcontrol LED marking layer") Signed-off-by: Dongliang Mu <mudongliangabcd(a)gmail.com> --- v1->v2: fix other similar memory leaks; move kfree(led_card) to a release function. sound/core/control_led.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/sound/core/control_led.c b/sound/core/control_led.c index 25f57c14f294..a90e31dbde61 100644 --- a/sound/core/control_led.c +++ b/sound/core/control_led.c @@ -17,6 +17,9 @@ MODULE_LICENSE("GPL"); #define MAX_LED (((SNDRV_CTL_ELEM_ACCESS_MIC_LED - SNDRV_CTL_ELEM_ACCESS_SPK_LED) \ >> SNDRV_CTL_ELEM_ACCESS_LED_SHIFT) + 1) +#define to_led_card_dev(_dev) \ + container_of(_dev, struct snd_ctl_led_card, dev) + enum snd_ctl_led_mode { MODE_FOLLOW_MUTE = 0, MODE_FOLLOW_ROUTE, @@ -371,6 +374,21 @@ static void snd_ctl_led_disconnect(struct snd_card *card) snd_ctl_led_refresh(); } +static void snd_ctl_led_card_release(struct device *dev) +{ + struct snd_ctl_led_card *led_card = to_led_card_dev(dev); + + kfree(led_card); +} + +static void snd_ctl_led_release(struct device *dev) +{ +} + +static void snd_ctl_led_dev_release(struct device *dev) +{ +} + /* * sysfs */ @@ -663,6 +681,7 @@ static void snd_ctl_led_sysfs_add(struct snd_card *card) led_card->number = card->number; led_card->led = led; device_initialize(&led_card->dev); + led_card->dev.release = snd_ctl_led_card_release; if (dev_set_name(&led_card->dev, "card%d", card->number) < 0) goto cerr; led_card->dev.parent = &led->dev; @@ -681,7 +700,6 @@ static void snd_ctl_led_sysfs_add(struct snd_card *card) put_device(&led_card->dev); cerr2: printk(KERN_ERR "snd_ctl_led: unable to add card%d", card->number); - kfree(led_card); } } @@ -700,8 +718,7 @@ static void snd_ctl_led_sysfs_remove(struct snd_card *card) snprintf(link_name, sizeof(link_name), "led-%s", led->name); sysfs_remove_link(&card->ctl_dev.kobj, link_name); sysfs_remove_link(&led_card->dev.kobj, "card"); - device_del(&led_card->dev); - kfree(led_card); + device_unregister(&led_card->dev); led->cards[card->number] = NULL; } } @@ -723,6 +740,7 @@ static int __init snd_ctl_led_init(void) device_initialize(&snd_ctl_led_dev); snd_ctl_led_dev.class = sound_class; + snd_ctl_led_dev.release = snd_ctl_led_dev_release; dev_set_name(&snd_ctl_led_dev, "ctl-led"); if (device_add(&snd_ctl_led_dev)) { put_device(&snd_ctl_led_dev); @@ -733,15 +751,16 @@ static int __init snd_ctl_led_init(void) INIT_LIST_HEAD(&led->controls); device_initialize(&led->dev); led->dev.parent = &snd_ctl_led_dev; + led->dev.release = snd_ctl_led_release; led->dev.groups = snd_ctl_led_dev_attr_groups; dev_set_name(&led->dev, led->name); if (device_add(&led->dev)) { put_device(&led->dev); for (; group > 0; group--) { led = &snd_ctl_leds[group - 1]; - device_del(&led->dev); + device_unregister(&led->dev); } - device_del(&snd_ctl_led_dev); + device_unregister(&snd_ctl_led_dev); return -ENOMEM; } } @@ -767,9 +786,9 @@ static void __exit snd_ctl_led_exit(void) } for (group = 0; group < MAX_LED; group++) { led = &snd_ctl_leds[group]; - device_del(&led->dev); + device_unregister(&led->dev); } - device_del(&snd_ctl_led_dev); + device_unregister(&snd_ctl_led_dev); snd_ctl_led_clean(NULL); } -- 2.25.1

4 3

bytcr-rt5640 initiializes but has wrong settings
by GitHub issues - opened 02 Jun '21

02 Jun '21

alsa-project/alsa-ucm-conf issue #96 was opened from AnterCreeper: My device is Elitepad 1000 G2. The headphone and the mic inside cannot work. However, The speaker works properly. The mic IN1 is the headphone mic insted of the mic inside. I think that it may be because the audio was ported to the wrong place. Sorry for my bad English :D Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/96 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[syzbot] UBSAN: shift-out-of-bounds in snd_timer_user_ccallback
by syzbot 02 Jun '21

02 Jun '21

Hello, syzbot found the following issue on: HEAD commit: 5ff2756a Merge tag 'nfs-for-5.13-2' of git://git.linux-nfs.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17872d5bd00000 kernel config: https://syzkaller.appspot.com/x/.config?x=770708ea7cfd4916 dashboard link: https://syzkaller.appspot.com/bug?extid=d102fa5b35335a7e544e Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d102fa5b35335a7e544e(a)syzkaller.appspotmail.com ================================================================================ UBSAN: shift-out-of-bounds in sound/core/timer.c:1376:23 shift exponent 105 is too large for 32-bit type 'int' CPU: 1 PID: 10368 Comm: syz-executor.1 Not tainted 5.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 snd_timer_user_ccallback.cold+0x19/0x1e sound/core/timer.c:1376 snd_timer_notify1+0x243/0x3b0 sound/core/timer.c:525 snd_timer_stop1+0x641/0x890 sound/core/timer.c:656 snd_timer_pause+0x6e/0x90 sound/core/timer.c:738 seq_timer_stop sound/core/seq/seq_timer.c:331 [inline] snd_seq_timer_stop+0x93/0xd0 sound/core/seq/seq_timer.c:341 queue_delete+0x42/0xa0 sound/core/seq/seq_queue.c:133 snd_seq_queue_client_leave+0x37/0x1a0 sound/core/seq/seq_queue.c:552 seq_free_client1.part.0+0x10a/0x260 sound/core/seq/seq_clientmgr.c:280 seq_free_client1 sound/core/seq/seq_clientmgr.c:273 [inline] seq_free_client+0x7b/0xf0 sound/core/seq/seq_clientmgr.c:301 snd_seq_release+0x4d/0xe0 sound/core/seq/seq_clientmgr.c:382 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x272/0x280 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:301 do_syscall_64+0x47/0xb0 arch/x86/entry/common.c:57 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4193eb Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44 RSP: 002b:0000000000a9fb80 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00000000004193eb RDX: 0000000000571b58 RSI: ffffffff89166efe RDI: 0000000000000004 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000001b2ea280a8 R10: 00000000000001d1 R11: 0000000000000293 R12: 000000000014d248 R13: 00000000000003e8 R14: 000000000056bf80 R15: 000000000014d1dd ================================================================================ --- 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.

1 0