- Linux-stable-mirror - lists.linaro.org

[PATCH] LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY

by Huacai Chen

Now we use virtual addresses to fill CSR_MERRENTRY/CSR_TLBRENTRY, but hardware hope physical addresses. Now it works well because the high bits are ignored above PA_BITS (48 bits), but explicitly use physical addresses can avoid potential bugs. So fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/kernel/traps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/kernel/traps.c b/arch/loongarch/kernel/traps.c index 3d9be6ca7ec5..da5926fead4a 100644 --- a/arch/loongarch/kernel/traps.c +++ b/arch/loongarch/kernel/traps.c @@ -1131,8 +1131,8 @@ static void configure_exception_vector(void) tlbrentry = (unsigned long)exception_handlers + 80*VECSIZE; csr_write64(eentry, LOONGARCH_CSR_EENTRY); - csr_write64(eentry, LOONGARCH_CSR_MERRENTRY); - csr_write64(tlbrentry, LOONGARCH_CSR_TLBRENTRY); + csr_write64(__pa(eentry), LOONGARCH_CSR_MERRENTRY); + csr_write64(__pa(tlbrentry), LOONGARCH_CSR_TLBRENTRY); } void per_cpu_trap_init(int cpu) -- 2.47.3

2 weeks, 4 days

1
0
0 0

[PATCH v2] ksmbd: vfs: skip lock-range check on equal size to avoid size==0 underflow

by Qianchang Zhao

When size equals the current i_size (including 0), the code used to call check_lock_range(filp, i_size, size - 1, WRITE), which computes `size - 1` and can underflow for size==0. Skip the equal case. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/vfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c index 891ed2dc2..d068b78a3 100644 --- a/fs/smb/server/vfs.c +++ b/fs/smb/server/vfs.c @@ -828,7 +828,7 @@ int ksmbd_vfs_truncate(struct ksmbd_work *work, if (size < inode->i_size) { err = check_lock_range(filp, size, inode->i_size - 1, WRITE); - } else { + } else if (size > inode->i_size) { err = check_lock_range(filp, inode->i_size, size - 1, WRITE); } -- 2.34.1

2 weeks, 4 days

2
1
0 0

Fwd: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor

by Chuck Lever

FYI https://bugzilla.kernel.org/show_bug.cgi?id=220745 -------- Forwarded Message -------- Subject: Re: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor Date: Thu, 06 Nov 2025 07:29:25 -0500 From: Jeff Layton <jlayton(a)kernel.org> To: Mike-SPC via Bugspray Bot <bugbot(a)kernel.org>, cel(a)kernel.org, neilb(a)ownmail.net, trondmy(a)kernel.org, linux-nfs(a)vger.kernel.org, anna(a)kernel.org, neilb(a)brown.name On Thu, 2025-11-06 at 11:30 +0000, Mike-SPC via Bugspray Bot wrote: > Mike-SPC writes via Kernel.org Bugzilla: > > (In reply to Bugspray Bot from comment #5) > > Chuck Lever <cel(a)kernel.org> replies to comment #4: > > > > On 11/5/25 7:25 AM, Mike-SPC via Bugspray Bot wrote: > > > Mike-SPC writes via Kernel.org Bugzilla: > > > > > > > Have you found a 6.1.y kernel for which the build doesn't fail? > > > > > > Yes. Compiling Version 6.1.155 works without problems. > > > Versions >= 6.1.156 aren't. > > > > My analysis yesterday suggests that, because the nfs4state.c code hasn't > > changed, it's probably something elsewhere that introduced this problem. > > As we can't reproduce the issue, can you use "git bisect" between > > v6.1.155 and v6.1.156 to find the culprit commit? > > > > (via https://msgid.link/ab235dbe-7949-4208-a21a-2cdd50347152@kernel.org) > > > Yes, your analysis is right (thanks for it). > After some investigation, the issue appears to be caused by changes introduced in > include/linux/minmax.h. > > I verified this by replacing minmax.h in 6.1.156 with the version from 6.1.155, > and the kernel then compiles successfully. > > The relevant section in the 6.1.156 changelog (https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.156) shows several modifications to minmax.h (notably around __clamp_once() and the use of > BUILD_BUG_ON_MSG(statically_true(ulo > uhi), ...)), which seem to trigger a compile-time assertion when building NFSD. > > Replacing the updated header with the previous one resolves the issue, so this appears > to be a regression introduced by the new clamp() logic. > > Could you please advise who is the right person or mailing list to report this issue to > (minmax.h maintainers, kernel core, or stable tree)? > I'd let all 3 know, and I'd include the author of the patches that you suspect are the problem. They'll probably want to revise the one that's a problem. Cheers, -- Jeff Layton <jlayton(a)kernel.org>

2 weeks, 4 days

3
8
0 0

[PATCH] powerpc: Fix mprotect on book3s32

by Dave Vasilevsky via B4 Relay

From: Dave Vasilevsky <dave(a)vasilevsky.ca> On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 8 ++++++-- arch/powerpc/mm/book3s32/tlb.c | 6 ++++++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..b8c587ad2ea954f179246a57d6e86e45e91dcfdc 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -28,9 +29,12 @@ void _tlbia(void); */ static inline void tlb_flush(struct mmu_gather *tlb) { - /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) { + hash__flush_gather(tlb); + } else { + /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ _tlbia(); + } } static inline void flush_range(struct mm_struct *mm, unsigned long start, unsigned long end) diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..3da95ecfbbb296303082e378425e92a5fbdbfac8 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,9 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

2 weeks, 4 days

4
3
0 0

[PATCH] mm/hmm/test: Fix error handling in dmirror_device_init

by Ma Ke

dmirror_device_init() calls device_initialize() which sets the device reference count to 1, but fails to call put_device() when error occurs after dev_set_name() or cdev_device_add() failures. This results in memory leaks of struct device objects. Additionally, dmirror_device_remove() lacks the final put_device() call to properly release the device reference. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 6a760f58c792 ("mm/hmm/test: use char dev with struct device to get device node") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- lib/test_hmm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/test_hmm.c b/lib/test_hmm.c index 83e3d8208a54..5159fc36eea6 100644 --- a/lib/test_hmm.c +++ b/lib/test_hmm.c @@ -1458,20 +1458,25 @@ static int dmirror_device_init(struct dmirror_device *mdevice, int id) ret = dev_set_name(&mdevice->device, "hmm_dmirror%u", id); if (ret) - return ret; + goto put_device; ret = cdev_device_add(&mdevice->cdevice, &mdevice->device); if (ret) - return ret; + goto put_device; /* Build a list of free ZONE_DEVICE struct pages */ return dmirror_allocate_chunk(mdevice, NULL); + +put_device: + put_device(&mdevice->device); + return ret; } static void dmirror_device_remove(struct dmirror_device *mdevice) { dmirror_device_remove_chunks(mdevice); cdev_device_del(&mdevice->cdevice, &mdevice->device); + put_device(&mdevice->device); } static int __init hmm_dmirror_init(void) -- 2.17.1

2 weeks, 4 days

2
1
0 0

[PATCH] ksmbd: fix leak of transform buffer on encrypt_resp() failure

by Qianchang Zhao

When encrypt_resp() fails at the send path, we only set STATUS_DATA_ERROR but leave the transform buffer allocated (work->tr_buf in this tree). Repeating this path leaks kernel memory and can lead to OOM (DoS) when encryption is required. Reproduced on: Linux v6.18-rc2 (self-built test kernel) Fix by freeing the transform buffer and forcing plaintext error reply. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/server.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c index 40420544c..15dd13e76 100644 --- a/fs/smb/server/server.c +++ b/fs/smb/server/server.c @@ -244,8 +244,14 @@ static void __handle_ksmbd_work(struct ksmbd_work *work, if (work->sess && work->sess->enc && work->encrypted && conn->ops->encrypt_resp) { rc = conn->ops->encrypt_resp(work); - if (rc < 0) + if (rc < 0) { conn->ops->set_rsp_status(work, STATUS_DATA_ERROR); + work->encrypted = false; + if (work->tr_buf) { + kvfree(work->tr_buf); + work->tr_buf = NULL; + } + } } if (work->sess) ksmbd_user_session_put(work->sess); -- 2.34.1

2 weeks, 4 days

2
3
0 0

FAILED: patch "[PATCH] btrfs: ensure no dirty metadata is written back for an fs" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 2618849f31e7cf51fadd4a5242458501a6d5b315 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110858-banker-discolor-266d@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2618849f31e7cf51fadd4a5242458501a6d5b315 Mon Sep 17 00:00:00 2001 From: Qu Wenruo <wqu(a)suse.com> Date: Thu, 23 Oct 2025 19:44:04 +1030 Subject: [PATCH] btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs. CC: stable(a)vger.kernel.org # 6.6+ Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 755ec6dfd51c..23273d0e6f22 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2228,6 +2228,14 @@ static noinline_for_stack void write_one_eb(struct extent_buffer *eb, wbc_account_cgroup_owner(wbc, folio, range_len); folio_unlock(folio); } + /* + * If the fs is already in error status, do not submit any writeback + * but immediately finish it. + */ + if (unlikely(BTRFS_FS_ERROR(fs_info))) { + btrfs_bio_end_io(bbio, errno_to_blk_status(BTRFS_FS_ERROR(fs_info))); + return; + } btrfs_submit_bbio(bbio, 0); }

2 weeks, 4 days

2
1
0 0

FAILED: patch "[PATCH] drm/mediatek: Disable AFBC support on Mediatek DRM driver" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 9882a40640036d5bbc590426a78981526d4f2345 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110838-imply-extruding-3561@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9882a40640036d5bbc590426a78981526d4f2345 Mon Sep 17 00:00:00 2001 From: Ariel D'Alessandro <ariel.dalessandro(a)collabora.com> Date: Fri, 24 Oct 2025 17:27:56 -0300 Subject: [PATCH] drm/mediatek: Disable AFBC support on Mediatek DRM driver Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa. Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ariel D'Alessandro <ariel.dalessandro(a)collabora.com> Reviewed-by: Daniel Stone <daniels(a)collabora.com> Reviewed-by: CK Hu <ck.hu(a)mediatek.com> Reviewed-by: Macpaul Lin <macpaul.lin(a)mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251024202756.811425-… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c b/drivers/gpu/drm/mediatek/mtk_plane.c index 02349bd44001..788b52c1d10c 100644 --- a/drivers/gpu/drm/mediatek/mtk_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_plane.c @@ -21,9 +21,6 @@ static const u64 modifiers[] = { DRM_FORMAT_MOD_LINEAR, - DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | - AFBC_FORMAT_MOD_SPLIT | - AFBC_FORMAT_MOD_SPARSE), DRM_FORMAT_MOD_INVALID, }; @@ -71,26 +68,7 @@ static bool mtk_plane_format_mod_supported(struct drm_plane *plane, uint32_t format, uint64_t modifier) { - if (modifier == DRM_FORMAT_MOD_LINEAR) - return true; - - if (modifier != DRM_FORMAT_MOD_ARM_AFBC( - AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | - AFBC_FORMAT_MOD_SPLIT | - AFBC_FORMAT_MOD_SPARSE)) - return false; - - if (format != DRM_FORMAT_XRGB8888 && - format != DRM_FORMAT_ARGB8888 && - format != DRM_FORMAT_BGRX8888 && - format != DRM_FORMAT_BGRA8888 && - format != DRM_FORMAT_ABGR8888 && - format != DRM_FORMAT_XBGR8888 && - format != DRM_FORMAT_RGB888 && - format != DRM_FORMAT_BGR888) - return false; - - return true; + return modifier == DRM_FORMAT_MOD_LINEAR; } static void mtk_plane_destroy_state(struct drm_plane *plane,

2 weeks, 4 days

2
1
0 0

[PATCH] ksmbd: vfs: fix truncate lock-range check for shrink/grow and avoid size==0 underflow

by Qianchang Zhao

ksmbd_vfs_truncate() uses check_lock_range() with arguments that are incorrect for shrink, and can underflow when size==0: - For shrink, the code passed [inode->i_size, size-1], which is reversed. - When size==0, "size-1" underflows to -1, so the range becomes [old_size, -1], effectively skipping the intended [0, old_size-1]. Fix by: - Rejecting negative size with -EINVAL. - For shrink (size < old): check [size, old-1]. - For grow (size > old): check [old, size-1]. - Skip lock check when size == old. - Keep the return value on conflict as -EAGAIN (no noisy pr_err()). This avoids the size==0 underflow and uses the correct range order, preserving byte-range lock semantics. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/vfs.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c index 891ed2dc2..e7843ec9b 100644 --- a/fs/smb/server/vfs.c +++ b/fs/smb/server/vfs.c @@ -825,17 +825,27 @@ int ksmbd_vfs_truncate(struct ksmbd_work *work, if (!work->tcon->posix_extensions) { struct inode *inode = file_inode(filp); - if (size < inode->i_size) { - err = check_lock_range(filp, size, - inode->i_size - 1, WRITE); - } else { - err = check_lock_range(filp, inode->i_size, - size - 1, WRITE); + loff_t old = i_size_read(inode); + loff_t start = 0, end = -1; + bool need_check = false; + + if (size < 0) + return -EINVAL; + + if (size < old) { + start = size; + end = old - 1; + need_check = true; + } else if (size > old) { + start = old; + end = size - 1; + need_check = true; } - if (err) { - pr_err("failed due to lock\n"); - return -EAGAIN; + if (need_check) { + err = check_lock_range(filp, start, end, WRITE); + if (err) + return -EAGAIN; } } -- 2.34.1

2 weeks, 4 days

1
0
0 0

[PATCH v6 1/2] dt-bindings: media: qcom,qcs8300-camss: Add missing power supplies

by Vikram Sharma

Add missing vdda-phy-supply and vdda-pll-supply in the (monaco)qcs8300 camss binding. While enabling imx412 sensor for qcs8300 we see a need to add these supplies which were missing in initial submission. Fixes: 634a2958fae30 ("media: dt-bindings: Add qcom,qcs8300-camss compatible") Cc: <stable(a)vger.kernel.org> Co-developed-by: Nihal Kumar Gupta <quic_nihalkum(a)quicinc.com> Signed-off-by: Nihal Kumar Gupta <quic_nihalkum(a)quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa(a)quicinc.com> --- .../bindings/media/qcom,qcs8300-camss.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml index 80a4540a22dc..e5f170aa4d9e 100644 --- a/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml @@ -120,6 +120,14 @@ properties: items: - const: top + vdda-phy-supply: + description: + Phandle to a 0.88V regulator supply to CSI PHYs. + + vdda-pll-supply: + description: + Phandle to 1.2V regulator supply to CSI PHYs pll block. + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -160,6 +168,8 @@ required: - power-domains - power-domain-names - ports + - vdda-phy-supply + - vdda-pll-supply additionalProperties: false @@ -328,6 +338,9 @@ examples: power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>; power-domain-names = "top"; + vdda-phy-supply = <&vreg_l4a_0p88>; + vdda-pll-supply = <&vreg_l1c_1p2>; + ports { #address-cells = <1>; #size-cells = <0>; -- 2.34.1

2 weeks, 4 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror