Merge/sound upstream 20241009 #5204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[WHY & HOW] Some eDP panels suffer from flicking when HDR is enabled in KDE. This quirk works around it by skipping VSC that is incompatible with eDP panels. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3151 Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 4d42572) Cc: [email protected]
[Why] There are more IPS modes other than DMUB_IPS_ENABLE that enables IPS. We need to enable the hotplug detect idle workqueue for those modes as well. [How] Modify the if condition to initialize the workqueue in all IPS modes except for DMUB_IPS_DISABLE_ALL. Fixes: 6544458 ("drm/amd/display: Determine IPS mode by ASIC and PMFW versions") Signed-off-by: Leo Li <[email protected]> Reviewed-by: Roman Li <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 181db30) Cc: [email protected]
[Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Tom Chung <[email protected]> Signed-off-by: Fangzhi Zuo <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 453f86a) Cc: [email protected]
Merge series from Jinjie Ruan <[email protected]>: Fix pm_runtime_set_suspended() with runtime pm enabled, and fix the missing check for spi-cadence. Jinjie Ruan (3): spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled spi: spi-cadence: Fix missing spi_controller_is_target() check drivers/spi/spi-cadence.c | 8 +++++--- drivers/spi/spi-imx.c | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-) -- 2.34.1
Due to server permission control, the client does not have access to the shared root directory, but can access subdirectories normally, so users usually mount the shared subdirectories directly. In this case, queryfs should use the actual path instead of the root directory to avoid the call returning an error (EACCES). Signed-off-by: wangrong <[email protected]> Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Cc: [email protected] Signed-off-by: Steve French <[email protected]>
Declarations local to arch/*/kernel/*.c are better off *not* in a public header - arch/parisc/kernel/unaligned.h is just fine for those bits. With that done parisc asm/unaligned.h is reduced to include of asm-generic/unaligned.h and can be removed - unaligned.h is in mandatory-y in include/asm-generic/Kbuild. Acked-by: Helge Deller <[email protected]> Signed-off-by: Al Viro <[email protected]>
new_dir does *NOT* point into dir_folio - it's an inode, not a pointer to ufs directory entry. Fixes: 516b97c "ufs: Convert directory handling to kmap_local" Acked-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Al Viro <[email protected]>
Some time ago, we introduced the obey_preferred_dacs flag for choosing the DAC/pin pairs specified by the driver instead of parsing the paths. This works as expected, per se, but there have been a few cases where we forgot to set this flag while preferred_dacs table is already set up. It ended up with incorrect wiring and made us wondering why it doesn't work. Basically, when the preferred_dacs table is provided, it means that the driver really wants to wire up to follow that. That is, the presence of the preferred_dacs table itself is already a "do-it" flag. In this patch, we simply replace the evaluation of obey_preferred_dacs flag with the presence of preferred_dacs table for fixing the misbehavior. Another patch to drop of the obsoleted flag will follow. Fixes: 242d990 ("ALSA: hda/generic: Add option to enforce preferred_dacs pairs") Link: https://bugzilla.suse.com/show_bug.cgi?id=1219803 Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
Now we evaluate directly with preferred_dacs table, the flag is no longer used and merely a placeholder. Let's drop the definition and its users. Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
Add the quirk for HP Pavilion Gaming laptop 15z-ec200 for enabling the mute led. The fix apply the ALC285_FIXUP_HP_MUTE_LED quirk for this model. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219303 Signed-off-by: Abhishek Tamboli <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
If you enable "Option -> Show Debug Info" and click a link, the program
terminates with the following error:
*** buffer overflow detected ***: terminated
The buffer overflow is caused by the following line:
strcat(data, "$");
The buffer needs one more byte to accommodate the additional character.
Fixes: c4f7398 ("kconfig: qconf: make debug links work again")
Signed-off-by: Masahiro Yamada <[email protected]>
Since commit d29e741 ("gpio: davinci: drop platform data support"), irqchip is no longer being registered on platforms what don't use unbanked gpios. Fix this. Reported-by: Sabeeh Khan <[email protected]> Fixes: d29e741 ("gpio: davinci: drop platform data support") Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
As Jan suggested in links below, refactor udf_current_aext() to differentiate between error, hit EOF and success, it now takes pointer to etype to store the extent type, return 1 when getting etype success, return 0 when hitting EOF and return -errno when err. Link: https://lore.kernel.org/all/20240912111235.6nr3wuqvktecy3vh@quack3/ Signed-off-by: Zhao Mengmeng <[email protected]> Suggested-by: Jan Kara <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected]
When the trigger_tstamp_latched flag is set, the PCM core code assumes that the low-level driver handles the trigger timestamping itself. Ensure that runtime->trigger_tstamp is always updated. Buglink: alsa-project/alsa-lib#387 Reported-by: Zeno Endemann <[email protected]> Signed-off-by: Jaroslav Kysela <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
Since udf_current_aext() has error handling, udf_next_aext() should have error handling too. Besides, when too many indirect extents found in one inode, return -EFSCORRUPTED; when reading block failed, return -EIO. Signed-off-by: Zhao Mengmeng <[email protected]> Suggested-by: Jan Kara <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected]
Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=7a4842f0b1801230a989 Tested-by: [email protected] Signed-off-by: Zhao Mengmeng <[email protected]> Suggested-by: Jan Kara <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected]
Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df Tested-by: [email protected] Suggested-by: Jan Kara <[email protected]> Signed-off-by: Gianfranco Trad <[email protected]> Signed-off-by: Jan Kara <[email protected]> Link: https://patch.msgid.link/[email protected]
Add adsp-backed soundcard compatible for QRB4210 RB2 platform, which as of now looks fully compatible with SM8250. Signed-off-by: Alexey Klimov <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
Add "qcom,qrb4210-rb2-sndcard" to the list of recognizable devices. Signed-off-by: Alexey Klimov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
My understanding of the interrupts property is that it can either be: 1/ - TX 2/ - TX - RX 3/ - Common/combined. There are very little chances that either: - TX - Common/combined or even - TX - RX - Common/combined could be a thing. Looking at the interrupt-names definition (which uses oneOf instead of anyOf), it makes indeed little sense to use anyOf in the interrupts definition. I believe this is just a mistake, hence let's fix it. Fixes: 8be9064 ("ASoC: dt-bindings: davinci-mcasp: convert McASP bindings to yaml schema") Signed-off-by: Miquel Raynal <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
In most Linux distribution kernels, the SND is set to m, in such a case, when booting the kernel on i.MX8MP EVK board, there is a warning calltrace like below: Call trace: snd_card_init+0x484/0x4cc [snd] snd_card_new+0x70/0xa8 [snd] snd_soc_bind_card+0x310/0xbd0 [snd_soc_core] snd_soc_register_card+0xf0/0x108 [snd_soc_core] devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core] That is because the card.owner is not set, a warning calltrace is raised in the snd_card_init() due to it. Fixes: aa73670 ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Hui Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fixes: b359760 ("ASoC: intel: sof_sdw: Add simple DAI link creation helper") Signed-off-by: Charles Han <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
When i2s_irq_handler is called, it's guaranteed that adata is not NULL, since IRQ handlers are guaranteed to be provided with a valid data pointer. Moreover, adata pointer is being dereferenced right before the NULL check, which makes the check pointless, even if adata could be NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Murad Masimov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
…_object_watched() When __fsnotify_recalc_mask() recomputes the mask on the watched object, the compiler can "optimize" the code to perform partial updates to the mask (including zeroing it at the beginning). Thus places checking the object mask without conn->lock such as fsnotify_object_watched() could see invalid states of the mask. Make sure the mask update is performed by one memory store using WRITE_ONCE(). Reported-by: [email protected] Reported-by: Dmitry Vyukov <[email protected]> Link: https://lore.kernel.org/all/CACT4Y+Zk0ohwwwHSD63U2-PQ=UuamXczr1mKBD6xtj2dyYKBvA@mail.gmail.com Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Link: https://patch.msgid.link/[email protected]
[Syzbot reported]
WARNING: possible circular locking dependency detected
6.11.0-rc4-syzkaller-00019-gb311c1b497e5 #0 Not tainted
------------------------------------------------------
kswapd0/78 is trying to acquire lock:
ffff88801b8d8930 (&group->mark_mutex){+.+.}-{3:3}, at: fsnotify_group_lock include/linux/fsnotify_backend.h:270 [inline]
ffff88801b8d8930 (&group->mark_mutex){+.+.}-{3:3}, at: fsnotify_destroy_mark+0x38/0x3c0 fs/notify/mark.c:578
but task is already holding lock:
ffffffff8ea2fd60 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:6841 [inline]
ffffffff8ea2fd60 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0xbb4/0x35a0 mm/vmscan.c:7223
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
...
kmem_cache_alloc_noprof+0x3d/0x2a0 mm/slub.c:4044
inotify_new_watch fs/notify/inotify/inotify_user.c:599 [inline]
inotify_update_watch fs/notify/inotify/inotify_user.c:647 [inline]
__do_sys_inotify_add_watch fs/notify/inotify/inotify_user.c:786 [inline]
__se_sys_inotify_add_watch+0x72e/0x1070 fs/notify/inotify/inotify_user.c:729
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&group->mark_mutex){+.+.}-{3:3}:
...
__mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752
fsnotify_group_lock include/linux/fsnotify_backend.h:270 [inline]
fsnotify_destroy_mark+0x38/0x3c0 fs/notify/mark.c:578
fsnotify_destroy_marks+0x14a/0x660 fs/notify/mark.c:934
fsnotify_inoderemove include/linux/fsnotify.h:264 [inline]
dentry_unlink_inode+0x2e0/0x430 fs/dcache.c:403
__dentry_kill+0x20d/0x630 fs/dcache.c:610
shrink_kill+0xa9/0x2c0 fs/dcache.c:1055
shrink_dentry_list+0x2c0/0x5b0 fs/dcache.c:1082
prune_dcache_sb+0x10f/0x180 fs/dcache.c:1163
super_cache_scan+0x34f/0x4b0 fs/super.c:221
do_shrink_slab+0x701/0x1160 mm/shrinker.c:435
shrink_slab+0x1093/0x14d0 mm/shrinker.c:662
shrink_one+0x43b/0x850 mm/vmscan.c:4815
shrink_many mm/vmscan.c:4876 [inline]
lru_gen_shrink_node mm/vmscan.c:4954 [inline]
shrink_node+0x3799/0x3de0 mm/vmscan.c:5934
kswapd_shrink_node mm/vmscan.c:6762 [inline]
balance_pgdat mm/vmscan.c:6954 [inline]
kswapd+0x1bcd/0x35a0 mm/vmscan.c:7223
[Analysis]
The problem is that inotify_new_watch() is using GFP_KERNEL to allocate
new watches under group->mark_mutex, however if dentry reclaim races
with unlinking of an inode, it can end up dropping the last dentry reference
for an unlinked inode resulting in removal of fsnotify mark from reclaim
context which wants to acquire group->mark_mutex as well.
This scenario shows that all notification groups are in principle prone
to this kind of a deadlock (previously, we considered only fanotify and
dnotify to be problematic for other reasons) so make sure all
allocations under group->mark_mutex happen with GFP_NOFS.
Reported-and-tested-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=c679f13773f295d2da53
Signed-off-by: Lizhi Xu <[email protected]>
Reviewed-by: Amir Goldstein <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Link: https://patch.msgid.link/[email protected]
Fix the documentation to match the new function signature. Fixes: 76c313f ("blk-integrity: improved sg segment mapping") Signed-off-by: Keith Busch <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
These are called from blkcg_print_blkgs() which already disables IRQs so disabling it again is wrong. It means that IRQs will be enabled slightly earlier than intended, however, so far as I can see, this bug is harmless. Fixes: 35198e3 ("blk-iocost: read params inside lock in sysfs apis") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
For fixing CVE-2023-6270, f98364e ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue. Cc: [email protected] Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270 Fixes: f98364e ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") Reported-by: Nicolai Stange <[email protected]> Signed-off-by: Chun-Yi Lee <[email protected]> Link: https://lore.kernel.org/stable/20240624064418.27043-1-jlee%40suse.com Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
Commit 2fae6bb ("xen/privcmd: Add new syscall to get gsi from dev") adds a weak reverse dependency to the config XEN_PRIVCMD definition, referring to CONFIG_XEN_PCIDEV_BACKEND. In Kconfig files, one refers to config options without the CONFIG prefix, though. So in its current form, this does not create the reverse dependency as intended, but is an attribute with no effect. Refer to the intended config option XEN_PCIDEV_BACKEND in the XEN_PRIVCMD definition. Fixes: 2fae6bb ("xen/privcmd: Add new syscall to get gsi from dev") Signed-off-by: Lukas Bulwahn <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Message-ID: <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
This reverts commit e6a3531. The problem that the commit e6a3531 fixes was reported as a security bug, but Google engineers working on Android and ChromeOS didn't want to change the default behavior, they want to get -EIO rather than restarting the system, so I am reverting that commit. Note also that calling machine_restart from the I/O handling code is potentially unsafe (the reboot notifiers may wait for the bio that triggered the restart), but Android uses the reboot notifiers to store the reboot reason into the PMU microcontroller, so machine_restart must be used. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Fixes: e6a3531 ("dm-verity: restart or panic on an I/O error") Suggested-by: Sami Tolvanen <[email protected]> Suggested-by: Will Drewry <[email protected]>
bardliao
requested review from
lgirdwood,
plbossart,
ranj063 and
dbaluta
as code owners
|
@bardliao : could you please point me commits which you have resolved the merge conflicts? |
It is bardliao@2ffd47d. The conflict is in sound/soc/amd/acp/acp-sdw-sof-mach.c. |
vijendarmukunda
approved these changes
Oct 9, 2024
|
SOFCI TEST |
|
stable-2.2 has regression: and a new (for me) on LNL: |
|
@bardliao, what happens is: I don't see anything like this happening with other PRs... |
|
Logging the test result before re-triggering the test: 46626 |
|
SOFCI TEST |
|
@ujfalusi Is it possible to bisect it? Can the issue be reproduced with linux-next kernel? |
|
I think the i2c bus is not probing and thus the two chromebook is without audio card as the codec is not probed. |
I would go with mainline first, it should work fine on LNL... |
|
I checked the stable v2.2 issue on And that is due to an incorrect sof-cml.ri is used. The md5sum of the incorrect sof-cml.ri is dee17a3c329e560c08f104f0e35a59f6 which is updated on Oct 12th. Not sure what happened. After using the sof-cml.ri from jf-cml-hel-rt5682-01, the issue is gone. |
|
There is another issue on the stable-v2.2 test. I will look into it. |
You are right. There is no |
|
If I test with the https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, |
|
It is the |
|
@bardliao, the i2c issue will be fixed by: thesofproject/kconfig#101 |
Thanks @ujfalusi I just found the same. haha. |
|
SOFCI TEST |
|
Let's see with the updated sof-kconfig... |
|
Test result looks good to me. Let's merge. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@vijendarmukunda Could you double check the AMD part? I fixed some conflicts. Not sure if I did it right.