April 2025 - Linux-stable-mirror

+ tools-testing-selftests-fix-guard-region-test-tmpfs-assumption.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: tools/testing/selftests: fix guard region test tmpfs assumption has been added to the -mm mm-hotfixes-unstable branch. Its filename is tools-testing-selftests-fix-guard-region-test-tmpfs-assumption.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: tools/testing/selftests: fix guard region test tmpfs assumption Date: Fri, 25 Apr 2025 17:24:36 +0100 The current implementation of the guard region tests assume that /tmp is mounted as tmpfs, that is shmem. This isn't always the case, and at least one instance of a spurious test failure has been reported as a result. This assumption is unsafe, rushed and silly - and easily remedied by simply using memfd, so do so. We also have to fixup the readonly_file test to explicitly only be applicable to file-backed cases. Link: https://lkml.kernel.org/r/20250425162436.564002-1-lorenzo.stoakes@oracle.com Fixes: 272f37d3e99a ("tools/selftests: expand all guard region tests to file-backed") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reported-by: Ryan Roberts <ryan.roberts(a)arm.com> Closes: https://lore.kernel.org/linux-mm/a2d2766b-0ab4-437b-951a-8595a7506fe9@arm.c… Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/guard-regions.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/mm/guard-regions.c~tools-testing-selftests-fix-guard-region-test-tmpfs-assumption +++ a/tools/testing/selftests/mm/guard-regions.c @@ -271,12 +271,16 @@ FIXTURE_SETUP(guard_regions) self->page_size = (unsigned long)sysconf(_SC_PAGESIZE); setup_sighandler(); - if (variant->backing == ANON_BACKED) + switch (variant->backing) { + case ANON_BACKED: return; - - self->fd = open_file( - variant->backing == SHMEM_BACKED ? "/tmp/" : "", - self->path); + case LOCAL_FILE_BACKED: + self->fd = open_file("", self->path); + break; + case SHMEM_BACKED: + self->fd = memfd_create(self->path, 0); + break; + } /* We truncate file to at least 100 pages, tests can modify as needed. */ ASSERT_EQ(ftruncate(self->fd, 100 * self->page_size), 0); @@ -1696,7 +1700,7 @@ TEST_F(guard_regions, readonly_file) char *ptr; int i; - if (variant->backing == ANON_BACKED) + if (variant->backing != LOCAL_FILE_BACKED) SKIP(return, "Read-only test specific to file-backed"); /* Map shared so we can populate with pattern, populate it, unmap. */ _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are maintainers-add-reverse-mapping-section.patch maintainers-add-core-mm-section.patch maintainers-add-mm-thp-section.patch maintainers-add-mm-thp-section-fix.patch tools-testing-selftests-fix-guard-region-test-tmpfs-assumption.patch mm-vma-fix-incorrectly-disallowed-anonymous-vma-merges.patch tools-testing-add-procmap_query-helper-functions-in-mm-self-tests.patch tools-testing-selftests-assert-that-anon-merge-cases-behave-as-expected.patch mm-move-mmap-vma-locking-logic-into-specific-files.patch

2 months

1
0
0 0

[PATCH v3] KVM: SVM: forcibly leave SMM mode on vCPU reset

by Mikhail Lobanov

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM). This omission results in triggering a WARN when a vCPU reset occurs while still in SMM mode, due to the check in kvm_vcpu_reset(). This situation was reprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault The issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Architecturally, hardware CPUs exit SMM upon receiving a triple fault as part of a hardware reset. To reflect this behavior and avoid triggering the WARN, this patch explicitly calls kvm_smm_changed(vcpu, false) in the SVM-specific shutdown_interception() handler prior to resetting the vCPU. The initial version of this patch attempted to address the issue by calling kvm_smm_changed() inside kvm_vcpu_reset(). However, this approach was not architecturally accurate, as INIT is blocked during SMM and SMM should not be exited implicitly during a generic vCPU reset. This version moves the fix into shutdown_interception() for SVM, where the triple fault is actually handled, and where exiting SMM explicitly is appropriate. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") Cc: stable(a)vger.kernel.org Suggested-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Mikhail Lobanov <m.lobanov(a)rosa.ru> --- v2: Move SMM exit from kvm_vcpu_reset() to SVM's shutdown_interception(), per suggestion from Sean Christopherson <seanjc(a)google.com>. v3: -Export kvm_smm_changed() using EXPORT_SYMBOL_GPL. -Wrap the call to kvm_smm_changed() in svm.c with #ifdef CONFIG_KVM_SMM to avoid build errors when SMM support is disabled. arch/x86/kvm/smm.c | 1 + arch/x86/kvm/svm/svm.c | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/arch/x86/kvm/smm.c b/arch/x86/kvm/smm.c index 699e551ec93b..9864c057187d 100644 --- a/arch/x86/kvm/smm.c +++ b/arch/x86/kvm/smm.c @@ -131,6 +131,7 @@ void kvm_smm_changed(struct kvm_vcpu *vcpu, bool entering_smm) kvm_mmu_reset_context(vcpu); } +EXPORT_SYMBOL_GPL(kvm_smm_changed); void process_smi(struct kvm_vcpu *vcpu) { diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index d5d0c5c3300b..c5470d842aed 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2231,6 +2231,10 @@ static int shutdown_interception(struct kvm_vcpu *vcpu) */ if (!sev_es_guest(vcpu->kvm)) { clear_page(svm->vmcb); +#ifdef CONFIG_KVM_SMM + if (is_smm(vcpu)) + kvm_smm_changed(vcpu, false); +#endif kvm_vcpu_reset(vcpu, true); } -- 2.47.2

2 months

2
1
0 0

[PATCH] arm64: dts: ti: k3-j784s4-j742s2-main-common: fix length of serdes_ln_ctrl

by Siddharth Vadapalli

Commit under Fixes corrected the "mux-reg-masks" property but did not update the "length" field of the "reg" property to account for the newly added register offsets which extend the region. Fix this. Fixes: 38e7f9092efb ("arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix serdes_ln_ctrl reg-masks") Cc: stable(a)vger.kernel.org Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Hello, This patch is based on commit bc3372351d0c Merge tag 'for-6.15-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux of Mainline Linux. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi index 1944616ab357..1fc0a11c5ab4 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi @@ -77,7 +77,7 @@ pcie1_ctrl: pcie1-ctrl@4074 { serdes_ln_ctrl: mux-controller@4080 { compatible = "reg-mux"; - reg = <0x00004080 0x30>; + reg = <0x00004080 0x50>; #mux-control-cells = <1>; mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ -- 2.34.1

2 months

3
2
0 0

[PATCH 1/2] mm/userfaultfd: Fix uninitialized output field for -EAGAIN race

by Peter Xu

While discussing some userfaultfd relevant issues recently, Andrea noticed a potential ABI breakage with -EAGAIN on almost all userfaultfd ioctl()s. Quote from Andrea, explaining how -EAGAIN was processed, and how this should fix it (taking example of UFFDIO_COPY ioctl): The "mmap_changing" and "stale pmd" conditions are already reported as -EAGAIN written in the copy field, this does not change it. This change removes the subnormal case that left copy.copy uninitialized and required apps to explicitly set the copy field to get deterministic behavior (which is a requirement contrary to the documentation in both the manpage and source code). In turn there's no alteration to backwards compatibility as result of this change because userland will find the copy field consistently set to -EAGAIN, and not anymore sometime -EAGAIN and sometime uninitialized. Even then the change only can make a difference to non cooperative users of userfaultfd, so when UFFD_FEATURE_EVENT_* is enabled, which is not true for the vast majority of apps using userfaultfd or this unintended uninitialized field may have been noticed sooner. Meanwhile, since this bug existed for years, it also almost affects all ioctl()s that was introduced later. Besides UFFDIO_ZEROPAGE, these also get affected in the same way: - UFFDIO_CONTINUE - UFFDIO_POISON - UFFDIO_MOVE This patch should have fixed all of them. Fixes: df2cc96e7701 ("userfaultfd: prevent non-cooperative events vs mcopy_atomic races") Fixes: f619147104c8 ("userfaultfd: add UFFDIO_CONTINUE ioctl") Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl") Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Cc: linux-stable <stable(a)vger.kernel.org> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Reported-by: Andrea Arcangeli <aarcange(a)redhat.com> Suggested-by: Andrea Arcangeli <aarcange(a)redhat.com> Signed-off-by: Peter Xu <peterx(a)redhat.com> --- fs/userfaultfd.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index d80f94346199..22f4bf956ba1 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1585,8 +1585,11 @@ static int userfaultfd_copy(struct userfaultfd_ctx *ctx, user_uffdio_copy = (struct uffdio_copy __user *) arg; ret = -EAGAIN; - if (atomic_read(&ctx->mmap_changing)) + if (unlikely(atomic_read(&ctx->mmap_changing))) { + if (unlikely(put_user(ret, &user_uffdio_copy->copy))) + return -EFAULT; goto out; + } ret = -EFAULT; if (copy_from_user(&uffdio_copy, user_uffdio_copy, @@ -1641,8 +1644,11 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx, user_uffdio_zeropage = (struct uffdio_zeropage __user *) arg; ret = -EAGAIN; - if (atomic_read(&ctx->mmap_changing)) + if (unlikely(atomic_read(&ctx->mmap_changing))) { + if (unlikely(put_user(ret, &user_uffdio_zeropage->zeropage))) + return -EFAULT; goto out; + } ret = -EFAULT; if (copy_from_user(&uffdio_zeropage, user_uffdio_zeropage, @@ -1744,8 +1750,11 @@ static int userfaultfd_continue(struct userfaultfd_ctx *ctx, unsigned long arg) user_uffdio_continue = (struct uffdio_continue __user *)arg; ret = -EAGAIN; - if (atomic_read(&ctx->mmap_changing)) + if (unlikely(atomic_read(&ctx->mmap_changing))) { + if (unlikely(put_user(ret, &user_uffdio_continue->mapped))) + return -EFAULT; goto out; + } ret = -EFAULT; if (copy_from_user(&uffdio_continue, user_uffdio_continue, @@ -1801,8 +1810,11 @@ static inline int userfaultfd_poison(struct userfaultfd_ctx *ctx, unsigned long user_uffdio_poison = (struct uffdio_poison __user *)arg; ret = -EAGAIN; - if (atomic_read(&ctx->mmap_changing)) + if (unlikely(atomic_read(&ctx->mmap_changing))) { + if (unlikely(put_user(ret, &user_uffdio_poison->updated))) + return -EFAULT; goto out; + } ret = -EFAULT; if (copy_from_user(&uffdio_poison, user_uffdio_poison, @@ -1870,8 +1882,12 @@ static int userfaultfd_move(struct userfaultfd_ctx *ctx, user_uffdio_move = (struct uffdio_move __user *) arg; - if (atomic_read(&ctx->mmap_changing)) - return -EAGAIN; + ret = -EAGAIN; + if (unlikely(atomic_read(&ctx->mmap_changing))) { + if (unlikely(put_user(ret, &user_uffdio_move->move))) + return -EFAULT; + goto out; + } if (copy_from_user(&uffdio_move, user_uffdio_move, /* don't copy "move" last field */ -- 2.48.1

2 months

3
3
0 0

Potential Linux Crash: possible deadlock in udf_page_mkwrite in linux6.12.24(longterm maintenance)

by Jianzhou Zhao

Hello, I found a potential bug titled " possible deadlock in udf_page_mkwrite " with modified syzkaller in the Linux6.12.24(longterm maintenance, last updated on April 20, 2025). Unfortunately, I am unable to reproduce this bug. If you fix this issue, please add the following tag to the commit: Reported-by: Jianzhou Zhao <luckd0g(a)163.com>, xingwei lee <xrivendell7(a)gmail.com>,Penglei Jiang <superman.xpt(a)gmail.com> The commit of the kernel is : b6efa8ce222e58cfe2bbaa4e3329818c2b4bd74e kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=55f8591b98dd132 compiler: gcc version 11.4.0 ------------[ cut here ]----------------------------------------- TITLE: possible deadlock in udf_page_mkwrite ------------[ cut here ]------------ ====================================================== WARNING: possible circular locking dependency detected 6.12.24 #3 Not tainted ------------------------------------------------------ syz.6.870/18445 is trying to acquire lock: ffff888053607700 (mapping.invalidate_lock#4){++++}-{3:3}, at: filemap_invalidate_lock_shared include/linux/fs.h:870 [inline] ffff888053607700 (mapping.invalidate_lock#4){++++}-{3:3}, at: udf_page_mkwrite+0x2af/0xa20 fs/udf/file.c:50 but task is already holding lock: ffff888044124518 (sb_pagefaults#2){.+.+}-{0:0}, at: do_page_mkwrite+0x17d/0x390 mm/memory.c:3161 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #9 (sb_pagefaults#2){.+.+}-{0:0}: percpu_down_read include/linux/percpu-rwsem.h:51 [inline] __sb_start_write include/linux/fs.h:1716 [inline] sb_start_pagefault include/linux/fs.h:1881 [inline] udf_page_mkwrite+0x18b/0xa20 fs/udf/file.c:48 do_page_mkwrite+0x17d/0x390 mm/memory.c:3161 wp_page_shared mm/memory.c:3562 [inline] do_wp_page+0x1291/0x4860 mm/memory.c:3712 handle_pte_fault mm/memory.c:5786 [inline] __handle_mm_fault+0x150c/0x2a20 mm/memory.c:5913 handle_mm_fault+0x404/0xab0 mm/memory.c:6081 do_user_addr_fault+0x61b/0x13a0 arch/x86/mm/fault.c:1338 handle_page_fault arch/x86/mm/fault.c:1481 [inline] exc_page_fault+0x98/0x180 arch/x86/mm/fault.c:1539 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 -> #8 (&vma->vm_lock->lock){++++}-{3:3}: down_write+0x92/0x200 kernel/locking/rwsem.c:1577 vma_start_write include/linux/mm.h:757 [inline] vma_link+0x268/0x490 mm/vma.c:1604 insert_vm_struct+0x197/0x3f0 mm/mmap.c:2011 __bprm_mm_init fs/exec.c:289 [inline] bprm_mm_init fs/exec.c:393 [inline] alloc_bprm+0x6d1/0xd30 fs/exec.c:1578 kernel_execve+0xb0/0x3d0 fs/exec.c:2010 try_to_run_init_process init/main.c:1397 [inline] kernel_init+0x154/0x2d0 init/main.c:1525 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #7 (&mm->mmap_lock){++++}-{3:3}: __might_fault mm/memory.c:6719 [inline] __might_fault+0x118/0x190 mm/memory.c:6713 _inline_copy_from_user include/linux/uaccess.h:162 [inline] _copy_from_user+0x2b/0xd0 lib/usercopy.c:18 copy_from_user include/linux/uaccess.h:212 [inline] __blk_trace_setup+0x96/0x180 kernel/trace/blktrace.c:626 blk_trace_setup+0x47/0x70 kernel/trace/blktrace.c:648 sg_ioctl_common drivers/scsi/sg.c:1114 [inline] sg_ioctl+0x65e/0x2720 drivers/scsi/sg.c:1156 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x19d/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #6 (&q->debugfs_mutex){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x147/0x930 kernel/locking/mutex.c:752 blk_mq_init_sched+0x436/0x650 block/blk-mq-sched.c:473 elevator_init_mq+0x2cc/0x420 block/elevator.c:610 device_add_disk+0x10e/0x12f0 block/genhd.c:411 sd_probe+0xa0e/0xf80 drivers/scsi/sd.c:4024 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x24f/0xa90 drivers/base/dd.c:658 __driver_probe_device+0x1df/0x450 drivers/base/dd.c:800 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:830 __device_attach_driver+0x1db/0x2f0 drivers/base/dd.c:958 bus_for_each_drv+0x149/0x1d0 drivers/base/bus.c:459 __device_attach_async_helper+0x1d1/0x290 drivers/base/dd.c:987 async_run_entry_fn+0x9c/0x530 kernel/async.c:129 process_one_work+0xa02/0x1bf0 kernel/workqueue.c:3232 process_scheduled_works kernel/workqueue.c:3314 [inline] worker_thread+0x677/0xe90 kernel/workqueue.c:3395 kthread+0x2c7/0x3b0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #5 (&q->q_usage_counter(queue)#51){++++}-{0:0}: blk_queue_enter+0x4d0/0x600 block/blk-core.c:328 blk_mq_alloc_request+0x422/0x9c0 block/blk-mq.c:680 scsi_alloc_request drivers/scsi/scsi_lib.c:1227 [inline] scsi_execute_cmd+0x1fe/0xf20 drivers/scsi/scsi_lib.c:304 read_capacity_16+0x1f2/0xe60 drivers/scsi/sd.c:2655 sd_read_capacity drivers/scsi/sd.c:2824 [inline] sd_revalidate_disk.isra.0+0x1989/0xa440 drivers/scsi/sd.c:3734 sd_probe+0x887/0xf80 drivers/scsi/sd.c:4010 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x24f/0xa90 drivers/base/dd.c:658 __driver_probe_device+0x1df/0x450 drivers/base/dd.c:800 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:830 __device_attach_driver+0x1db/0x2f0 drivers/base/dd.c:958 bus_for_each_drv+0x149/0x1d0 drivers/base/bus.c:459 __device_attach_async_helper+0x1d1/0x290 drivers/base/dd.c:987 async_run_entry_fn+0x9c/0x530 kernel/async.c:129 process_one_work+0xa02/0x1bf0 kernel/workqueue.c:3232 process_scheduled_works kernel/workqueue.c:3314 [inline] worker_thread+0x677/0xe90 kernel/workqueue.c:3395 kthread+0x2c7/0x3b0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #4 (&q->limits_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x147/0x930 kernel/locking/mutex.c:752 queue_limits_start_update include/linux/blkdev.h:935 [inline] loop_reconfigure_limits+0x1f2/0x960 drivers/block/loop.c:1004 loop_set_block_size drivers/block/loop.c:1474 [inline] lo_simple_ioctl drivers/block/loop.c:1497 [inline] lo_ioctl+0xb92/0x1870 drivers/block/loop.c:1560 blkdev_ioctl+0x27b/0x6c0 block/ioctl.c:693 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x19d/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #3 (&q->q_usage_counter(io)#19){++++}-{0:0}: bio_queue_enter block/blk.h:76 [inline] blk_mq_submit_bio+0x2167/0x2b70 block/blk-mq.c:3090 __submit_bio+0x399/0x630 block/blk-core.c:629 __submit_bio_noacct_mq block/blk-core.c:716 [inline] submit_bio_noacct_nocheck+0x6c3/0xd00 block/blk-core.c:745 submit_bio_noacct+0x57a/0x1fa0 block/blk-core.c:868 submit_bh fs/buffer.c:2824 [inline] __bread_slow fs/buffer.c:1270 [inline] __bread_gfp+0x189/0x340 fs/buffer.c:1494 sb_bread include/linux/buffer_head.h:346 [inline] read_block_bitmap fs/udf/balloc.c:43 [inline] load_block_bitmap+0x1ff/0x570 fs/udf/balloc.c:99 udf_bitmap_free_blocks fs/udf/balloc.c:150 [inline] udf_free_blocks+0x57c/0x10a0 fs/udf/balloc.c:674 udf_evict_inode+0x34c/0x590 fs/udf/inode.c:163 evict+0x3ef/0x940 fs/inode.c:725 iput_final fs/inode.c:1877 [inline] iput fs/inode.c:1903 [inline] iput+0x511/0x7f0 fs/inode.c:1889 do_unlinkat+0x58f/0x710 fs/namei.c:4540 __do_sys_unlink fs/namei.c:4581 [inline] __se_sys_unlink fs/namei.c:4579 [inline] __x64_sys_unlink+0xc7/0x110 fs/namei.c:4579 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #2 (&sbi->s_alloc_mutex){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x147/0x930 kernel/locking/mutex.c:752 udf_bitmap_new_block fs/udf/balloc.c:236 [inline] udf_new_block+0x7e2/0x1750 fs/udf/balloc.c:721 inode_getblk+0xe88/0x3bb0 fs/udf/inode.c:895 udf_map_block+0x2e3/0x5a0 fs/udf/inode.c:447 __udf_get_block+0x9c/0x340 fs/udf/inode.c:461 __block_write_begin_int+0x4e5/0x1670 fs/buffer.c:2121 block_write_begin+0x9a/0x1d0 fs/buffer.c:2231 udf_write_begin+0x1bc/0x280 fs/udf/inode.c:256 generic_perform_write+0x2bd/0x900 mm/filemap.c:4065 __generic_file_write_iter+0x1f6/0x240 mm/filemap.c:4166 udf_file_write_iter+0x233/0x740 fs/udf/file.c:111 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xbfc/0x10d0 fs/read_write.c:683 ksys_write+0x122/0x250 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 (&ei->i_data_sem#2){++++}-{3:3}: down_write+0x92/0x200 kernel/locking/rwsem.c:1577 udf_expand_file_adinicb+0x174/0x970 fs/udf/inode.c:363 udf_setsize+0x4b2/0x10f0 fs/udf/inode.c:1289 udf_setattr+0x523/0x6c0 fs/udf/file.c:236 notify_change+0x6d3/0x1280 fs/attr.c:503 do_truncate+0x143/0x200 fs/open.c:65 vfs_truncate+0x3e3/0x4c0 fs/open.c:111 do_sys_truncate.part.0+0xf7/0x140 fs/open.c:134 do_sys_truncate fs/open.c:128 [inline] __do_sys_truncate fs/open.c:146 [inline] __se_sys_truncate fs/open.c:144 [inline] __x64_sys_truncate+0x6d/0xa0 fs/open.c:144 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (mapping.invalidate_lock#4){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain kernel/locking/lockdep.c:3904 [inline] __lock_acquire+0x2425/0x3b90 kernel/locking/lockdep.c:5202 lock_acquire.part.0+0x11b/0x370 kernel/locking/lockdep.c:5825 down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 filemap_invalidate_lock_shared include/linux/fs.h:870 [inline] udf_page_mkwrite+0x2af/0xa20 fs/udf/file.c:50 do_page_mkwrite+0x17d/0x390 mm/memory.c:3161 wp_page_shared mm/memory.c:3562 [inline] do_wp_page+0x1291/0x4860 mm/memory.c:3712 handle_pte_fault mm/memory.c:5786 [inline] __handle_mm_fault+0x150c/0x2a20 mm/memory.c:5913 handle_mm_fault+0x404/0xab0 mm/memory.c:6081 do_user_addr_fault+0x61b/0x13a0 arch/x86/mm/fault.c:1338 handle_page_fault arch/x86/mm/fault.c:1481 [inline] exc_page_fault+0x98/0x180 arch/x86/mm/fault.c:1539 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 other info that might help us debug this: Chain exists of: mapping.invalidate_lock#4 --> &vma->vm_lock->lock --> sb_pagefaults#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(sb_pagefaults#2); lock(&vma->vm_lock->lock); lock(sb_pagefaults#2); rlock(mapping.invalidate_lock#4); *** DEADLOCK *** 2 locks held by syz.6.870/18445: #0: ffff888050dbed18 (&vma->vm_lock->lock){++++}-{3:3}, at: vma_start_read include/linux/mm.h:704 [inline] #0: ffff888050dbed18 (&vma->vm_lock->lock){++++}-{3:3}, at: lock_vma_under_rcu+0x141/0x9a0 mm/memory.c:6247 #1: ffff888044124518 (sb_pagefaults#2){.+.+}-{0:0}, at: do_page_mkwrite+0x17d/0x390 mm/memory.c:3161 stack backtrace: CPU: 0 UID: 0 PID: 18445 Comm: syz.6.870 Not tainted 6.12.24 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_circular_bug+0x406/0x5c0 kernel/locking/lockdep.c:2074 check_noncircular+0x2f7/0x3e0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain kernel/locking/lockdep.c:3904 [inline] __lock_acquire+0x2425/0x3b90 kernel/locking/lockdep.c:5202 lock_acquire.part.0+0x11b/0x370 kernel/locking/lockdep.c:5825 down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 filemap_invalidate_lock_shared include/linux/fs.h:870 [inline] udf_page_mkwrite+0x2af/0xa20 fs/udf/file.c:50 do_page_mkwrite+0x17d/0x390 mm/memory.c:3161 wp_page_shared mm/memory.c:3562 [inline] do_wp_page+0x1291/0x4860 mm/memory.c:3712 handle_pte_fault mm/memory.c:5786 [inline] __handle_mm_fault+0x150c/0x2a20 mm/memory.c:5913 handle_mm_fault+0x404/0xab0 mm/memory.c:6081 do_user_addr_fault+0x61b/0x13a0 arch/x86/mm/fault.c:1338 handle_page_fault arch/x86/mm/fault.c:1481 [inline] exc_page_fault+0x98/0x180 arch/x86/mm/fault.c:1539 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0033:0x7fc9b0c4f002 Code: f0 48 8b 54 24 f0 8b 8a 80 00 00 00 8b 82 04 01 00 00 21 c8 83 c1 01 c1 e0 04 48 8b b4 02 40 01 00 00 48 8b 84 02 48 01 00 00 <89> 8a 80 00 00 00 48 81 fe 45 23 01 00 74 09 48 81 fe 56 34 02 00 RSP: 002b:00007fc9b1c9af88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00007fc9b0fe6080 RCX: 0000000000000001 RDX: 0000200000ff9000 RSI: 0000000000000000 RDI: 0000200000ff9000 RBP: 00007fc9b0e46d56 R08: 0000000000000000 R09: 0000000000000000 R10: 0000200000ff9000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fc9b0fe6080 R15: 00007fc9b1c7b000 </TASK> ================================================================== I hope it helps. Best regards Jianzhou Zhao

2 months

1
0
0 0

[PATCH] usb: uhci-platform: Make the clock really optional

by Alexey Charkov

Device tree bindings state that the clock is optional for UHCI platform controllers, and some existing device trees don't provide those - such as those for VIA/WonderMedia devices. The driver however fails to probe now if no clock is provided, because devm_clk_get returns an error pointer in such case. Switch to devm_clk_get_optional instead, so that it could probe again on those platforms where no clocks are given. Cc: stable(a)vger.kernel.org Fixes: 26c502701c52 ("usb: uhci: Add clk support to uhci-platform") Signed-off-by: Alexey Charkov <alchark(a)gmail.com> --- drivers/usb/host/uhci-platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c index a7c934404ebc7ed74f64265fafa7830809979ba5..62318291f5664c9ec94f24535c71d962e28354f3 100644 --- a/drivers/usb/host/uhci-platform.c +++ b/drivers/usb/host/uhci-platform.c @@ -121,7 +121,7 @@ static int uhci_hcd_platform_probe(struct platform_device *pdev) } /* Get and enable clock if any specified */ - uhci->clk = devm_clk_get(&pdev->dev, NULL); + uhci->clk = devm_clk_get_optional(&pdev->dev, NULL); if (IS_ERR(uhci->clk)) { ret = PTR_ERR(uhci->clk); goto err_rmr; --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250425-uhci-clock-optional-9a9d09560e17 Best regards, -- Alexey Charkov <alchark(a)gmail.com>

2 months

2
2
0 0

[PATCH RESEND v3 0/3] Add ti,suppress-v1p8-ena

by Judith Mendez

Resend patch series to fix cc list There are MMC boot failures seen with V1P8_SIGNAL_ENA on Kingston eMMC and Microcenter/Patriot SD cards on Sitara K3 boards due to the HS200 initialization sequence involving V1P8_SIGNAL_ENA. Since V1P8_SIGNAL_ENA is optional for eMMC, do not set V1P8_SIGNAL_ENA by default for eMMC. For SD cards we shall parse DT for ti,suppress-v1p8-ena property to determine whether to suppress V1P8_SIGNAL_ENA. Add new ti,suppress-v1p8-ena to am62x, am62ax, and am62px SoC dtsi files since there is no internal LDO tied to sdhci1 interface so V1P8_SIGNAL_ENA only affects timing. This fix was previously merged in the kernel, but was reverted due to the "heuristics for enabling the quirk"[0]. This issue is adressed in this patch series by adding optional ti,suppress-v1p8-ena DT property which determines whether to apply the quirk for SD. Changes since v2: - Include patch 3/3 - Reword cover letter - Reword binding patch description - Add fixes/cc tags to driver patch - Reorder patches according to binding patch first - Resend to fix cc list in original v3 series Link to v2: https://lore.kernel.org/linux-mmc/20250417182652.3521104-1-jm@ti.com/ Link to v1: https://lore.kernel.org/linux-mmc/20250407222702.2199047-1-jm@ti.com/ [0] https://lore.kernel.org/linux-mmc/20250127-am654-mmc-regression-v2-1-9bb39f… Judith Mendez (3): dt-bindings: mmc: sdhci-am654: Add ti,suppress-v1p8-ena mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch arm64: dts: ti: k3-am62*: add ti,suppress-v1p8-ena .../devicetree/bindings/mmc/sdhci-am654.yaml | 5 +++ arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 1 + arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 1 + .../dts/ti/k3-am62p-j722s-common-main.dtsi | 1 + drivers/mmc/host/sdhci_am654.c | 32 +++++++++++++++++++ 5 files changed, 40 insertions(+) base-commit: 1be38f81251f6d276713c259ecf4414f82f22c29 -- 2.49.0

2 months

4
8
0 0

[PATCH v2 1/4] firmware: arm_scmi: Ensure that the message-id supports fastchannel

by Cristian Marussi

From: Sibi Sankar <quic_sibis(a)quicinc.com> Currently the perf and powercap protocol relies on the protocol domain attributes, which just ensures that one fastchannel per domain, before instantiating fastchannels for all possible message-ids. Fix this by ensuring that each message-id supports fastchannel before initialization. Logs: scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging. scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging. scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging. CC: stable(a)vger.kernel.org Reported-by: Johan Hovold <johan+linaro(a)kernel.org> Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/ Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Sibi Sankar <quic_sibis(a)quicinc.com> [Cristian: Modified the condition checked to establish support or not] Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com> --- RFC -> V1 - picked up a few tags Since PROTOCOL_MESSAGE_ATTRIBUTES, used to check if message_id is supported, is a mandatory command, it cannot fail so we must bail-out NOT only if FC was not supported for that command but also if the query fails as a whole; so the condition checked for bailing out is modified to: if (ret || !MSG_SUPPORTS_FASTCHANNEL(attributes)) { --- drivers/firmware/arm_scmi/driver.c | 76 +++++++++++++++------------ drivers/firmware/arm_scmi/protocols.h | 2 + 2 files changed, 45 insertions(+), 33 deletions(-) diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 1cf18cc8e63f..0e281fca0a38 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -1738,6 +1738,39 @@ static int scmi_common_get_max_msg_size(const struct scmi_protocol_handle *ph) return info->desc->max_msg_size; } +/** + * scmi_protocol_msg_check - Check protocol message attributes + * + * @ph: A reference to the protocol handle. + * @message_id: The ID of the message to check. + * @attributes: A parameter to optionally return the retrieved message + * attributes, in case of Success. + * + * An helper to check protocol message attributes for a specific protocol + * and message pair. + * + * Return: 0 on SUCCESS + */ +static int scmi_protocol_msg_check(const struct scmi_protocol_handle *ph, + u32 message_id, u32 *attributes) +{ + int ret; + struct scmi_xfer *t; + + ret = xfer_get_init(ph, PROTOCOL_MESSAGE_ATTRIBUTES, + sizeof(__le32), 0, &t); + if (ret) + return ret; + + put_unaligned_le32(message_id, t->tx.buf); + ret = do_xfer(ph, t); + if (!ret && attributes) + *attributes = get_unaligned_le32(t->rx.buf); + xfer_put(ph, t); + + return ret; +} + /** * struct scmi_iterator - Iterator descriptor * @msg: A reference to the message TX buffer; filled by @prepare_message with @@ -1879,6 +1912,7 @@ scmi_common_fastchannel_init(const struct scmi_protocol_handle *ph, int ret; u32 flags; u64 phys_addr; + u32 attributes; u8 size; void __iomem *addr; struct scmi_xfer *t; @@ -1887,6 +1921,15 @@ scmi_common_fastchannel_init(const struct scmi_protocol_handle *ph, struct scmi_msg_resp_desc_fc *resp; const struct scmi_protocol_instance *pi = ph_to_pi(ph); + /* Check if the MSG_ID supports fastchannel */ + ret = scmi_protocol_msg_check(ph, message_id, &attributes); + if (ret || !MSG_SUPPORTS_FASTCHANNEL(attributes)) { + dev_dbg(ph->dev, + "Skip FC init for 0x%02X/%d domain:%d - ret:%d\n", + pi->proto->id, message_id, domain, ret); + return; + } + if (!p_addr) { ret = -EINVAL; goto err_out; @@ -2004,39 +2047,6 @@ static void scmi_common_fastchannel_db_ring(struct scmi_fc_db_info *db) SCMI_PROTO_FC_RING_DB(64); } -/** - * scmi_protocol_msg_check - Check protocol message attributes - * - * @ph: A reference to the protocol handle. - * @message_id: The ID of the message to check. - * @attributes: A parameter to optionally return the retrieved message - * attributes, in case of Success. - * - * An helper to check protocol message attributes for a specific protocol - * and message pair. - * - * Return: 0 on SUCCESS - */ -static int scmi_protocol_msg_check(const struct scmi_protocol_handle *ph, - u32 message_id, u32 *attributes) -{ - int ret; - struct scmi_xfer *t; - - ret = xfer_get_init(ph, PROTOCOL_MESSAGE_ATTRIBUTES, - sizeof(__le32), 0, &t); - if (ret) - return ret; - - put_unaligned_le32(message_id, t->tx.buf); - ret = do_xfer(ph, t); - if (!ret && attributes) - *attributes = get_unaligned_le32(t->rx.buf); - xfer_put(ph, t); - - return ret; -} - static const struct scmi_proto_helpers_ops helpers_ops = { .extended_name_get = scmi_common_extended_name_get, .get_max_msg_size = scmi_common_get_max_msg_size, diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h index aaee57cdcd55..d62c4469d1fd 100644 --- a/drivers/firmware/arm_scmi/protocols.h +++ b/drivers/firmware/arm_scmi/protocols.h @@ -31,6 +31,8 @@ #define SCMI_PROTOCOL_VENDOR_BASE 0x80 +#define MSG_SUPPORTS_FASTCHANNEL(x) ((x) & BIT(0)) + enum scmi_common_cmd { PROTOCOL_VERSION = 0x0, PROTOCOL_ATTRIBUTES = 0x1, -- 2.47.0

2 months

1
0
0 0

[PATCH] ASoC: renesas: rz-ssi: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> In the latest kernel versions system crashes were noticed occasionally during suspend/resume. This occurs because the RZ SSI suspend trigger (called from snd_soc_suspend()) is executed after rz_ssi_pm_ops->suspend() and it accesses IP registers. After the rz_ssi_pm_ops->suspend() is executed the IP clocks are disabled and its reset line is asserted. Since snd_soc_suspend() is invoked through snd_soc_pm_ops->suspend(), snd_soc_pm_ops is associated with soc_driver (defined in sound/soc/soc-core.c), and there is no parent-child relationship between soc_driver and rz_ssi_driver the power management subsystem does not enforce a specific suspend/resume order between the RZ SSI platform driver and soc_driver. To ensure that the suspend/resume function of rz-ssi is executed after snd_soc_suspend(), use NOIRQ_SYSTEM_SLEEP_PM_OPS(). Fixes: 1fc778f7c833 ("ASoC: renesas: rz-ssi: Add suspend to RAM support") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- sound/soc/renesas/rz-ssi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/renesas/rz-ssi.c b/sound/soc/renesas/rz-ssi.c index 3a0af4ca7ab6..0f7458a43901 100644 --- a/sound/soc/renesas/rz-ssi.c +++ b/sound/soc/renesas/rz-ssi.c @@ -1244,7 +1244,7 @@ static int rz_ssi_runtime_resume(struct device *dev) static const struct dev_pm_ops rz_ssi_pm_ops = { RUNTIME_PM_OPS(rz_ssi_runtime_suspend, rz_ssi_runtime_resume, NULL) - SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) + NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) }; static struct platform_driver rz_ssi_driver = { -- 2.43.0

2 months

2
1
0 0

[PATCH] ASoC: meson: meson-card-utils: use of_property_present() for DT parsing

by Martin Blumenstingl

Commit c141ecc3cecd ("of: Warn when of_property_read_bool() is used on non-boolean properties") added a warning when trying to parse a property with a value (boolean properties are defined as: absent = false, present without any value = true). This causes a warning from meson-card-utils. meson-card-utils needs to know about the existence of the "audio-routing" and/or "audio-widgets" properties in order to properly parse them. Switch to of_property_present() in order to silence the following warning messages during boot: OF: /sound: Read of boolean property 'audio-routing' with a value. OF: /sound: Read of boolean property 'audio-widgets' with a value. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Tested-by: Christian Hewitt <christianshewitt(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com> --- sound/soc/meson/meson-card-utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/meson/meson-card-utils.c b/sound/soc/meson/meson-card-utils.c index cfc7f6e41ab5..68531183fb60 100644 --- a/sound/soc/meson/meson-card-utils.c +++ b/sound/soc/meson/meson-card-utils.c @@ -231,7 +231,7 @@ static int meson_card_parse_of_optional(struct snd_soc_card *card, const char *p)) { /* If property is not provided, don't fail ... */ - if (!of_property_read_bool(card->dev->of_node, propname)) + if (!of_property_present(card->dev->of_node, propname)) return 0; /* ... but do fail if it is provided and the parsing fails */ -- 2.49.0

2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025