* Re: [PATCH] phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix
From: Abel Vesa @ 2026-04-20 11:30 UTC (permalink / raw)
To: Nitin Rawat
Cc: vkoul, neil.armstrong, konrad.dybcio, dmitry.baryshkov, mani,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com>
On 26-04-15 16:18:51, Nitin Rawat wrote:
> Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared
> sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base
> table to fix Gear 4 operation on SM8650.
>
> However, this change inadvertently broke kaanapali and SM8750 SoCs
> which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5
> configuration but use their own sm8750_ufsphy_pcs base table. After the
> change, kaanapali PHYs are left without the required PLL_CNTL = 0x33
> setting, causing the PHY PLL to remain at its hardware reset default
> value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts.
>
> Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry
> to the sm8750_ufsphy_pcs table, mirroring what the original commit
> already did for sm8650_ufsphy_pcs.
>
> Cc: stable@vger.kernel.org # v6.19.12
> Fixes: 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] vmalloc: fix buffer overflow in vrealloc_node_align()
From: Marco Elver @ 2026-04-20 11:47 UTC (permalink / raw)
To: elver, Vlastimil Babka, Andrew Morton
Cc: Uladzislau Rezki, linux-mm, linux-kernel, kasan-dev, Vitaly Wool,
stable, Harry Yoo (Oracle)
Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
vrealloc") added the ability to force a new allocation if the current
pointer is on the wrong NUMA node, or if an alignment constraint is not
met, even if the user is shrinking the allocation.
On this path (need_realloc), the code allocates a new object of 'size'
bytes and then memcpy()s 'old_size' bytes into it. If the request is to
shrink the object (size < old_size), this results in an out-of-bounds
write on the new buffer.
Fix this by bounding the copy length by the new allocation size.
Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
Cc: <stable@vger.kernel.org>
Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
Signed-off-by: Marco Elver <elver@google.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 61caa55a4402..8b1124158f54 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
return NULL;
if (p) {
- memcpy(n, p, old_size);
+ memcpy(n, p, min(size, old_size));
vfree(p);
}
--
2.54.0.rc1.513.gad8abe7a5a-goog
^ permalink raw reply related
* [PATCH v2] btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC
From: Qu Wenruo @ 2026-04-20 11:50 UTC (permalink / raw)
To: linux-btrfs; +Cc: stable
[WARNING]
When running test cases with injected errors or shutdown, e.g.
generic/388 or generic/475, there is a chance that the following kernel
warning is triggered:
BTRFS info (device dm-2): first mount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff
BTRFS info (device dm-2): using crc32c checksum algorithm
BTRFS info (device dm-2): checking UUID tree
BTRFS info (device dm-2): turning on async discard
BTRFS info (device dm-2): enabling free space tree
BTRFS critical (device dm-2 state E): emergency shutdown
------------[ cut here ]------------
WARNING: extent_io.c:1742 at extent_writepage_io+0x437/0x520 [btrfs], CPU#2: kworker/u43:2/651591
CPU: 2 UID: 0 PID: 651591 Comm: kworker/u43:2 Tainted: G W OE 7.0.0-rc6-custom+ #365 PREEMPT(full) 5804053f02137e627472d94b5128cc9fcb110e88
RIP: 0010:extent_writepage_io+0x437/0x520 [btrfs]
Call Trace:
<TASK>
extent_write_cache_pages+0x2a5/0x820 [btrfs 70299925d0856939e93b17d480651713b3cbba58]
btrfs_writepages+0x74/0x130 [btrfs 70299925d0856939e93b17d480651713b3cbba58]
do_writepages+0xd0/0x160
__writeback_single_inode+0x42/0x340
writeback_sb_inodes+0x22d/0x580
wb_writeback+0xc6/0x360
wb_workfn+0xbd/0x470
process_one_work+0x198/0x3b0
worker_thread+0x1c8/0x330
kthread+0xee/0x120
ret_from_fork+0x2a6/0x330
ret_from_fork_asm+0x11/0x20
</TASK>
---[ end trace 0000000000000000 ]---
BTRFS error (device dm-2 state E): root 5 ino 259 folio 1323008 is marked dirty without notifying the fs
BTRFS error (device dm-2 state E): failed to submit blocks, root=5 inode=259 folio=1323008 submit_bitmap=0: -117
BTRFS info (device dm-2 state E): last unmount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff
[CAUSE]
Inside btrfs we have the following pattern in several locations, for
example inside btrfs_dirty_folio():
btrfs_clear_extent_bit(&inode->io_tree, start_pos, end_of_last_block,
EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
cached);
ret = btrfs_set_extent_delalloc(inode, start_pos, end_of_last_block,
extra_bits, cached);
if (ret)
return ret;
However btrfs_set_extent_delalloc() can return IO errors other than -ENOMEM
through the following callchain:
btrfs_set_extent_delalloc()
\- btrfs_find_new_delalloc_bytes()
\- btrfs_get_extent()
\- btrfs_lookup_file_extent()
\- btrfs_search_slot()
When such IO error happened, the previous btrfs_clear_extent_bit() has
cleared the EXTENT_DELALLOC for the range, and we're expecting
btrfs_set_extent_delalloc() to re-set EXTENT_DELALLOC.
But since btrfs_set_extent_delalloc() failed before
btrfs_set_extent_bit(), EXTENT_DELALLOC flag is no longere present.
And if the folio range is dirty before entering
btrfs_set_extent_delalloc(), we got a dirty folio but no EXTENT_DELALLOC
flag now.
Then we hit the folio writeback:
extent_writepage()
|- writepage_delalloc()
| No ordered extent is created, as there is no EXTENT_DELALLOC set
| for the folio range.
| This also means the folio has no ordered flag set.
|
|- extent_writepage_io()
\- if (unlikely(!folio_test_ordered(folio))
Now we hit the warning.
[FIX]
Introduce a new helper, btrfs_reset_extent_delalloc() to replace the
currently open-coded btrfs_clear_extent_bit() +
btrfs_set_extent_delalloc() combination.
Instead of calling btrfs_clear_extent_bit() first, update
EXTENT_DELALLOC_NEW first, as that part can fail due to metadata IO,
meanwhile btrfs_clear_extent_bit() and btrfs_set_extent_bit() can really
only fail with -ENOMEM.
This allows us to fail early without clearing EXTENT_DELALLOC bit, so
even if that new btrfs_reset_extent_delalloc() failed before touching
EXTENT_DELALLOC, the existing dirty range will still have their old
EXTENT_DELALLOC flag present, thus avoid the warning.
Cc: stable@vger.kernel.org # 6.1+
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Changelog:
v2:
- Use NULL as @cached_extent for btrfs_find_new_delalloc_bytes()
Unlike later btrfs_clear_extent_bit(), btrfs_find_new_delalloc_bytes()
can hit several different extent maps and update @cached_state.
This makes later btrfs_set/clear_extent_bit() to discard the cache,
making the original optimization less useful.
---
fs/btrfs/btrfs_inode.h | 3 +++
fs/btrfs/file.c | 25 +++---------------
fs/btrfs/inode.c | 58 +++++++++++++++++++++++++++++++++++++-----
fs/btrfs/reflink.c | 4 +--
4 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 6e696b350dc5..ad523549d8b4 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -569,6 +569,9 @@ int btrfs_start_delalloc_roots(struct btrfs_fs_info *fs_info, long nr,
int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
unsigned int extra_bits,
struct extent_state **cached_state);
+int btrfs_reset_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
+ unsigned int extra_bits,
+ struct extent_state **cached_state);
struct btrfs_new_inode_args {
/* Input */
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index a6f641a41d99..ab536a304500 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -85,16 +85,8 @@ int btrfs_dirty_folio(struct btrfs_inode *inode, struct folio *folio, loff_t pos
end_of_last_block = start_pos + num_bytes - 1;
- /*
- * The pages may have already been dirty, clear out old accounting so
- * we can set things up properly
- */
- btrfs_clear_extent_bit(&inode->io_tree, start_pos, end_of_last_block,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
- cached);
-
- ret = btrfs_set_extent_delalloc(inode, start_pos, end_of_last_block,
- extra_bits, cached);
+ ret = btrfs_reset_extent_delalloc(inode, start_pos, end_of_last_block,
+ extra_bits, cached);
if (ret)
return ret;
@@ -1952,18 +1944,7 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
}
}
- /*
- * page_mkwrite gets called when the page is firstly dirtied after it's
- * faulted in, but write(2) could also dirty a page and set delalloc
- * bits, thus in this case for space account reason, we still need to
- * clear any delalloc bits within this page range since we have to
- * reserve data&meta space before lock_page() (see above comments).
- */
- btrfs_clear_extent_bit(io_tree, page_start, end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING |
- EXTENT_DEFRAG, &cached_state);
-
- ret = btrfs_set_extent_delalloc(inode, page_start, end, 0, &cached_state);
+ ret = btrfs_reset_extent_delalloc(inode, page_start, end, 0, &cached_state);
if (ret < 0) {
btrfs_unlock_extent(io_tree, page_start, page_end, &cached_state);
goto out_unlock;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 71129502333a..ec2300698a6a 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2810,7 +2810,10 @@ int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
unsigned int extra_bits,
struct extent_state **cached_state)
{
- WARN_ON(PAGE_ALIGNED(end));
+ const u32 blocksize = inode->root->fs_info->sectorsize;
+
+ ASSERT(IS_ALIGNED(start, blocksize), "start=%llu", start);
+ ASSERT(IS_ALIGNED(end + 1, blocksize), "end=%llu", end);
if (start >= i_size_read(&inode->vfs_inode) &&
!(inode->flags & BTRFS_INODE_PREALLOC)) {
@@ -2833,6 +2836,52 @@ int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
EXTENT_DELALLOC | extra_bits, cached_state);
}
+/*
+ * Clear the old accounting flags and set EXTENT_DELALLOC for the range.
+ *
+ * Return <0 for error, in that case no range has EXTENT_DELALLOC bit cleared or set.
+ */
+int btrfs_reset_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
+ unsigned int extra_bits,
+ struct extent_state **cached_state)
+{
+ const u32 blocksize = inode->root->fs_info->sectorsize;
+
+ /* The @extra_bits can only be EXTENT_NORESERVE for now. */
+ ASSERT(!(extra_bits & ~EXTENT_NORESERVE));
+
+ /* Basic alignment check. */
+ ASSERT(IS_ALIGNED(start, blocksize), "start=%llu", start);
+ ASSERT(IS_ALIGNED(end + 1, blocksize), "end=%llu", end);
+
+ /*
+ * Check and set DELALLOC_NEW flags, this needs to search tree thus
+ * can fail early.
+ * Thus we want to do this before clearing DELALLOC_EXTENT.
+ */
+ if (start >= i_size_read(&inode->vfs_inode) &&
+ !(inode->flags & BTRFS_INODE_PREALLOC)) {
+ /*
+ * There can't be any extents following eof in this case so just
+ * set the delalloc new bit for the range directly.
+ */
+ extra_bits |= EXTENT_DELALLOC_NEW;
+ } else {
+ int ret;
+
+ ret = btrfs_find_new_delalloc_bytes(inode, start, end + 1 - start,
+ NULL);
+ if (unlikely(ret))
+ return ret;
+ }
+ /* Clear the old accounting as the range may already be dirty. */
+ btrfs_clear_extent_bit(&inode->io_tree, start, end,
+ EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING |
+ EXTENT_DEFRAG, cached_state);
+ return btrfs_set_extent_bit(&inode->io_tree, start, end,
+ EXTENT_DELALLOC | extra_bits, cached_state);
+}
+
static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,
struct btrfs_inode *inode, u64 file_pos,
struct btrfs_file_extent_item *stack_fi,
@@ -4973,12 +5022,7 @@ int btrfs_truncate_block(struct btrfs_inode *inode, u64 offset, u64 start, u64 e
goto again;
}
- btrfs_clear_extent_bit(&inode->io_tree, block_start, block_end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
- &cached_state);
-
- ret = btrfs_set_extent_delalloc(inode, block_start, block_end, 0,
- &cached_state);
+ ret = btrfs_reset_extent_delalloc(inode, block_start, block_end, 0, &cached_state);
if (ret) {
btrfs_unlock_extent(io_tree, block_start, block_end, &cached_state);
goto out_unlock;
diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index 14742abe0f92..fb34598a77ff 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -94,9 +94,7 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
if (ret < 0)
goto out_unlock;
- btrfs_clear_extent_bit(&inode->io_tree, file_offset, range_end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG, NULL);
- ret = btrfs_set_extent_delalloc(inode, file_offset, range_end, 0, NULL);
+ ret = btrfs_reset_extent_delalloc(inode, file_offset, range_end, 0, NULL);
if (ret)
goto out_unlock;
--
2.53.0
^ permalink raw reply related
* [PATCH 6.1.y] ublk: fix deadlock when reading partition table
From: Ruohan Lan @ 2026-04-20 12:01 UTC (permalink / raw)
To: gregkh, sashal, stable
Cc: linux-block, Ming Lei, Caleb Sander Mateos, Jens Axboe,
Ruohan Lan
From: Ming Lei <ming.lei@redhat.com>
[ Upstream commit c258f5c4502c9667bccf5d76fa731ab9c96687c1 ]
When one process(such as udev) opens ublk block device (e.g., to read
the partition table via bdev_open()), a deadlock[1] can occur:
1. bdev_open() grabs disk->open_mutex
2. The process issues read I/O to ublk backend to read partition table
3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()
runs bio->bi_end_io() callbacks
4. If this triggers fput() on file descriptor of ublk block device, the
work may be deferred to current task's task work (see fput() implementation)
5. This eventually calls blkdev_release() from the same context
6. blkdev_release() tries to grab disk->open_mutex again
7. Deadlock: same task waiting for a mutex it already holds
The fix is to run blk_update_request() and blk_mq_end_request() with bottom
halves disabled. This forces blkdev_release() to run in kernel work-queue
context instead of current task work context, and allows ublk server to make
forward progress, and avoids the deadlock.
Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
Link: https://github.com/ublk-org/ublksrv/issues/170 [1]
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Caleb Sander Mateos <csander@purestorage.com>
[axboe: rewrite comment in ublk]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[ The fix omits the change in __ublk_do_auto_buf_reg() since this function
doesn't exist in 6.1. ]
Signed-off-by: Ruohan Lan <ruohanlan@aliyun.com>
---
drivers/block/ublk_drv.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 121b62f8bb0a..00d29a3c3d28 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -603,12 +603,20 @@ static inline bool ubq_daemon_is_dying(struct ublk_queue *ubq)
return ubq->ubq_daemon->flags & PF_EXITING;
}
+static void ublk_end_request(struct request *req, blk_status_t error)
+{
+ local_bh_disable();
+ blk_mq_end_request(req, error);
+ local_bh_enable();
+}
+
/* todo: handle partial completion */
static void ublk_complete_rq(struct request *req)
{
struct ublk_queue *ubq = req->mq_hctx->driver_data;
struct ublk_io *io = &ubq->ios[req->tag];
unsigned int unmapped_bytes;
+ bool requeue;
/* failed read IO if nothing is read */
if (!io->res && req_op(req) == REQ_OP_READ)
@@ -641,7 +649,23 @@ static void ublk_complete_rq(struct request *req)
if (unlikely(unmapped_bytes < io->res))
io->res = unmapped_bytes;
- if (blk_update_request(req, BLK_STS_OK, io->res))
+ /*
+ * Run bio->bi_end_io() with softirqs disabled. If the final fput
+ * happens off this path, then that will prevent ublk's blkdev_release()
+ * from being called on current's task work, see fput() implementation.
+ *
+ * Otherwise, ublk server may not provide forward progress in case of
+ * reading the partition table from bdev_open() with disk->open_mutex
+ * held, and causes dead lock as we could already be holding
+ * disk->open_mutex here.
+ *
+ * Preferably we would not be doing IO with a mutex held that is also
+ * used for release, but this work-around will suffice for now.
+ */
+ local_bh_disable();
+ requeue = blk_update_request(req, BLK_STS_OK, io->res);
+ local_bh_enable();
+ if (requeue)
blk_mq_requeue_request(req, true);
else
__blk_mq_end_request(req, BLK_STS_OK);
@@ -694,7 +718,7 @@ static inline void __ublk_abort_rq(struct ublk_queue *ubq,
if (ublk_queue_can_use_recovery(ubq))
blk_mq_requeue_request(rq, false);
else
- blk_mq_end_request(rq, BLK_STS_IOERR);
+ ublk_end_request(rq, BLK_STS_IOERR);
mod_delayed_work(system_wq, &ubq->dev->monitor_work, 0);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] drm/hibmc: Use drm_atomic_helper_check_plane_state()
From: Thomas Zimmermann @ 2026-04-20 12:09 UTC (permalink / raw)
To: xinliang.liu, tiantao6, kong.kongxinwei, sumit.semwal,
yongqin.liu, jstultz, maarten.lankhorst, mripard, airlied, simona
Cc: dri-devel, Thomas Zimmermann, Rongrong Zou, Sean Paul,
Dmitry Baryshkov, Baihan Li, Yongbang Shi, stable
In-Reply-To: <20260420121130.200133-1-tzimmermann@suse.de>
Call drm_atomic_helper_check_plane_state() from the primary plane's
atomic-check helper and replace the custom implementation.
All plane's implementations of atomic_check should call the shared
_check_plane_state() helper first. It adjusts the plane state for
correct positioning, rotation and scaling of the plane. Do this
even if the plane's CRTC has been disabled by setting the parameter
can_update_disabled. The original code returned early in this case,
but it's safe to so and cleaner to have all plane state initialized.
As we don't set can_position, drm_atomic_helper_check_plane_state()'s
visibility check tests if the plane covers all of the CRTC. This is
a small change from the original code, which tested if the plane is
exactly the size of the CRTC. With the new test, the plane still has
to cover all of the CRTC, but can be larger than the CRTC's size. A
later patch can fully implement this feature in hibmc.
If the plane is disabled, the helper clears the visibility flag in the
plane state. On errors or if the plane is not visible, the atomic-check
helper can return early. Implement all this in hibmc and drop the custom
code that does some of it.
v2:
- extend the commit description (Yongbang)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine")
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Dmitry Baryshkov <lumag@kernel.org>
Cc: Baihan Li <libaihan@huawei.com>
Cc: Yongbang Shi <shiyongbang@huawei.com>
Cc: <stable@vger.kernel.org> # v4.10+
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 46 ++++++-------------
1 file changed, 14 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 89bed78f1466..8fa2a95bcdd1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -55,46 +55,28 @@ static const struct hibmc_dislay_pll_config hibmc_pll_table[] = {
static int hibmc_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
- struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state,
- plane);
- struct drm_framebuffer *fb = new_plane_state->fb;
- struct drm_crtc *crtc = new_plane_state->crtc;
- struct drm_crtc_state *crtc_state;
- u32 src_w = new_plane_state->src_w >> 16;
- u32 src_h = new_plane_state->src_h >> 16;
-
- if (!crtc || !fb)
- return 0;
+ struct drm_plane_state *new_plane_state =
+ drm_atomic_get_new_plane_state(state, plane);
+ struct drm_crtc_state *new_crtc_state = NULL;
+ int ret;
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state))
- return PTR_ERR(crtc_state);
+ if (new_plane_state->crtc)
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, new_plane_state->crtc);
- if (src_w != new_plane_state->crtc_w || src_h != new_plane_state->crtc_h) {
- drm_dbg_atomic(plane->dev, "scale not support\n");
- return -EINVAL;
- }
-
- if (new_plane_state->crtc_x < 0 || new_plane_state->crtc_y < 0) {
- drm_dbg_atomic(plane->dev, "crtc_x/y of drm_plane state is invalid\n");
- return -EINVAL;
- }
-
- if (!crtc_state->enable)
+ ret = drm_atomic_helper_check_plane_state(new_plane_state, new_crtc_state,
+ DRM_PLANE_NO_SCALING,
+ DRM_PLANE_NO_SCALING,
+ false, true);
+ if (ret)
+ return ret;
+ else if (!new_plane_state->visible)
return 0;
- if (new_plane_state->crtc_x + new_plane_state->crtc_w >
- crtc_state->adjusted_mode.hdisplay ||
- new_plane_state->crtc_y + new_plane_state->crtc_h >
- crtc_state->adjusted_mode.vdisplay) {
- drm_dbg_atomic(plane->dev, "visible portion of plane is invalid\n");
- return -EINVAL;
- }
-
if (new_plane_state->fb->pitches[0] % 128 != 0) {
drm_dbg_atomic(plane->dev, "wrong stride with 128-byte aligned\n");
return -EINVAL;
}
+
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/4] drm/hibmc: Fix list of formats on the primary plane
From: Thomas Zimmermann @ 2026-04-20 12:09 UTC (permalink / raw)
To: xinliang.liu, tiantao6, kong.kongxinwei, sumit.semwal,
yongqin.liu, jstultz, maarten.lankhorst, mripard, airlied, simona
Cc: dri-devel, Thomas Zimmermann, Yongbang Shi, Rongrong Zou,
Sean Paul, Dmitry Baryshkov, Baihan Li, stable
In-Reply-To: <20260420121130.200133-1-tzimmermann@suse.de>
Remove all formats from the primary plane that are unsupported for
various reasons.
* Formats with alpha channel: planes should not announce alpha channels
unless they support transparency. There's no transparency support in
the primary plane's implementation.
* Formats with BGR order. The common format is in RGB channel order.
There's no BGR support in the primary plane's implementation.
* RGB888: atomic_update programs the format from cpp[0] * 8 / 16. For
RGB888's cpp value of 3 this returns 1.5; rounded to 1. Programming
the value of 1 to HIBMC_CRT_DISP_CTL_FORMAT sets up RGB565. Hence, the
output is distorted. This can be tested by booting with video=1024x768-24.
Removing all unsupported formats leaves XRGB8888 and RGB565. Both of
which are supported and work correctly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: da52605eea8f ("drm/hisilicon/hibmc: Add support for display engine")
Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Dmitry Baryshkov <lumag@kernel.org>
Cc: Yongbang Shi <shiyongbang@huawei.com>
Cc: Baihan Li <libaihan@huawei.com>
Cc: <stable@vger.kernel.org> # v4.10+
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 8fa2a95bcdd1..c4f9ebd9250d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -118,10 +118,8 @@ static void hibmc_plane_atomic_update(struct drm_plane *plane,
}
static const u32 channel_formats1[] = {
- DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
- DRM_FORMAT_BGR888, DRM_FORMAT_XRGB8888, DRM_FORMAT_XBGR8888,
- DRM_FORMAT_RGBA8888, DRM_FORMAT_BGRA8888, DRM_FORMAT_ARGB8888,
- DRM_FORMAT_ABGR8888
+ DRM_FORMAT_XRGB8888,
+ DRM_FORMAT_RGB565,
};
static const struct drm_plane_funcs hibmc_plane_funcs = {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] vmalloc: fix buffer overflow in vrealloc_node_align()
From: Uladzislau Rezki @ 2026-04-20 12:17 UTC (permalink / raw)
To: Marco Elver
Cc: Vlastimil Babka, Andrew Morton, Uladzislau Rezki, linux-mm,
linux-kernel, kasan-dev, Vitaly Wool, stable, Harry Yoo (Oracle)
In-Reply-To: <20260420114805.3572606-2-elver@google.com>
On Mon, Apr 20, 2026 at 01:47:26PM +0200, Marco Elver wrote:
> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.
>
> Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
> Cc: <stable@vger.kernel.org>
> Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8b1124158f54 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> return NULL;
>
> if (p) {
> - memcpy(n, p, old_size);
> + memcpy(n, p, min(size, old_size));
> vfree(p);
> }
>
> --
> 2.54.0.rc1.513.gad8abe7a5a-goog
>
Agree with a problem described in commit message:
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Thank you for fixing it!
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH 5.15.y] PCI/ACPI: Restrict program_hpx_type2() to AER bits
From: Haakon Bugge @ 2026-04-20 12:20 UTC (permalink / raw)
To: stable@vger.kernel.org; +Cc: Bjorn Helgaas
In-Reply-To: <20260311171736.343422-1-haakon.bugge@oracle.com>
> commit 9abf79c8d7b40db0e5a34aa8c744ea60ff9a3fcf upstream.
>
> Previously program_hpx_type2() applied PCIe settings unconditionally,
> which could incorrectly change bits like Extended Tag Field Enable and
> Enable Relaxed Ordering.
>
> When _HPX was added to ACPI r3.0, the intent of the PCIe Setting
> Record (Type 2) in sec 6.2.7.3 was to configure AER registers when the
> OS does not own the AER Capability:
>
> The PCI Express setting record contains ... [the AER] Uncorrectable
> Error Mask, Uncorrectable Error Severity, Correctable Error Mask
> ... to be used when configuring registers in the Advanced Error
> Reporting Extended Capability Structure ...
>
> OSPM [1] will only evaluate _HPX with Setting Record – Type 2 if
> OSPM is not controlling the PCI Express Advanced Error Reporting
> capability.
>
> ACPI r3.0b, sec 6.2.7.3, added more AER registers, including registers
> in the PCIe Capability with AER-related bits, and the restriction that
> the OS use this only when it owns PCIe native hotplug:
>
> ... when configuring PCI Express registers in the Advanced Error
> Reporting Extended Capability Structure *or PCI Express Capability
> Structure* ...
>
> An OS that has assumed ownership of native hot plug but does not
> ... have ownership of the AER register set must use ... the Type 2
> record to program the AER registers ...
>
> However, since the Type 2 record also includes register bits that
> have functions other than AER, the OS must ignore values ... that
> are not applicable.
>
> Restrict program_hpx_type2() to only the intended purpose:
>
> - Apply settings only when OS owns PCIe native hotplug but not AER,
>
> - Only touch the AER-related bits (Error Reporting Enables) in Device
> Control
>
> - Don't touch Link Control at all, since nothing there seems AER-related,
> but log _HPX settings for debugging purposes
>
> Note that Read Completion Boundary is now configured elsewhere, since it is
> unrelated to _HPX.
>
> [1] Operating System-directed configuration and Power Management
>
> Fixes: 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters")
> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260129175237.727059-3-haakon.bugge@oracle.com
> [ Conflict in drivers/pci.h because the context has changed. ]
> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
I see this was not added to 5.15.203, hence a gentle ping on it.
Thxs, Håkon
> ---
> drivers/pci/pci-acpi.c | 59 +++++++++++++++++-------------------------
> drivers/pci/pci.h | 3 +++
> drivers/pci/pcie/aer.c | 3 ---
> 3 files changed, 27 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 268ca998443af..5e86038f2ea5f 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -245,21 +245,6 @@ static acpi_status decode_type1_hpx_record(union acpi_object *record,
> return AE_OK;
> }
>
> -static bool pcie_root_rcb_set(struct pci_dev *dev)
> -{
> - struct pci_dev *rp = pcie_find_root_port(dev);
> - u16 lnkctl;
> -
> - if (!rp)
> - return false;
> -
> - pcie_capability_read_word(rp, PCI_EXP_LNKCTL, &lnkctl);
> - if (lnkctl & PCI_EXP_LNKCTL_RCB)
> - return true;
> -
> - return false;
> -}
> -
> /* _HPX PCI Express Setting Record (Type 2) */
> struct hpx_type2 {
> u32 revision;
> @@ -285,6 +270,7 @@ static void program_hpx_type2(struct pci_dev *dev, struct hpx_type2 *hpx)
> {
> int pos;
> u32 reg32;
> + const struct pci_host_bridge *host;
>
> if (!hpx)
> return;
> @@ -292,6 +278,15 @@ static void program_hpx_type2(struct pci_dev *dev, struct hpx_type2 *hpx)
> if (!pci_is_pcie(dev))
> return;
>
> + host = pci_find_host_bridge(dev->bus);
> +
> + /*
> + * Only do the _HPX Type 2 programming if OS owns PCIe native
> + * hotplug but not AER.
> + */
> + if (!host->native_pcie_hotplug || host->native_aer)
> + return;
> +
> if (hpx->revision > 1) {
> pci_warn(dev, "PCIe settings rev %d not supported\n",
> hpx->revision);
> @@ -299,33 +294,27 @@ static void program_hpx_type2(struct pci_dev *dev, struct hpx_type2 *hpx)
> }
>
> /*
> - * Don't allow _HPX to change MPS or MRRS settings. We manage
> - * those to make sure they're consistent with the rest of the
> - * platform.
> + * We only allow _HPX to program DEVCTL bits related to AER, namely
> + * PCI_EXP_DEVCTL_CERE, PCI_EXP_DEVCTL_NFERE, PCI_EXP_DEVCTL_FERE,
> + * and PCI_EXP_DEVCTL_URRE.
> + *
> + * The rest of DEVCTL is managed by the OS to make sure it's
> + * consistent with the rest of the platform.
> */
> - hpx->pci_exp_devctl_and |= PCI_EXP_DEVCTL_PAYLOAD |
> - PCI_EXP_DEVCTL_READRQ;
> - hpx->pci_exp_devctl_or &= ~(PCI_EXP_DEVCTL_PAYLOAD |
> - PCI_EXP_DEVCTL_READRQ);
> + hpx->pci_exp_devctl_and |= ~PCI_EXP_AER_FLAGS;
> + hpx->pci_exp_devctl_or &= PCI_EXP_AER_FLAGS;
>
> /* Initialize Device Control Register */
> pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
> ~hpx->pci_exp_devctl_and, hpx->pci_exp_devctl_or);
>
> - /* Initialize Link Control Register */
> + /* Log if _HPX attempts to modify Link Control Register */
> if (pcie_cap_has_lnkctl(dev)) {
> -
> - /*
> - * If the Root Port supports Read Completion Boundary of
> - * 128, set RCB to 128. Otherwise, clear it.
> - */
> - hpx->pci_exp_lnkctl_and |= PCI_EXP_LNKCTL_RCB;
> - hpx->pci_exp_lnkctl_or &= ~PCI_EXP_LNKCTL_RCB;
> - if (pcie_root_rcb_set(dev))
> - hpx->pci_exp_lnkctl_or |= PCI_EXP_LNKCTL_RCB;
> -
> - pcie_capability_clear_and_set_word(dev, PCI_EXP_LNKCTL,
> - ~hpx->pci_exp_lnkctl_and, hpx->pci_exp_lnkctl_or);
> + if (hpx->pci_exp_lnkctl_and != 0xffff ||
> + hpx->pci_exp_lnkctl_or != 0)
> + pci_info(dev, "_HPX attempts Link Control setting (AND %#06x OR %#06x)\n",
> + hpx->pci_exp_lnkctl_and,
> + hpx->pci_exp_lnkctl_or);
> }
>
> /* Find Advanced Error Reporting Enhanced Capability */
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index d9d7a79e3563e..e1614c8dc04bb 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -11,6 +11,9 @@
>
> #define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
>
> +#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE | PCI_EXP_DEVCTL_NFERE | \
> + PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
> +
> extern const unsigned char pcie_link_speed[];
> extern bool pci_early_dump;
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index a8bec1c3c769a..9b86df5b82359 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -214,9 +214,6 @@ void pcie_ecrc_get_policy(char *str)
> }
> #endif /* CONFIG_PCIE_ECRC */
>
> -#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE | PCI_EXP_DEVCTL_NFERE | \
> - PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
> -
> int pcie_aer_is_native(struct pci_dev *dev)
> {
> struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
> --
> 2.43.5
^ permalink raw reply
* Re: [PATCH] vmalloc: fix buffer overflow in vrealloc_node_align()
From: Vlastimil Babka (SUSE) @ 2026-04-20 12:21 UTC (permalink / raw)
To: Marco Elver, Andrew Morton
Cc: Uladzislau Rezki, linux-mm, linux-kernel, kasan-dev, Vitaly Wool,
stable, Harry Yoo (Oracle)
In-Reply-To: <20260420114805.3572606-2-elver@google.com>
On 4/20/26 13:47, Marco Elver wrote:
> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.
>
> Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
> Cc: <stable@vger.kernel.org>
> Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
> Signed-off-by: Marco Elver <elver@google.com>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8b1124158f54 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> return NULL;
>
> if (p) {
> - memcpy(n, p, old_size);
> + memcpy(n, p, min(size, old_size));
> vfree(p);
> }
>
^ permalink raw reply
* Re: [PATCH 5.15.y] PCI/ACPI: Restrict program_hpx_type2() to AER bits
From: Greg KH @ 2026-04-20 12:32 UTC (permalink / raw)
To: Haakon Bugge; +Cc: stable@vger.kernel.org, Bjorn Helgaas
In-Reply-To: <7226713B-8871-40FA-BAA1-6AC5E516AF46@oracle.com>
On Mon, Apr 20, 2026 at 12:20:05PM +0000, Haakon Bugge wrote:
> > commit 9abf79c8d7b40db0e5a34aa8c744ea60ff9a3fcf upstream.
> >
> > Previously program_hpx_type2() applied PCIe settings unconditionally,
> > which could incorrectly change bits like Extended Tag Field Enable and
> > Enable Relaxed Ordering.
> >
> > When _HPX was added to ACPI r3.0, the intent of the PCIe Setting
> > Record (Type 2) in sec 6.2.7.3 was to configure AER registers when the
> > OS does not own the AER Capability:
> >
> > The PCI Express setting record contains ... [the AER] Uncorrectable
> > Error Mask, Uncorrectable Error Severity, Correctable Error Mask
> > ... to be used when configuring registers in the Advanced Error
> > Reporting Extended Capability Structure ...
> >
> > OSPM [1] will only evaluate _HPX with Setting Record – Type 2 if
> > OSPM is not controlling the PCI Express Advanced Error Reporting
> > capability.
> >
> > ACPI r3.0b, sec 6.2.7.3, added more AER registers, including registers
> > in the PCIe Capability with AER-related bits, and the restriction that
> > the OS use this only when it owns PCIe native hotplug:
> >
> > ... when configuring PCI Express registers in the Advanced Error
> > Reporting Extended Capability Structure *or PCI Express Capability
> > Structure* ...
> >
> > An OS that has assumed ownership of native hot plug but does not
> > ... have ownership of the AER register set must use ... the Type 2
> > record to program the AER registers ...
> >
> > However, since the Type 2 record also includes register bits that
> > have functions other than AER, the OS must ignore values ... that
> > are not applicable.
> >
> > Restrict program_hpx_type2() to only the intended purpose:
> >
> > - Apply settings only when OS owns PCIe native hotplug but not AER,
> >
> > - Only touch the AER-related bits (Error Reporting Enables) in Device
> > Control
> >
> > - Don't touch Link Control at all, since nothing there seems AER-related,
> > but log _HPX settings for debugging purposes
> >
> > Note that Read Completion Boundary is now configured elsewhere, since it is
> > unrelated to _HPX.
> >
> > [1] Operating System-directed configuration and Power Management
> >
> > Fixes: 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters")
> > Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > Link: https://patch.msgid.link/20260129175237.727059-3-haakon.bugge@oracle.com
> > [ Conflict in drivers/pci.h because the context has changed. ]
> > Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
>
> I see this was not added to 5.15.203, hence a gentle ping on it.
The backlog for manually backported 5.15.y patches right now is over 100
patches long. You are in good company :)
thanks,
greg k-h
^ permalink raw reply
* sashiko.dev review (Re: [PATCH v4 01/17] dmaengine: sh: rz-dmac: Move interrupt request after everything is set up)
From: Claudiu Beznea @ 2026-04-20 12:33 UTC (permalink / raw)
To: vkoul, Frank.Li, lgirdwood, broonie, perex, tiwai, biju.das.jz,
prabhakar.mahadev-lad.rj, p.zabel, geert+renesas,
fabrizio.castro.jz, long.luu.ur
Cc: dmaengine, linux-kernel, linux-sound, linux-renesas-soc,
Claudiu Beznea, stable
In-Reply-To: <20260411114303.2814115-2-claudiu.beznea.uj@bp.renesas.com>
> commit b3dfdd5fbd2463db407b1396ee1ae79801cb96bf
> Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> dmaengine: sh: rz-dmac: Move interrupt request after everything is set up
> This patch moves the channel interrupt request to the end of the channel
> probe function to prevent the IRQ handler from accessing uninitialized
> data. It also replaces dma_alloc_coherent() with dmam_alloc_coherent()
> to simplify the error path.
> > diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
> > index 625ff29024de0..9f206a33dcc6b 100644
> > --- a/drivers/dma/sh/rz-dmac.c
> > +++ b/drivers/dma/sh/rz-dmac.c
> [ ... ]
> > @@ -1210,16 +1207,6 @@ static int rz_dmac_probe(struct platform_device *pdev)
> > dma_register_err:
> > of_dma_controller_free(pdev->dev.of_node);
> > err:
> > - channel_num = i ? i - 1 : 0;
> > - for (i = 0; i < channel_num; i++) {
> > - struct rz_dmac_chan *channel = &dmac->channels[i];
> > -
> > - dma_free_coherent(&pdev->dev,
> > - sizeof(struct rz_lmdesc) * DMAC_NR_LMDESC,
> > - channel->lmdesc.base,
> > - channel->lmdesc.base_dma);
> > - }
> > -
> > reset_control_assert(dmac->rstc);
> > err_pm_runtime_put:
> > pm_runtime_put(&pdev->dev);
> > @@ -1232,18 +1219,9 @@ static int rz_dmac_probe(struct platform_device *pdev)
> > static void rz_dmac_remove(struct platform_device *pdev)
> > {
> > struct rz_dmac *dmac = platform_get_drvdata(pdev);
> > - unsigned int i;
> >
> > dma_async_device_unregister(&dmac->engine);
> > of_dma_controller_free(pdev->dev.of_node);
> > - for (i = 0; i < dmac->n_channels; i++) {
> > - struct rz_dmac_chan *channel = &dmac->channels[i];
> > -
> > - dma_free_coherent(&pdev->dev,
> > - sizeof(struct rz_lmdesc) * DMAC_NR_LMDESC,
> > - channel->lmdesc.base,
> > - channel->lmdesc.base_dma);
> > - }
> > reset_control_assert(dmac->rstc);
> > pm_runtime_put(&pdev->dev);
> > pm_runtime_disable(&pdev->dev);
> > }
> While this patch fixes the initialization races, does it leave a similar
> vulnerability exposed during teardown?
> Since devm_request_threaded_irq() is used to allocate the interrupts, they
> will remain active until after rz_dmac_remove() and the rz_dmac_probe() error
> paths complete.
> If an interrupt fires during or just after rz_dmac_remove(), could the handler
> attempt to access hardware registers while the device is in reset or powered
> down by pm_runtime_put()?
> Would it be safer to explicitly free or disable the IRQs before asserting the
> hardware reset and disabling runtime PM, or perhaps manage the reset and PM
> states via devm actions to guarantee correct teardown ordering?
On either failure or remove path the device is with runtime PM put (clocks being
disabled) and in reset state. The controller cannot generate interrupts from
this state.
However, to keep this series simple, I'll add this in a cleanup patch after the
current series will be merged.
^ permalink raw reply
* Re: [PATCH 6.6.y] iio: common: st_sensors: Fix use of uninitialize device structs
From: Jonathan Cameron @ 2026-04-20 12:41 UTC (permalink / raw)
To: Fang Wang
Cc: maudspierings, gregkh, stable, patches, linux-kernel, lars,
dimitri.fedrau, markus.koeniger, andy, linux-iio,
Jonathan.Cameron
In-Reply-To: <tencent_B4E5A4D17E67F7C7096F7BF8A4C701223008@qq.com>
On Tue, 14 Apr 2026 14:45:53 +0800
Fang Wang <32840572@qq.com> wrote:
> From: Maud Spierings <maudspierings@gocontroll.com>
>
> [ Upstream commit 9f92e93e257b33e73622640a9205f8642ec16ddd ]
>
> Throughout the various probe functions &indio_dev->dev is used before it
> is initialized.
Looking at this again, I'm not sure what exactly what meant by 'initialized'
given device_initialize() has definitely been called on indio_dev->dev
as that's part of the allocation functions.
What this is actually about is device private structure (dev->p) being initialized
which are only done on device_add.
Given the struct device in the iio_dev is always the wrong thing to use
for messages (as it's not very informative if nothing else) this is fine.
So if not picked up already
Acked-by: Jonathan Cameron <jic23@kernel.org>
>This caused a kernel panic in st_sensors_power_enable()
> when the call to devm_regulator_bulk_get_enable() fails and then calls
> dev_err_probe() with the uninitialized device.
>
> This seems to only cause a panic with dev_err_probe(), dev_err(),
> dev_warn() and dev_info() don't seem to cause a panic, but are fixed
> as well.
>
> The issue is reported and traced here: [1]
>
> Link: https://lore.kernel.org/all/AM7P189MB100986A83D2F28AF3FFAF976E39EA@AM7P189MB1009.EURP189.PROD.OUTLOOK.COM/ [1]
> Cc: stable@vger.kernel.org
> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
> Reviewed-by: Andy Shevchenko <andy@kernel.org>
> Link: https://... [1]
> Link: https://patch.msgid.link/20250527-st_iio_fix-v4-1-12d89801c761@gocontroll.com
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Fang Wang <32840572@qq.com>
> ---
> drivers/iio/accel/st_accel_core.c | 10 +++---
> .../iio/common/st_sensors/st_sensors_core.c | 36 +++++++++----------
> .../common/st_sensors/st_sensors_trigger.c | 20 +++++------
> 3 files changed, 31 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c
> index 51d8de18e6d6..45d2268e042e 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -1342,6 +1342,7 @@ static int apply_acpi_orientation(struct iio_dev *indio_dev)
> union acpi_object *ont;
> union acpi_object *elements;
> acpi_status status;
> + struct device *parent = indio_dev->dev.parent;
> int ret = -EINVAL;
> unsigned int val;
> int i, j;
> @@ -1360,7 +1361,7 @@ static int apply_acpi_orientation(struct iio_dev *indio_dev)
> };
>
>
> - adev = ACPI_COMPANION(indio_dev->dev.parent);
> + adev = ACPI_COMPANION(parent);
> if (!adev)
> return -ENXIO;
>
> @@ -1369,8 +1370,7 @@ static int apply_acpi_orientation(struct iio_dev *indio_dev)
> if (status == AE_NOT_FOUND) {
> return -ENXIO;
> } else if (ACPI_FAILURE(status)) {
> - dev_warn(&indio_dev->dev, "failed to execute _ONT: %d\n",
> - status);
> + dev_warn(parent, "failed to execute _ONT: %d\n", status);
> return status;
> }
>
> @@ -1446,12 +1446,12 @@ static int apply_acpi_orientation(struct iio_dev *indio_dev)
> }
>
> ret = 0;
> - dev_info(&indio_dev->dev, "computed mount matrix from ACPI\n");
> + dev_info(parent, "computed mount matrix from ACPI\n");
>
> out:
> kfree(buffer.pointer);
> if (ret)
> - dev_dbg(&indio_dev->dev,
> + dev_dbg(parent,
> "failed to apply ACPI orientation data: %d\n", ret);
>
> return ret;
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c b/drivers/iio/common/st_sensors/st_sensors_core.c
> index c77d7bdcc121..78f5728417d5 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -154,7 +154,7 @@ static int st_sensors_set_fullscale(struct iio_dev *indio_dev, unsigned int fs)
> return err;
>
> st_accel_set_fullscale_error:
> - dev_err(&indio_dev->dev, "failed to set new fullscale.\n");
> + dev_err(indio_dev->dev.parent, "failed to set new fullscale.\n");
> return err;
> }
>
> @@ -231,8 +231,7 @@ int st_sensors_power_enable(struct iio_dev *indio_dev)
> ARRAY_SIZE(regulator_names),
> regulator_names);
> if (err)
> - return dev_err_probe(&indio_dev->dev, err,
> - "unable to enable supplies\n");
> + return dev_err_probe(parent, err, "unable to enable supplies\n");
>
> return 0;
> }
> @@ -241,13 +240,14 @@ EXPORT_SYMBOL_NS(st_sensors_power_enable, IIO_ST_SENSORS);
> static int st_sensors_set_drdy_int_pin(struct iio_dev *indio_dev,
> struct st_sensors_platform_data *pdata)
> {
> + struct device *parent = indio_dev->dev.parent;
> struct st_sensor_data *sdata = iio_priv(indio_dev);
>
> /* Sensor does not support interrupts */
> if (!sdata->sensor_settings->drdy_irq.int1.addr &&
> !sdata->sensor_settings->drdy_irq.int2.addr) {
> if (pdata->drdy_int_pin)
> - dev_info(&indio_dev->dev,
> + dev_info(parent,
> "DRDY on pin INT%d specified, but sensor does not support interrupts\n",
> pdata->drdy_int_pin);
> return 0;
> @@ -256,29 +256,27 @@ static int st_sensors_set_drdy_int_pin(struct iio_dev *indio_dev,
> switch (pdata->drdy_int_pin) {
> case 1:
> if (!sdata->sensor_settings->drdy_irq.int1.mask) {
> - dev_err(&indio_dev->dev,
> - "DRDY on INT1 not available.\n");
> + dev_err(parent, "DRDY on INT1 not available.\n");
> return -EINVAL;
> }
> sdata->drdy_int_pin = 1;
> break;
> case 2:
> if (!sdata->sensor_settings->drdy_irq.int2.mask) {
> - dev_err(&indio_dev->dev,
> - "DRDY on INT2 not available.\n");
> + dev_err(parent, "DRDY on INT2 not available.\n");
> return -EINVAL;
> }
> sdata->drdy_int_pin = 2;
> break;
> default:
> - dev_err(&indio_dev->dev, "DRDY on pdata not valid.\n");
> + dev_err(parent, "DRDY on pdata not valid.\n");
> return -EINVAL;
> }
>
> if (pdata->open_drain) {
> if (!sdata->sensor_settings->drdy_irq.int1.addr_od &&
> !sdata->sensor_settings->drdy_irq.int2.addr_od)
> - dev_err(&indio_dev->dev,
> + dev_err(parent,
> "open drain requested but unsupported.\n");
> else
> sdata->int_pin_open_drain = true;
> @@ -336,6 +334,7 @@ EXPORT_SYMBOL_NS(st_sensors_dev_name_probe, IIO_ST_SENSORS);
> int st_sensors_init_sensor(struct iio_dev *indio_dev,
> struct st_sensors_platform_data *pdata)
> {
> + struct device *parent = indio_dev->dev.parent;
> struct st_sensor_data *sdata = iio_priv(indio_dev);
> struct st_sensors_platform_data *of_pdata;
> int err = 0;
> @@ -343,7 +342,7 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> mutex_init(&sdata->odr_lock);
>
> /* If OF/DT pdata exists, it will take precedence of anything else */
> - of_pdata = st_sensors_dev_probe(indio_dev->dev.parent, pdata);
> + of_pdata = st_sensors_dev_probe(parent, pdata);
> if (IS_ERR(of_pdata))
> return PTR_ERR(of_pdata);
> if (of_pdata)
> @@ -370,7 +369,7 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> if (err < 0)
> return err;
> } else
> - dev_info(&indio_dev->dev, "Full-scale not possible\n");
> + dev_info(parent, "Full-scale not possible\n");
>
> err = st_sensors_set_odr(indio_dev, sdata->odr);
> if (err < 0)
> @@ -405,7 +404,7 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> mask = sdata->sensor_settings->drdy_irq.int2.mask_od;
> }
>
> - dev_info(&indio_dev->dev,
> + dev_info(parent,
> "set interrupt line to open drain mode on pin %d\n",
> sdata->drdy_int_pin);
> err = st_sensors_write_data_with_mask(indio_dev, addr,
> @@ -594,21 +593,20 @@ EXPORT_SYMBOL_NS(st_sensors_get_settings_index, IIO_ST_SENSORS);
> int st_sensors_verify_id(struct iio_dev *indio_dev)
> {
> struct st_sensor_data *sdata = iio_priv(indio_dev);
> + struct device *parent = indio_dev->dev.parent;
> int wai, err;
>
> if (sdata->sensor_settings->wai_addr) {
> err = regmap_read(sdata->regmap,
> sdata->sensor_settings->wai_addr, &wai);
> if (err < 0) {
> - dev_err(&indio_dev->dev,
> - "failed to read Who-Am-I register.\n");
> - return err;
> + return dev_err_probe(parent, err,
> + "failed to read Who-Am-I register.\n");
> }
>
> if (sdata->sensor_settings->wai != wai) {
> - dev_err(&indio_dev->dev,
> - "%s: WhoAmI mismatch (0x%x).\n",
> - indio_dev->name, wai);
> + dev_warn(parent, "%s: WhoAmI mismatch (0x%x).\n",
> + indio_dev->name, wai);
> return -EINVAL;
> }
> }
> diff --git a/drivers/iio/common/st_sensors/st_sensors_trigger.c b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> index a0df9250a69f..b900acd471bd 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_trigger.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_trigger.c
> @@ -127,7 +127,7 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> sdata->trig = devm_iio_trigger_alloc(parent, "%s-trigger",
> indio_dev->name);
> if (sdata->trig == NULL) {
> - dev_err(&indio_dev->dev, "failed to allocate iio trigger.\n");
> + dev_err(parent, "failed to allocate iio trigger.\n");
> return -ENOMEM;
> }
>
> @@ -143,7 +143,7 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> case IRQF_TRIGGER_FALLING:
> case IRQF_TRIGGER_LOW:
> if (!sdata->sensor_settings->drdy_irq.addr_ihl) {
> - dev_err(&indio_dev->dev,
> + dev_err(parent,
> "falling/low specified for IRQ but hardware supports only rising/high: will request rising/high\n");
> if (irq_trig == IRQF_TRIGGER_FALLING)
> irq_trig = IRQF_TRIGGER_RISING;
> @@ -156,21 +156,19 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> sdata->sensor_settings->drdy_irq.mask_ihl, 1);
> if (err < 0)
> return err;
> - dev_info(&indio_dev->dev,
> + dev_info(parent,
> "interrupts on the falling edge or active low level\n");
> }
> break;
> case IRQF_TRIGGER_RISING:
> - dev_info(&indio_dev->dev,
> - "interrupts on the rising edge\n");
> + dev_info(parent, "interrupts on the rising edge\n");
> break;
> case IRQF_TRIGGER_HIGH:
> - dev_info(&indio_dev->dev,
> - "interrupts active high level\n");
> + dev_info(parent, "interrupts active high level\n");
> break;
> default:
> /* This is the most preferred mode, if possible */
> - dev_err(&indio_dev->dev,
> + dev_err(parent,
> "unsupported IRQ trigger specified (%lx), enforce rising edge\n", irq_trig);
> irq_trig = IRQF_TRIGGER_RISING;
> }
> @@ -179,7 +177,7 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> if (irq_trig == IRQF_TRIGGER_FALLING ||
> irq_trig == IRQF_TRIGGER_RISING) {
> if (!sdata->sensor_settings->drdy_irq.stat_drdy.addr) {
> - dev_err(&indio_dev->dev,
> + dev_err(parent,
> "edge IRQ not supported w/o stat register.\n");
> return -EOPNOTSUPP;
> }
> @@ -214,13 +212,13 @@ int st_sensors_allocate_trigger(struct iio_dev *indio_dev,
> sdata->trig->name,
> sdata->trig);
> if (err) {
> - dev_err(&indio_dev->dev, "failed to request trigger IRQ.\n");
> + dev_err(parent, "failed to request trigger IRQ.\n");
> return err;
> }
>
> err = devm_iio_trigger_register(parent, sdata->trig);
> if (err < 0) {
> - dev_err(&indio_dev->dev, "failed to register iio trigger.\n");
> + dev_err(parent, "failed to register iio trigger.\n");
> return err;
> }
> indio_dev->trig = iio_trigger_get(sdata->trig);
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-04-20 12:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <islxoe4wbqx5pl54difetdcl5lrqvfd5ysbaicxz5lv235sfmd@6hwrq3rmqx7c>
On 3/20/2026 2:36 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 02, 2026 at 04:28:29PM +0800, Yongxing Mou wrote:
>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>> The current driver doesn't fully support every combo PHY mode and use
>> either the eDP or DP table when enable the platform. In addition, some
>> platforms mismatch between the mode and the table where DP mode uses
>> the eDP table or eDP mode use the DP table.
>>
>> Clean up and correct the tables for currently supported platforms based on
>> the HPG specification.
>>
>> Here lists the tables can be reused across current platforms.
>> DP mode：
>> -sa8775p/sc7280/sc8280xp/x1e80100
>> -glymur
>> eDP mode(low vdiff):
>
> Separate question: should we extend phy_configure_dp_opts with the
> low/high vdiff? Is there a point in providing the ability to toggle
> between low vdiff and high vdiff?
>
Emm ,i haven't found any platform using high vdiff so far, and I'm not
clear in which cases switching between low and high vdiff would be needed.
>> -glymur/sa8775p/sc8280xp/x1e80100
>> -sc7280
>
> I understand your wish to perform all the changes in a single patch, but
> there is one problem with that. Consider this patch regresses one of the
> platforms (I'm looking at Kodiak and SC8180X as they get the biggest set
> of changes). It would be almost impossible to separate, which particular
> change caused the regression. I'd suggest splitting this patch into a
> set of more atomic changes. E.g. the AUX_CFG8 is definitely a separate
> change. Writing swing / pre_emph tables on Kodiak and SC8180X is a
> separate change (or two). Switching each of the platforms to the
> corrected set of tables ideally also should come as a separate change,
> so that in case of a regression the issue would be easier to identify.
>
Thank for point this, will separate the change.
I mostly overlooked SC8180X here, since I assumed it shares the same PHY
as SC7280. However, they are using different PHY sub‑versions. Will add
proper support for it in the next version.
>>
>> Cc: stable@vger.kernel.org
>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-edp.c | 90 ++++++++++++++++++++++---------------
>> 1 file changed, 53 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
>> index 7372de05a0b8..36998326bae6 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
>> @@ -87,7 +87,8 @@ struct qcom_edp_phy_cfg {
>> bool is_edp;
>> const u8 *aux_cfg;
>> const u8 *vco_div_cfg;
>> - const struct qcom_edp_swing_pre_emph_cfg *swing_pre_emph_cfg;
>> + const struct qcom_edp_swing_pre_emph_cfg *dp_swing_pre_emph_cfg;
>> + const struct qcom_edp_swing_pre_emph_cfg *edp_swing_pre_emph_cfg;
>> const struct phy_ver_ops *ver_ops;
>> };
>>
>> @@ -116,17 +117,17 @@ struct qcom_edp {
>> };
>>
>> static const u8 dp_swing_hbr_rbr[4][4] = {
>> - { 0x08, 0x0f, 0x16, 0x1f },
>> + { 0x07, 0x0f, 0x16, 0x1f },
>> { 0x11, 0x1e, 0x1f, 0xff },
>> { 0x16, 0x1f, 0xff, 0xff },
>> { 0x1f, 0xff, 0xff, 0xff }
>> };
>>
>> static const u8 dp_pre_emp_hbr_rbr[4][4] = {
>> - { 0x00, 0x0d, 0x14, 0x1a },
>> + { 0x00, 0x0e, 0x15, 0x1a },
>> { 0x00, 0x0e, 0x15, 0xff },
>> { 0x00, 0x0e, 0xff, 0xff },
>> - { 0x03, 0xff, 0xff, 0xff }
>> + { 0x04, 0xff, 0xff, 0xff }
>> };
>
> I've checked, at least this table doesn't match SC8180X configuration.
>
Got it.
>>
>> static const u8 dp_swing_hbr2_hbr3[4][4] = {
>> @@ -150,6 +151,20 @@ static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg = {
>> .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
>> };
>>
>> +static const u8 dp_pre_emp_hbr_rbr_v8[4][4] = {
>> + { 0x00, 0x0e, 0x15, 0x1a },
>> + { 0x00, 0x0e, 0x15, 0xff },
>> + { 0x00, 0x0e, 0xff, 0xff },
>> + { 0x00, 0xff, 0xff, 0xff }
>> +};
>> +
>> +static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg_v8 = {
>> + .swing_hbr_rbr = &dp_swing_hbr_rbr,
>> + .swing_hbr3_hbr2 = &dp_swing_hbr2_hbr3,
>> + .pre_emphasis_hbr_rbr = &dp_pre_emp_hbr_rbr_v8,
>> + .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
>> +};
>> +
>> static const u8 edp_swing_hbr_rbr[4][4] = {
>> { 0x07, 0x0f, 0x16, 0x1f },
>> { 0x0d, 0x16, 0x1e, 0xff },
>> @@ -158,7 +173,7 @@ static const u8 edp_swing_hbr_rbr[4][4] = {
>> };
>>
>> static const u8 edp_pre_emp_hbr_rbr[4][4] = {
>> - { 0x05, 0x12, 0x17, 0x1d },
>> + { 0x05, 0x11, 0x17, 0x1d },
>
> This was changed only for Kodiak. For SC8180X, I assume, we should be
> using the older table.
>
Emm, for SC8180X, eDP low VDIFF (High HBR) only S1 (250mV) P0-0dB
Emphasis Settings "0x08" different from other "generic" tables which is
"0x0B".
>> { 0x05, 0x11, 0x18, 0xff },
>> { 0x06, 0x11, 0xff, 0xff },
>> { 0x00, 0xff, 0xff, 0xff }
>> @@ -172,10 +187,10 @@ static const u8 edp_swing_hbr2_hbr3[4][4] = {
>> };
>>
>> static const u8 edp_pre_emp_hbr2_hbr3[4][4] = {
>
> I think it becomes worth adding version to the "generic" tables. They
> are not that generic anyway.
>
Got it. SC8180X here need a different table..
>> - { 0x08, 0x11, 0x17, 0x1b },
>> - { 0x00, 0x0c, 0x13, 0xff },
>> - { 0x05, 0x10, 0xff, 0xff },
>> - { 0x00, 0xff, 0xff, 0xff }
>> + { 0x0c, 0x15, 0x19, 0x1e },
>> + { 0x0b, 0x15, 0x19, 0xff },
>> + { 0x0e, 0x14, 0xff, 0xff },
>> + { 0x0d, 0xff, 0xff, 0xff }
>
> Current table indeed doesn't match the swing table. Please take care
> about the SC8180X differences (I think, it will need separate set of
> tables).
>
Got it.
>> };
>>
>> static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg = {
>> @@ -193,25 +208,25 @@ static const u8 edp_phy_vco_div_cfg_v4[4] = {
>> 0x01, 0x01, 0x02, 0x00,
>> };
>>
>> -static const u8 edp_pre_emp_hbr_rbr_v5[4][4] = {
>> - { 0x05, 0x11, 0x17, 0x1d },
>> - { 0x05, 0x11, 0x18, 0xff },
>> - { 0x06, 0x11, 0xff, 0xff },
>> - { 0x00, 0xff, 0xff, 0xff }
>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>> + { 0x06, 0x11, 0x16, 0x1b },
>> + { 0x0b, 0x19, 0x1f, 0xff },
>> + { 0x18, 0x1f, 0xff, 0xff },
>> + { 0x1f, 0xff, 0xff, 0xff }
>> };
>>
>> -static const u8 edp_pre_emp_hbr2_hbr3_v5[4][4] = {
>> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
>> { 0x0c, 0x15, 0x19, 0x1e },
>> - { 0x0b, 0x15, 0x19, 0xff },
>> - { 0x0e, 0x14, 0xff, 0xff },
>> + { 0x09, 0x14, 0x19, 0xff },
>> + { 0x0f, 0x14, 0xff, 0xff },
>> { 0x0d, 0xff, 0xff, 0xff }
>> };
>>
>> -static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v5 = {
>> +static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v3 = {
>> .swing_hbr_rbr = &edp_swing_hbr_rbr,
>> - .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
>> - .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr_v5,
>> - .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v5,
>> + .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3_v3,
>> + .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr,
>> + .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v3,
>> };
>>
>> static const u8 edp_phy_aux_cfg_v5[DP_AUX_CFG_SIZE] = {
>> @@ -262,12 +277,7 @@ static int qcom_edp_phy_init(struct phy *phy)
>> DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
>> edp->edp + DP_PHY_PD_CTL);
>>
>> - /*
>> - * TODO: Re-work the conditions around setting the cfg8 value
>> - * when more information becomes available about why this is
>> - * even needed.
>> - */
>> - if (edp->cfg->swing_pre_emph_cfg && !edp->is_edp)
>> + if (!edp->is_edp)
>> aux_cfg[8] = 0xb7;
>
> This is a separate fix, as it changes the aux_cfg[8] value for Kodiak
> and SC8180X.
>
Got it.
>>
>> writel(0xfc, edp->edp + DP_PHY_MODE);
>> @@ -291,7 +301,7 @@ static int qcom_edp_phy_init(struct phy *phy)
>>
>> static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configure_opts_dp *dp_opts)
>> {
>> - const struct qcom_edp_swing_pre_emph_cfg *cfg = edp->cfg->swing_pre_emph_cfg;
>> + const struct qcom_edp_swing_pre_emph_cfg *cfg;
>> unsigned int v_level = 0;
>> unsigned int p_level = 0;
>> u8 ldo_config;
>> @@ -299,11 +309,10 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
>> u8 emph;
>> int i;
>>
>> - if (!cfg)
>> - return 0;
>> -
>> if (edp->is_edp)
>> - cfg = &edp_phy_swing_pre_emph_cfg;
>> + cfg = edp->cfg->edp_swing_pre_emph_cfg;
>> + else
>> + cfg = edp->cfg->dp_swing_pre_emph_cfg;
>>
>> for (i = 0; i < dp_opts->lanes; i++) {
>> v_level = max(v_level, dp_opts->voltage[i]);
>> @@ -564,20 +573,24 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
>> .is_edp = false,
>> .aux_cfg = edp_phy_aux_cfg_v5,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v4,
>> };
>>
>> static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v4,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v3,
>> .ver_ops = &qcom_edp_phy_ops_v4,
>> };
>>
>> static const struct qcom_edp_phy_cfg sc8280xp_dp_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v4,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> - .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v4,
>> };
>>
>> @@ -585,7 +598,8 @@ static const struct qcom_edp_phy_cfg sc8280xp_edp_phy_cfg = {
>> .is_edp = true,
>> .aux_cfg = edp_phy_aux_cfg_v4,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>
> Ok, we are going to continue using eDP table because of is_edp = true.
>
>> .ver_ops = &qcom_edp_phy_ops_v4,
>> };
>>
>> @@ -766,7 +780,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
>> static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v4,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> - .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v6,
>> };
>>
>> @@ -945,7 +960,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
>> static struct qcom_edp_phy_cfg glymur_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v8,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v8,
>> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
>> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg_v8,
>> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
>> .ver_ops = &qcom_edp_phy_ops_v8,
>> };
>>
>>
>> --
>> 2.43.0
>>
>>
>> --
>> linux-phy mailing list
>> linux-phy@lists.infradead.org
>> https://lists.infradead.org/mailman/listinfo/linux-phy
>
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-04-20 12:48 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Stephen Boyd,
Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <245f4589-d7ca-4d6b-8162-a86972752bd8@oss.qualcomm.com>
On 4/16/2026 5:34 PM, Konrad Dybcio wrote:
> On 3/2/26 9:28 AM, Yongxing Mou wrote:
>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>> The current driver doesn't fully support every combo PHY mode and use
>> either the eDP or DP table when enable the platform. In addition, some
>> platforms mismatch between the mode and the table where DP mode uses
>> the eDP table or eDP mode use the DP table.
>>
>> Clean up and correct the tables for currently supported platforms based on
>> the HPG specification.
>>
>> Here lists the tables can be reused across current platforms.
>> DP mode：
>> -sa8775p/sc7280/sc8280xp/x1e80100
>> -glymur
>> eDP mode(low vdiff):
>> -glymur/sa8775p/sc8280xp/x1e80100
>> -sc7280
>>
>> Cc: stable@vger.kernel.org
>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>
> I went through everything and all the sequences are OK.
>
> SC8180X will need changes, but it's already incorrect so this
> doesn't necessarily affect it
>
> Thanks!
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
Thanks here.. I didn’t notice before that SC8180X is different from
SC7280, and will correct it in the next version.
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Konrad Dybcio @ 2026-04-20 12:49 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong, Stephen Boyd,
Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <12e8a8de-49b8-463a-8b88-2cbbf1ab901c@oss.qualcomm.com>
On 4/20/26 2:48 PM, Yongxing Mou wrote:
>
>
> On 4/16/2026 5:34 PM, Konrad Dybcio wrote:
>> On 3/2/26 9:28 AM, Yongxing Mou wrote:
>>> The eDP PHY supports both eDP&DP modes, each requires a different table.
>>> The current driver doesn't fully support every combo PHY mode and use
>>> either the eDP or DP table when enable the platform. In addition, some
>>> platforms mismatch between the mode and the table where DP mode uses
>>> the eDP table or eDP mode use the DP table.
>>>
>>> Clean up and correct the tables for currently supported platforms based on
>>> the HPG specification.
>>>
>>> Here lists the tables can be reused across current platforms.
>>> DP mode：
>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>> -glymur
>>> eDP mode(low vdiff):
>>> -glymur/sa8775p/sc8280xp/x1e80100
>>> -sc7280
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>> ---
>>
>> I went through everything and all the sequences are OK.
>>
>> SC8180X will need changes, but it's already incorrect so this
>> doesn't necessarily affect it
>>
>> Thanks!
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Konrad
> Thanks here.. I didn’t notice before that SC8180X is different from SC7280, and will correct it in the next version.
Please make it another patch on top of these two, so that we don't have
to re-validate the existing diff
Konrad
^ permalink raw reply
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 7.0-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
The patch below does not apply to the 7.0-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@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-7.0.y
git checkout FETCH_HEAD
git cherry-pick -x 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042045-drool-wheat-4281@gregkh' --subject-prefix 'PATCH 7.0.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 6.19-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
The patch below does not apply to the 6.19-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@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.19.y
git checkout FETCH_HEAD
git cherry-pick -x 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042045-fountain-ebony-21f7@gregkh' --subject-prefix 'PATCH 6.19.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 6.12-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
The patch below does not apply to the 6.12-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@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.12.y
git checkout FETCH_HEAD
git cherry-pick -x 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042046-anime-babied-0905@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 6.18-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
The patch below does not apply to the 6.18-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@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.18.y
git checkout FETCH_HEAD
git cherry-pick -x 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042046-underfeed-riding-d661@gregkh' --subject-prefix 'PATCH 6.18.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 6.1-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
The patch below does not apply to the 6.1-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@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.1.y
git checkout FETCH_HEAD
git cherry-pick -x 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042047-kissable-reboot-f1bc@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* FAILED: patch "[PATCH] scripts: generate_rust_analyzer.py: define scripts" failed to apply to 6.6-stable tree
From: gregkh @ 2026-04-20 12:56 UTC (permalink / raw)
To: tamird, daniel.almeida, me, tmgross; +Cc: stable
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@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 36c619f6bd793493294becb10a02fea370b67a91
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042047-drizzly-oblivious-029f@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 36c619f6bd793493294becb10a02fea370b67a91 Mon Sep 17 00:00:00 2001
From: Tamir Duberstein <tamird@kernel.org>
Date: Thu, 22 Jan 2026 11:53:28 -0500
Subject: [PATCH] scripts: generate_rust_analyzer.py: define scripts
Add IDE support for host-side scripts written in Rust. This support has
been missing since these scripts were initially added in commit
9a8ff24ce584 ("scripts: add `generate_rust_target.rs`"), thus add it.
Change the existing instance of extension stripping to
`pathlib.Path.stem` to maintain code consistency.
Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Link: https://patch.msgid.link/20260122-rust-analyzer-scripts-v1-1-ff6ba278170e@kernel.org
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 7becc2698c14..38e834bd209e 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -299,6 +299,18 @@ def generate_crates(
"kernel", [core, macros, build_error, pin_init, ffi, bindings, uapi]
)
+ scripts = srctree / "scripts"
+ makefile = (scripts / "Makefile").read_text()
+ for path in scripts.glob("*.rs"):
+ name = path.stem
+ if f"{name}-rust" not in makefile:
+ continue
+ append_crate(
+ name,
+ path,
+ [std],
+ )
+
def is_root_crate(build_file: pathlib.Path, target: str) -> bool:
try:
return f"{target}.o" in open(build_file).read()
@@ -316,7 +328,7 @@ def generate_crates(
for folder in extra_dirs:
for path in folder.rglob("*.rs"):
logging.info("Checking %s", path)
- name = path.name.replace(".rs", "")
+ name = path.stem
# Skip those that are not crate roots.
if not is_root_crate(path.parent / "Makefile", name) and \
^ permalink raw reply related
* [PATCH] pnfs/flexfiles: reject zero version_count in GETDEVICEINFO
From: Junrui Luo @ 2026-04-20 13:01 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker, Weston Andros Adamson, Tao Peng,
Tom Haynes
Cc: linux-nfs, linux-kernel, Yuhao Jiang, stable, Junrui Luo
nfs4_ff_alloc_deviceid_node() parses the flexfiles device address from
a GETDEVICEINFO response and passes version_count to kzalloc_objs()
without validating it is non-zero. A zero count makes kzalloc_objs()
return ZERO_SIZE_PTR, which passes the NULL check.
This leads to a NULL pointer dereference when
nfs4_ff_layout_ds_version() later accesses ds_versions[0] through the
ZERO_SIZE_PTR.
Fix by rejecting version_count == 0 before the allocation.
Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
index c40395ae0814..d5aa6bf3ecbc 100644
--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -99,6 +99,11 @@ nfs4_ff_alloc_deviceid_node(struct nfs_server *server, struct pnfs_device *pdev,
version_count = be32_to_cpup(p);
dprintk("%s: version count %d\n", __func__, version_count);
+ if (version_count == 0) {
+ ret = -EINVAL;
+ goto out_err_drain_dsaddrs;
+ }
+
ds_versions = kzalloc_objs(struct nfs4_ff_ds_version, version_count,
gfp_flags);
if (!ds_versions)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20260420-fixes-9f910b7b5cde
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
* Re: [PATCH] vmalloc: fix buffer overflow in vrealloc_node_align()
From: Harry Yoo (Oracle) @ 2026-04-20 13:04 UTC (permalink / raw)
To: Marco Elver
Cc: Vlastimil Babka, Andrew Morton, Uladzislau Rezki, linux-mm,
linux-kernel, kasan-dev, Vitaly Wool, stable
In-Reply-To: <20260420114805.3572606-2-elver@google.com>
On Mon, Apr 20, 2026 at 01:47:26PM +0200, Marco Elver wrote:
> Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
> vrealloc") added the ability to force a new allocation if the current
> pointer is on the wrong NUMA node, or if an alignment constraint is not
> met, even if the user is shrinking the allocation.
>
> On this path (need_realloc), the code allocates a new object of 'size'
> bytes and then memcpy()s 'old_size' bytes into it. If the request is to
> shrink the object (size < old_size), this results in an out-of-bounds
> write on the new buffer.
>
> Fix this by bounding the copy length by the new allocation size.
>
> Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc")
> Cc: <stable@vger.kernel.org>
> Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
Looks good to me,
Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
Thanks a lot for fixing it!
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8b1124158f54 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4361,7 +4361,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> return NULL;
>
> if (p) {
> - memcpy(n, p, old_size);
> + memcpy(n, p, min(size, old_size));
> vfree(p);
> }
>
> --
> 2.54.0.rc1.513.gad8abe7a5a-goog
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* FAILED: patch "[PATCH] ocfs2: fix possible deadlock between unlink and" failed to apply to 5.15-stable tree
From: gregkh @ 2026-04-20 13:05 UTC (permalink / raw)
To: joseph.qi, akpm, gechangwei, heming.zhao, jiangqi903, jlbec,
junxiao.bi, mark, piaojun, stable
Cc: stable
The patch below does not apply to the 5.15-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@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-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x b02da26a992db0c0e2559acbda0fc48d4a2fd337
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042002-rumbling-plunder-40f1@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b02da26a992db0c0e2559acbda0fc48d4a2fd337 Mon Sep 17 00:00:00 2001
From: Joseph Qi <joseph.qi@linux.alibaba.com>
Date: Fri, 6 Mar 2026 11:22:11 +0800
Subject: [PATCH] ocfs2: fix possible deadlock between unlink and
dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):
ocfs2_unlink
ocfs2_prepare_orphan_dir
ocfs2_lookup_lock_orphan_dir
inode_lock(orphan_dir_inode) <- lock A
__ocfs2_prepare_orphan_dir
ocfs2_prepare_dir_for_insert
ocfs2_extend_dir
ocfs2_expand_inline_dir
down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):
ocfs2_dio_end_io_write
down_write(&oi->ip_alloc_sem) <- Lock B
ocfs2_del_inode_from_orphan()
inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario:
CPU0 (unlink) CPU1 (dio_end_io_write)
------ ------
inode_lock(orphan_dir_inode)
down_write(ip_alloc_sem)
down_write(ip_alloc_sem)
inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan. So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
Link: https://lkml.kernel.org/r/20260306032211.1016452-1-joseph.qi@linux.alibaba.com
Reported-by: syzbot+67b90111784a3eac8c04@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=67b90111784a3eac8c04
Fixes: a86a72a4a4e0 ("ocfs2: take ip_alloc_sem in ocfs2_dio_get_block & ocfs2_dio_end_io_write")
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reviewed-by: Heming Zhao <heming.zhao@suse.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <jiangqi903@gmail.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 17ba79f443ee..09146b43d1f0 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -2294,8 +2294,6 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
goto out;
}
- down_write(&oi->ip_alloc_sem);
-
/* Delete orphan before acquire i_rwsem. */
if (dwc->dw_orphaned) {
BUG_ON(dwc->dw_writer_pid != task_pid_nr(current));
@@ -2308,6 +2306,7 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
mlog_errno(ret);
}
+ down_write(&oi->ip_alloc_sem);
di = (struct ocfs2_dinode *)di_bh->b_data;
ocfs2_init_dinode_extent_tree(&et, INODE_CACHE(inode), di_bh);
^ permalink raw reply related
* FAILED: patch "[PATCH] ocfs2: fix possible deadlock between unlink and" failed to apply to 5.10-stable tree
From: gregkh @ 2026-04-20 13:05 UTC (permalink / raw)
To: joseph.qi, akpm, gechangwei, heming.zhao, jiangqi903, jlbec,
junxiao.bi, mark, piaojun, stable
Cc: stable
The patch below does not apply to the 5.10-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@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-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x b02da26a992db0c0e2559acbda0fc48d4a2fd337
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026042003-rocking-engine-1cb6@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b02da26a992db0c0e2559acbda0fc48d4a2fd337 Mon Sep 17 00:00:00 2001
From: Joseph Qi <joseph.qi@linux.alibaba.com>
Date: Fri, 6 Mar 2026 11:22:11 +0800
Subject: [PATCH] ocfs2: fix possible deadlock between unlink and
dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,
while in ocfs2_dio_end_io_write, it acquires these locks in reverse order.
This creates an ABBA lock ordering violation on lock classes
ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and
ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem):
ocfs2_unlink
ocfs2_prepare_orphan_dir
ocfs2_lookup_lock_orphan_dir
inode_lock(orphan_dir_inode) <- lock A
__ocfs2_prepare_orphan_dir
ocfs2_prepare_dir_for_insert
ocfs2_extend_dir
ocfs2_expand_inline_dir
down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock):
ocfs2_dio_end_io_write
down_write(&oi->ip_alloc_sem) <- Lock B
ocfs2_del_inode_from_orphan()
inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario:
CPU0 (unlink) CPU1 (dio_end_io_write)
------ ------
inode_lock(orphan_dir_inode)
down_write(ip_alloc_sem)
down_write(ip_alloc_sem)
inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated
with operations in ocfs2_del_inode_from_orphan. So move
ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
Link: https://lkml.kernel.org/r/20260306032211.1016452-1-joseph.qi@linux.alibaba.com
Reported-by: syzbot+67b90111784a3eac8c04@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=67b90111784a3eac8c04
Fixes: a86a72a4a4e0 ("ocfs2: take ip_alloc_sem in ocfs2_dio_get_block & ocfs2_dio_end_io_write")
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Reviewed-by: Heming Zhao <heming.zhao@suse.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <jiangqi903@gmail.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 17ba79f443ee..09146b43d1f0 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -2294,8 +2294,6 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
goto out;
}
- down_write(&oi->ip_alloc_sem);
-
/* Delete orphan before acquire i_rwsem. */
if (dwc->dw_orphaned) {
BUG_ON(dwc->dw_writer_pid != task_pid_nr(current));
@@ -2308,6 +2306,7 @@ static int ocfs2_dio_end_io_write(struct inode *inode,
mlog_errno(ret);
}
+ down_write(&oi->ip_alloc_sem);
di = (struct ocfs2_dinode *)di_bh->b_data;
ocfs2_init_dinode_extent_tree(&et, INODE_CACHE(inode), di_bh);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox