user/sven/linux.git, branch v6.1.77

Linux 6.1.77

2024-02-05T20:13:03Z

Link: https://lore.kernel.org/r/20240203035317.354186483@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Yann Sionneau Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20240203174756.358721205@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Yann Sionneau Tested-by: Linux Kernel Functional Testing Tested-by: Mateusz Jończyk Tested-by: Ron Economos Tested-by: kernelci.org bot Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'

2024-02-05T20:13:03Z

[ Upstream commit 16da399091dca3d1e48109086403587af37cc196 ] Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()' Fixes the below: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r' Fixes: fac4ebd79fed ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'") Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

ASoC: codecs: wsa883x: fix PA volume control

2024-02-05T20:13:03Z

commit b53cc6144a3f6c8b56afcdec89d81195c9b0dc69 upstream. The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is, in 15 levels. Fix the dB values for the PA volume control as experiments using wsa8835 show that the first 16 levels all map to the same lowest gain while the last three map to the highest gain. These values specifically need to be correct for the sound server to provide proper volume control. Note that level 0 (-3 dB) does not mute the PA so the mute flag should also not be set. Fixes: cdb09e623143 ("ASoC: codecs: wsa883x: add control, dapm widgets and map") Cc: stable@vger.kernel.org # 6.0 Cc: Srinivas Kandagatla Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ASoC: codecs: lpass-wsa-macro: fix compander volume hack

2024-02-05T20:13:03Z

commit 46188db080bd1df7d2d28031b89e56f2fdbabd67 upstream. The LPASS WSA macro codec driver is updating the digital gain settings behind the back of user space on DAPM events if companding has been enabled. As compander control is exported to user space, this can result in the digital gain setting being incremented (or decremented) every time the sound server is started and the codec suspended depending on what the UCM configuration looks like. Soon enough playback will become distorted (or too quiet). This is specifically a problem on the Lenovo ThinkPad X13s as this bypasses the limit for the digital gain setting that has been set by the machine driver. Fix this by simply dropping the compander gain offset hack. If someone cares about modelling the impact of the compander setting this can possibly be done by exporting it as a volume control later. Note that the volume registers still need to be written after enabling clocks in order for any prior updates to take effect. Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Cc: stable@vger.kernel.org # 5.11 Cc: Srinivas Kandagatla Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

bonding: remove print in bond_verify_device_path

2024-02-05T20:13:03Z

commit 486058f42a4728053ae69ebbf78e9731d8ce6f8b upstream. As suggested by Paolo in link[1], if the memory allocation fails, the mm layer will emit a lot warning comprising the backtrace, so remove the print. [1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/ Suggested-by: Paolo Abeni Signed-off-by: Zhengchao Shao Reviewed-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

gve: Fix use-after-free vulnerability

2024-02-05T20:13:02Z

From: Bailey Forrest Call skb_shinfo() after gve_prep_tso() on DQO TX path. gve_prep_tso() calls skb_cow_head(), which may reallocate shinfo causing a use after free. This bug was unintentionally fixed by 'a6fb8d5a8b69 ("gve: Tx path for DQO-QPL")' while adding DQO-QPL format support in 6.6. That patch is not appropriate for stable releases. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Praveen Kaligineedi Signed-off-by: Bailey Forrest Reviewed-by: Eric Dumazet Reviewed-by: Jeroen de Borst Reviewed-by: Kevin DeCabooter Signed-off-by: Greg Kroah-Hartman

LoongArch/smp: Call rcutree_report_cpu_starting() at tlb_init()

2024-02-05T20:13:02Z

commit 5056c596c3d1848021a4eaa76ee42f4c05c50346 upstream. Machines which have more than 8 nodes fail to boot SMP after commit a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier"). Because such machines use tlb-based per-cpu base address rather than dmw-based per-cpu base address, resulting per-cpu variables can only be accessed after tlb_init(). But rcutree_report_cpu_starting() is now called before tlb_init() and accesses per-cpu variables indeed. Since the original patch want to avoid the lockdep warning caused by page allocation in tlb_init(), we can move rcutree_report_cpu_starting() to tlb_init() where after tlb exception configuration but before page allocation. Fixes: a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier") Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman

drm/msm/dsi: Enable runtime PM

2024-02-05T20:13:02Z

commit 6ab502bc1cf3147ea1d8540d04b83a7a4cb6d1f1 upstream. Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/543352/ Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: Disable PSR-SU on Parade 0803 TCON again"

2024-02-05T20:13:02Z

This reverts commit 85d16c03ddd3f9b10212674e16ee8662b185bd14. duplicated a change made in 6.1.69 20907717918f0487258424631b704c7248a72da2 Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Jonathan Gray Signed-off-by: Greg Kroah-Hartman

mm, kmsan: fix infinite recursion due to RCU critical section

2024-02-05T20:13:02Z

commit f6564fce256a3944aa1bc76cb3c40e792d97c1eb upstream. Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1] Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com Fixes: 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") Signed-off-by: Marco Elver Reported-by: Alexander Potapenko Reported-by: syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com Reviewed-by: Alexander Potapenko Tested-by: Alexander Potapenko Cc: Charan Teja Kalla Cc: Borislav Petkov (AMD) Cc: Dave Hansen Cc: Dmitry Vyukov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman