Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v15 04/12] media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>

Enhances the Mediatek JPEG driver's stability and reliability by ensuring
that all queued buffers are processed before stopping the streaming in
multi-core environments. It introduces a call to
`vb2_wait_for_all_buffers()` in the `mtk_jpeg_enc_stop_streaming()` and
`mtk_jpeg_dec_stop_streaming()` functions when the `multi_core` variant
is enabled. This change ensures that no buffers are left unprocessed,
preventing potential data loss or corruption during multi-core flow.

Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface")
Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 6d6a999a22fc..76a5b49b7f43 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -850,8 +850,12 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
 static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
 {
 	struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
+	struct mtk_jpeg_dev *jpeg = ctx->jpeg;
 	struct vb2_v4l2_buffer *vb;
 
+	if (jpeg->variant->multi_core)
+		vb2_wait_for_all_buffers(q);
+
 	while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
 		v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
 }
@@ -859,6 +863,7 @@ static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
 static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
 {
 	struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
+	struct mtk_jpeg_dev *jpeg = ctx->jpeg;
 	struct vb2_v4l2_buffer *vb;
 
 	/*
@@ -866,6 +871,9 @@ static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
 	 * Before STREAMOFF, we still have to return the old resolution and
 	 * subsampling. Update capture queue when the stream is off.
 	 */
+	if (jpeg->variant->multi_core)
+		vb2_wait_for_all_buffers(q);
+
 	if (ctx->state == MTK_JPEG_SOURCE_CHANGE &&
 	    V4L2_TYPE_IS_CAPTURE(q->type)) {
 		struct mtk_jpeg_src_buf *src_buf;
-- 
2.45.2



^ permalink raw reply related
* [PATCH v15 05/12] media: mediatek: jpeg: Fix multi-core clk suspend and resume setting
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>

The suspend/resume callback function is defined in the dev_pm_ops
structure, which is defined in platform_driver. For multiple-core
architecture, each hardware driver will register a platform_driver
structure, so it is necessary to add a suspend/resume callback
function for each hardware to support this operation.

Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
 .../platform/mediatek/jpeg/mtk_jpeg_core.c    | 28 +++------
 .../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c  | 62 +++++++++++++++++--
 .../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c  | 60 ++++++++++++++++--
 3 files changed, 121 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 76a5b49b7f43..89048aba8dca 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1115,6 +1115,9 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
 {
 	int ret;
 
+	if (jpeg->variant->multi_core)
+		return;
+
 	ret = clk_bulk_prepare_enable(jpeg->variant->num_clks,
 				      jpeg->variant->clks);
 	if (ret)
@@ -1123,6 +1126,9 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
 
 static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
 {
+	if (jpeg->variant->multi_core)
+		return;
+
 	clk_bulk_disable_unprepare(jpeg->variant->num_clks,
 				   jpeg->variant->clks);
 }
@@ -1647,13 +1653,6 @@ static void mtk_jpegenc_worker(struct work_struct *work)
 		goto enc_end;
 	}
 
-	ret = clk_prepare_enable(comp_jpeg[hw_id]->venc_clk.clks->clk);
-	if (ret) {
-		dev_err(jpeg->dev, "%s : %d, jpegenc clk_prepare_enable fail\n",
-			__func__, __LINE__);
-		goto enc_end;
-	}
-
 	v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
 	v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
 
@@ -1750,20 +1749,13 @@ static void mtk_jpegdec_worker(struct work_struct *work)
 	jpeg_dst_buf->frame_num = ctx->total_frame_num;
 
 	mtk_jpegdec_set_hw_param(ctx, hw_id, src_buf, dst_buf);
-	ret = pm_runtime_get_sync(comp_jpeg[hw_id]->dev);
+	ret = pm_runtime_resume_and_get(comp_jpeg[hw_id]->dev);
 	if (ret < 0) {
 		dev_err(jpeg->dev, "%s : %d, pm_runtime_get_sync fail !!!\n",
 			__func__, __LINE__);
 		goto dec_end;
 	}
 
-	ret = clk_prepare_enable(comp_jpeg[hw_id]->jdec_clk.clks->clk);
-	if (ret) {
-		dev_err(jpeg->dev, "%s : %d, jpegdec clk_prepare_enable fail\n",
-			__func__, __LINE__);
-		goto clk_end;
-	}
-
 	v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
 	v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
 
@@ -1773,7 +1765,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
 				 &dst_buf->vb2_buf, &fb)) {
 		dev_err(jpeg->dev, "%s : %d, mtk_jpeg_set_dec_dst fail\n",
 			__func__, __LINE__);
-		goto setdst_end;
+		goto set_dst_fail;
 	}
 
 	schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
@@ -1794,9 +1786,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
 
 	return;
 
-setdst_end:
-	clk_disable_unprepare(comp_jpeg[hw_id]->jdec_clk.clks->clk);
-clk_end:
+set_dst_fail:
 	pm_runtime_put(comp_jpeg[hw_id]->dev);
 dec_end:
 	v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index 4534caeb104f..9a8dbca6af00 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -533,13 +533,12 @@ static void mtk_jpegdec_timeout_work(struct work_struct *work)
 	v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
 
 	mtk_jpeg_dec_reset(cjpeg->reg_base);
-	clk_disable_unprepare(cjpeg->jdec_clk.clks->clk);
-	pm_runtime_put(cjpeg->dev);
 	cjpeg->hw_state = MTK_JPEG_HW_IDLE;
 	atomic_inc(&master_jpeg->hw_rdy);
 	wake_up(&master_jpeg->hw_wq);
 	v4l2_m2m_buf_done(src_buf, buf_state);
 	mtk_jpegdec_put_buf(cjpeg);
+	pm_runtime_put(cjpeg->dev);
 }
 
 static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
@@ -547,7 +546,6 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
 	struct mtk_jpeg_src_buf *jpeg_src_buf;
 	enum vb2_buffer_state buf_state;
-	struct mtk_jpeg_ctx *ctx;
 	u32 dec_irq_ret;
 	u32 irq_status;
 	int i;
@@ -557,7 +555,6 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
 
 	cancel_delayed_work(&jpeg->job_timeout_work);
 
-	ctx = jpeg->hw_param.curr_ctx;
 	src_buf = jpeg->hw_param.src_buffer;
 	dst_buf = jpeg->hw_param.dst_buffer;
 	v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
@@ -580,12 +577,11 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
 	buf_state = VB2_BUF_STATE_DONE;
 	v4l2_m2m_buf_done(src_buf, buf_state);
 	mtk_jpegdec_put_buf(jpeg);
-	pm_runtime_put(ctx->jpeg->dev);
-	clk_disable_unprepare(jpeg->jdec_clk.clks->clk);
 
 	jpeg->hw_state = MTK_JPEG_HW_IDLE;
 	wake_up(&master_jpeg->hw_wq);
 	atomic_inc(&master_jpeg->hw_rdy);
+	pm_runtime_put(jpeg->dev);
 
 	return IRQ_HANDLED;
 }
@@ -668,15 +664,69 @@ static int mtk_jpegdec_hw_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, dev);
 	pm_runtime_enable(&pdev->dev);
+	ret = devm_clk_bulk_get(dev->dev,
+				jpegdec_clk->clk_num,
+				jpegdec_clk->clks);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to init clk\n");
+		return ret;
+	}
 
 	return 0;
 }
 
+static int mtk_jpegdec_pm_suspend(struct device *dev)
+{
+	struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	clk_bulk_disable_unprepare(jpeg->jdec_clk.clk_num,
+				   jpeg->jdec_clk.clks);
+
+	return 0;
+}
+
+static int mtk_jpegdec_pm_resume(struct device *dev)
+{
+	struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	return clk_bulk_prepare_enable(jpeg->jdec_clk.clk_num,
+				       jpeg->jdec_clk.clks);
+}
+
+static int mtk_jpegdec_suspend(struct device *dev)
+{
+	struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	v4l2_m2m_suspend(jpeg->master_dev->m2m_dev);
+
+	return pm_runtime_force_suspend(dev);
+}
+
+static int mtk_jpegdec_resume(struct device *dev)
+{
+	struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+	int ret;
+
+	ret = pm_runtime_force_resume(dev);
+	if (ret < 0)
+		return ret;
+
+	v4l2_m2m_resume(jpeg->master_dev->m2m_dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops mtk_jpegdec_pm_ops = {
+	SYSTEM_SLEEP_PM_OPS(mtk_jpegdec_suspend, mtk_jpegdec_resume)
+	RUNTIME_PM_OPS(mtk_jpegdec_pm_suspend, mtk_jpegdec_pm_resume, NULL)
+};
+
 static struct platform_driver mtk_jpegdec_hw_driver = {
 	.probe = mtk_jpegdec_hw_probe,
 	.driver = {
 		.name = "mtk-jpegdec-hw",
 		.of_match_table = mtk_jpegdec_hw_ids,
+		.pm             = &mtk_jpegdec_pm_ops,
 	},
 };
 
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index 2765dafab4ad..5d1c217fea0f 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -264,13 +264,12 @@ static void mtk_jpegenc_timeout_work(struct work_struct *work)
 	v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
 
 	mtk_jpeg_enc_reset(cjpeg->reg_base);
-	clk_disable_unprepare(cjpeg->venc_clk.clks->clk);
-	pm_runtime_put(cjpeg->dev);
 	cjpeg->hw_state = MTK_JPEG_HW_IDLE;
 	atomic_inc(&master_jpeg->hw_rdy);
 	wake_up(&master_jpeg->hw_wq);
 	v4l2_m2m_buf_done(src_buf, buf_state);
 	mtk_jpegenc_put_buf(cjpeg);
+	pm_runtime_put(cjpeg->dev);
 }
 
 static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
@@ -304,12 +303,11 @@ static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
 	buf_state = VB2_BUF_STATE_DONE;
 	v4l2_m2m_buf_done(src_buf, buf_state);
 	mtk_jpegenc_put_buf(jpeg);
-	pm_runtime_put(ctx->jpeg->dev);
-	clk_disable_unprepare(jpeg->venc_clk.clks->clk);
 
 	jpeg->hw_state = MTK_JPEG_HW_IDLE;
 	wake_up(&master_jpeg->hw_wq);
 	atomic_inc(&master_jpeg->hw_rdy);
+	pm_runtime_put(jpeg->dev);
 
 	return IRQ_HANDLED;
 }
@@ -390,15 +388,69 @@ static int mtk_jpegenc_hw_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, dev);
 	pm_runtime_enable(&pdev->dev);
+	ret = devm_clk_bulk_get(dev->dev,
+				jpegenc_clk->clk_num,
+				jpegenc_clk->clks);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to init clk\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int mtk_jpegenc_pm_suspend(struct device *dev)
+{
+	struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	clk_bulk_disable_unprepare(jpeg->venc_clk.clk_num,
+				   jpeg->venc_clk.clks);
 
 	return 0;
 }
 
+static int mtk_jpegenc_pm_resume(struct device *dev)
+{
+	struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	return clk_bulk_prepare_enable(jpeg->venc_clk.clk_num,
+				       jpeg->venc_clk.clks);
+}
+
+static int mtk_jpegenc_suspend(struct device *dev)
+{
+	struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+	v4l2_m2m_suspend(jpeg->master_dev->m2m_dev);
+
+	return pm_runtime_force_suspend(dev);
+}
+
+static int mtk_jpegenc_resume(struct device *dev)
+{
+	struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+	int ret;
+
+	ret = pm_runtime_force_resume(dev);
+	if (ret < 0)
+		return ret;
+
+	v4l2_m2m_resume(jpeg->master_dev->m2m_dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops mtk_jpegenc_pm_ops = {
+	SYSTEM_SLEEP_PM_OPS(mtk_jpegenc_suspend, mtk_jpegenc_resume)
+	RUNTIME_PM_OPS(mtk_jpegenc_pm_suspend, mtk_jpegenc_pm_resume, NULL)
+};
+
 static struct platform_driver mtk_jpegenc_hw_driver = {
 	.probe = mtk_jpegenc_hw_probe,
 	.driver = {
 		.name = "mtk-jpegenc-hw",
 		.of_match_table = mtk_jpegenc_drv_ids,
+		.pm = &mtk_jpegenc_pm_ops,
 	},
 };
 
-- 
2.45.2



^ permalink raw reply related
* [PATCH v15 01/12] media: mediatek: jpeg: fix jpeg cores' amounts setting
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>

Different ICs have different amounts of cores,
use a variable to set the cores' amounts.

Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c   | 8 ++++----
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h   | 2 ++
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 1 +
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 1 +
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..1e014fd698ae 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1462,7 +1462,7 @@ static int mtk_jpegenc_get_hw(struct mtk_jpeg_ctx *ctx)
 	int i;
 
 	spin_lock_irqsave(&jpeg->hw_lock, flags);
-	for (i = 0; i < MTK_JPEGENC_HW_MAX; i++) {
+	for (i = 0; i < jpeg->max_hw_count; i++) {
 		comp_jpeg = jpeg->enc_hw_dev[i];
 		if (comp_jpeg->hw_state == MTK_JPEG_HW_IDLE) {
 			hw_id = i;
@@ -1509,7 +1509,7 @@ static int mtk_jpegdec_get_hw(struct mtk_jpeg_ctx *ctx)
 	int i;
 
 	spin_lock_irqsave(&jpeg->hw_lock, flags);
-	for (i = 0; i < MTK_JPEGDEC_HW_MAX; i++) {
+	for (i = 0; i < jpeg->max_hw_count; i++) {
 		comp_jpeg = jpeg->dec_hw_dev[i];
 		if (comp_jpeg->hw_state == MTK_JPEG_HW_IDLE) {
 			hw_id = i;
@@ -1592,7 +1592,7 @@ static void mtk_jpegenc_worker(struct work_struct *work)
 		jpeg_work);
 	struct mtk_jpeg_dev *jpeg = ctx->jpeg;
 
-	for (i = 0; i < MTK_JPEGENC_HW_MAX; i++)
+	for (i = 0; i < jpeg->max_hw_count; i++)
 		comp_jpeg[i] = jpeg->enc_hw_dev[i];
 	i = 0;
 
@@ -1687,7 +1687,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
 	struct mtk_jpeg_fb fb;
 	unsigned long flags;
 
-	for (i = 0; i < MTK_JPEGDEC_HW_MAX; i++)
+	for (i = 0; i < jpeg->max_hw_count; i++)
 		comp_jpeg[i] = jpeg->dec_hw_dev[i];
 	i = 0;
 
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
index 02ed0ed5b736..6be5cf30dea1 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
@@ -212,6 +212,7 @@ struct mtk_jpegdec_comp_dev {
  * @reg_decbase:	jpg decode register base addr
  * @dec_hw_dev:	jpg decode hardware device
  * @hw_index:		jpg hw index
+ * @max_hw_count:	jpeg hw-core count
  */
 struct mtk_jpeg_dev {
 	struct mutex		lock;
@@ -234,6 +235,7 @@ struct mtk_jpeg_dev {
 	void __iomem *reg_decbase[MTK_JPEGDEC_HW_MAX];
 	struct mtk_jpegdec_comp_dev *dec_hw_dev[MTK_JPEGDEC_HW_MAX];
 	atomic_t hw_index;
+	u32 max_hw_count;
 };
 
 /**
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index 32372781daf5..4534caeb104f 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -664,6 +664,7 @@ static int mtk_jpegdec_hw_probe(struct platform_device *pdev)
 	master_dev->dec_hw_dev[i] = dev;
 	master_dev->reg_decbase[i] = dev->reg_base;
 	dev->master_dev = master_dev;
+	master_dev->max_hw_count++;
 
 	platform_set_drvdata(pdev, dev);
 	pm_runtime_enable(&pdev->dev);
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index b6f5b2249f1f..2765dafab4ad 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -386,6 +386,7 @@ static int mtk_jpegenc_hw_probe(struct platform_device *pdev)
 	master_dev->enc_hw_dev[i] = dev;
 	master_dev->reg_encbase[i] = dev->reg_base;
 	dev->master_dev = master_dev;
+	master_dev->max_hw_count++;
 
 	platform_set_drvdata(pdev, dev);
 	pm_runtime_enable(&pdev->dev);
-- 
2.45.2



^ permalink raw reply related
* [PATCH v15 03/12] media: mediatek: jpeg: fix buffer structure size and layout
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>

Updates the `buf_struct_size` in the JPEG driver to use the correct
structure `mtk_jpeg_src_buf` instead of `v4l2_m2m_buffer`, ensuring
proper handling of source buffers. The previous buffer size led to
mismatches and potential issues during video buffer handling.

Moves `frame_num` in the `mtk_jpeg_src_buf` structure to align with
other members appropriately. The first field of the driver-specific
buffer structure must be the subsystem-specificstruct
(vb2_v4l2_buffer in the case of V4L2).

Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 2 +-
 drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 3960ad21d7f0..6d6a999a22fc 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1092,7 +1092,7 @@ static int mtk_jpeg_queue_init(void *priv, struct vb2_queue *src_vq,
 	dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
 	dst_vq->io_modes = VB2_DMABUF | VB2_MMAP;
 	dst_vq->drv_priv = ctx;
-	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+	dst_vq->buf_struct_size = sizeof(struct mtk_jpeg_src_buf);
 	dst_vq->ops = jpeg->variant->qops;
 	dst_vq->mem_ops = &vb2_dma_contig_memops;
 	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
index 6be5cf30dea1..148fd41759b7 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
@@ -85,10 +85,10 @@ struct mtk_jpeg_variant {
 };
 
 struct mtk_jpeg_src_buf {
-	u32 frame_num;
 	struct vb2_v4l2_buffer b;
 	struct list_head list;
 	u32 bs_size;
+	u32 frame_num;
 	struct mtk_jpeg_dec_param dec_param;
 
 	struct mtk_jpeg_ctx *curr_ctx;
-- 
2.45.2



^ permalink raw reply related
* [PATCH v15 00/12] Enable jpeg enc & dec multi-hardwares for MT8196
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek

This series have the follow changing:
Firstly fix some bugs, including resolution change handleing, stop
streaming sw flow, fix buffer layout and clock setting to support multi-hw
jpeg working and others.
Secondly add mt8196 jpegdec and jpegenc compatible to support MT8196
kernel driver.
Lastly, Add smmu setting to support smmu and iommu at the same time.

This series has been tested with MT8196 tast test.
Encoding and decoding worked for this chip.

Patches 1 fix jpeg hw count setting to support different chips.
Patches 2 fix jpeg buffer payload setting to handle buffer
size bug while resolution changed.
Patches 3 fix jpeg dst buffer layout.
Patches 4 fix multi-core stop streaming flow
Patches 5 fix multi-core clk suspend/resume setting
Patches 6 fix decoding buffer number setting timing issue
Patches 7 fix decoding resolution change operation
Patches 8 fix remove buffer operation
Patches 9-11 Adds jpeg encoder and decoder compatible.
Patches 12 add jpeg smmu sid setting.

---
Changes compared with v14:
--Rebased on top of the latest media tree

Changes compared with v13:
--Rebased on top of the latest media tree

Changes compared with v12:
--Rebased on top of the latest media tree
--fix kernel rebot build warnings in patch 5

Changes compared with v11:
--Rebased on top of the latest media tree
--Some modifications for patch v11's review comments.
--add reviewer to commit messages

Changes compared with v10:
--Rebased on top of the latest media tree
--add reviewer to commit messages

Changes compared with v9:
--Rebased on top of the latest media tree

Changes compared with v8:
--Rebased on top of the latest media tree

Changes compared with v7:
--Rebased on top of the latest media tree

Changes compared with v6:
--Rebased on top of the latest media tree

Changes compared with v5:
--reorder the patches set.
--fix commit message of patch 1-8.

Changes compared with v4:
--fix kernel robot build errors for patch 4.
--add reviewer for patch 1 and patch 2.

Changes compared with v3:
--change patch subject of jpeg encoder and decoder compatible.

Changes compared with v2:
--refactor smmu sid setting function interface
--Some modifications for patch v2's review comments.

Changes compared with v1:
--refine jpeg dt-bindings for MT8196
--optimize software code to manage jpeg HW count
--refactor smmu sid setting function interface
--Some modifications for patch v1's review comments.

Kyrie Wu (12):
  media: mediatek: jpeg: fix jpeg cores' amounts setting
  media: mediatek: jpeg: fix jpeg buffer payload size setting
  media: mediatek: jpeg: fix buffer structure size and layout
  media: mediatek: jpeg: Fix buffer completion on multi-core streaming
    stop
  media: mediatek: jpeg: Fix multi-core clk suspend and resume setting
  media: mediatek: jpeg: fix decoding buffer number setting timing issue
  media: mediatek: jpeg: fix resolution change event handling in decoder
  media: mediatek: jpeg: fix remove buffer removal timing for multi-core
  media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgdec
    compatible
  media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc
    compatible
  media: mediatek: jpeg: add jpeg compatible
  media: mediatek: jpeg: add jpeg smmu sid setting

 .../media/mediatek,mt8195-jpegdec.yaml        |   8 +-
 .../media/mediatek,mt8195-jpegenc.yaml        |   8 +-
 .../platform/mediatek/jpeg/mtk_jpeg_core.c    | 153 +++++++++++++-----
 .../platform/mediatek/jpeg/mtk_jpeg_core.h    |  19 ++-
 .../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c  |  90 ++++++++++-
 .../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c  |  88 +++++++++-
 6 files changed, 310 insertions(+), 56 deletions(-)

-- 
2.45.2



^ permalink raw reply
* [PATCH v15 02/12] media: mediatek: jpeg: fix jpeg buffer payload size setting
From: Kyrie Wu @ 2026-07-02  7:26 UTC (permalink / raw)
  To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
	Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
	linux-media, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>

For multi-core jpegdec, if one core gets resolution change event,
the payload size, representing the size of Y/C data, needs to change.
But others are decoding at the same time and it can not be changed
immediately, which results in the payload size to not match the real
buffer length.
The payload size must less than the real buffer length to remove
the warnning logs.

Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
 .../platform/mediatek/jpeg/mtk_jpeg_core.c    | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 1e014fd698ae..3960ad21d7f0 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -702,6 +702,7 @@ static int mtk_jpeg_buf_prepare(struct vb2_buffer *vb)
 	struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
 	struct mtk_jpeg_q_data *q_data = NULL;
 	struct v4l2_plane_pix_format plane_fmt = {};
+	size_t max_size;
 	int i;
 
 	q_data = mtk_jpeg_get_q_data(ctx, vb->vb2_queue->type);
@@ -710,12 +711,20 @@ static int mtk_jpeg_buf_prepare(struct vb2_buffer *vb)
 
 	for (i = 0; i < q_data->fmt->colplanes; i++) {
 		plane_fmt = q_data->pix_mp.plane_fmt[i];
+		max_size = plane_fmt.sizeimage;
+
 		if (ctx->enable_exif &&
-		    q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG)
-			vb2_set_plane_payload(vb, i, plane_fmt.sizeimage +
-					      MTK_JPEG_MAX_EXIF_SIZE);
-		else
-			vb2_set_plane_payload(vb, i,  plane_fmt.sizeimage);
+			q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG) {
+			max_size += MTK_JPEG_MAX_EXIF_SIZE;
+
+			vb2_set_plane_payload(vb, i,
+					      MIN(vb->planes[i].length,
+						  max_size));
+		} else {
+			vb2_set_plane_payload(vb, i,
+					      MIN(plane_fmt.sizeimage,
+						  vb->planes[i].length));
+		}
 	}
 
 	return 0;
-- 
2.45.2



^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Krzysztof Kozlowski @ 2026-07-02  7:17 UTC (permalink / raw)
  To: muhammad.nazim.amirul.nazle.asmade
  Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
	davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
	linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-3-muhammad.nazim.amirul.nazle.asmade@altera.com>

On Tue, Jun 30, 2026 at 06:31:07AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> Add device tree for the Intel SoCFPGA Agilex5 SoCDK TSN Config2 board
> variant. This configuration enables gmac1 as a TSN port alongside
> the standard gmac2 Ethernet port.
> 
> The TSN port (gmac1) uses GMII internally in the MAC but connects to an
> RGMII PHY. The mac-mode property is set to "gmii" to reflect the
> MAC-side interface, while phy-mode is set to "rgmii" for the PHY-side
> interface.
> 
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
>  arch/arm64/boot/dts/intel/Makefile            |   3 +-
>  .../intel/socfpga_agilex5_socdk_tsn_cfg2.dts  | 133 ++++++++++++++++++
>  2 files changed, 135 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
> 
> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
> index 270c70fdf084..fc7ba2c6384b 100644
> --- a/arch/arm64/boot/dts/intel/Makefile
> +++ b/arch/arm64/boot/dts/intel/Makefile
> @@ -4,10 +4,11 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
>  				socfpga_agilex_socdk_emmc.dtb \
>  				socfpga_agilex_socdk_nand.dtb \
>  				socfpga_agilex3_socdk.dtb \
> -				socfpga_agilex5_socdk.dtb \
> +			socfpga_agilex5_socdk.dtb \

Why are you making this change?

>  				socfpga_agilex5_socdk_013b.dtb \
>  				socfpga_agilex5_socdk_modular.dtb \
>  				socfpga_agilex5_socdk_nand.dtb \
> +				socfpga_agilex5_socdk_tsn_cfg2.dtb \
>  				socfpga_agilex72_socdk.dtb \
>  				socfpga_agilex7m_socdk.dtb \
>  				socfpga_n5x_socdk.dtb

Best regards,
Krzysztof



^ permalink raw reply
* Re: [PATCH v2 0/6] KVM: arm64: ptdump: Shadow ptdump fixes
From: Itaru Kitayama @ 2026-07-02  6:55 UTC (permalink / raw)
  To: Wei-Lin Chang
  Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
	Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
	Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
	Sebastian Ene
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>

Hi Wei-Lin,
On Tue, Jun 30, 2026 at 01:09:59PM +0100, Wei-Lin Chang wrote:
> Hi,
> 
> This is v2 of fixing shadow ptdump debugfs files. Unfortunately I couldn't make
> per mmu ptdump files work after all, mainly because there isn't a clean way to
> locate the specific nested mmu for each ptdump file as the nested mmus could be
> freed when the file gets opened. Therefore in this series a single file
> "shadow_page_tables" is created that dumps all valid mmus' page table
> information.
> 
> An advantage of this is that this new ptdump file have a lifetime identical to
> other ptdump files i.e. stage2_page_tables, ipa_range, etc., hence avoiding the
> dentry UAF found last time [1].
> 
> With this all ptdump files are only removed when the last kvm reference gets
> dropped and kvm_destroy_vm_debugfs() is called, in their open(), show()
> functions the nested mmu array and mmu->pgt are checked with mmu_lock held to
> prevent UAF.
> 
> Patch 1-2: Undo previous shadow ptdump implementation.
> Patch 3:   Fix a mmu->pgt UAF that happens when ptdump files are read after
>            mmu->pgt is freed.
> Patch 4-5: Preparation for the shadow page table dump file.
> Patch 6:   Implementation of the shadow page table dump file.
> 
> The fixes are tested with CONFIG_PROVE_LOCKING,
> CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
> 
> Thanks!

Running your shadow stage 2 kselftest with bpftrace shows me that __kvm_pgtable_stage2_init()
for shadow stage 2 translation tables are built with ia_bits = 52 and
start_level = 0, but the debugfs entry for the active shadow stage 2 tables prints
out that's 3 levels. Is this fully expected?

Thanks,
Itaru.

> 
> * Changes from v1 ([2]):
> 
>   - Move from per mmu ptdump files to one file that will dump all shadow page
>     tables.
> 
> [1]: https://lore.kernel.org/kvmarm/ajty6I7ZqodP4ous@sm-arm-grace07/
> [2]: https://lore.kernel.org/kvmarm/20260623142443.648972-1-weilin.chang@arm.com/
> 
> Wei-Lin Chang (6):
>   KVM: arm64: ptdump: Remove shadow ptdump files
>   KVM: arm64: ptdump: Undo making the ptdump code mmu aware
>   KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
>   KVM: arm64: ptdump: Factor out initialization of
>     kvm_ptdump_guest_state
>   KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical
>     ptdump path
>   KVM: arm64: ptdump: Introduce the shadow ptdump file
> 
>  arch/arm64/include/asm/kvm_host.h |   5 +-
>  arch/arm64/include/asm/kvm_mmu.h  |   4 -
>  arch/arm64/kvm/nested.c           |  18 +--
>  arch/arm64/kvm/ptdump.c           | 185 ++++++++++++++++++++----------
>  4 files changed, 135 insertions(+), 77 deletions(-)
> 
> -- 
> 2.43.0
> 


^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan.M @ 2026-07-02  6:55 UTC (permalink / raw)
  To: krzk
  Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
	vigneshr, robh, krzk+dt, conor+dt, srini, Nicolas.Ferre,
	alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
	arnd, michael, linux-mtd, devicetree, linux-kernel,
	linux-arm-kernel, netdev
In-Reply-To: <20260702-utopian-termite-of-perfection-f1f3ec@quoll>

Hi Krzysztof,

On 7/2/26 11:46 AM, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
>> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
>> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
> 
> What is SFDP?
> 
SFDP is the Serial Flash Discoverable Parameters -- a JEDEC-standardised
(JESD216) read-only parameter table present in most SPI NOR flashes, the 
table contents provide basic information about the flash. There are 
standard tables which are specified by the JEDEC standard and there are 
vendor tables.
>> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
>>
>> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
>> ---
>>   .../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> index 587af4968255..98fd954598ab 100644
>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> @@ -103,6 +103,20 @@ properties:
>>     spi-cpol: true
>>     spi-cpha: true
>>
>> +  sfdp:
>> +    $ref: /schemas/nvmem/nvmem.yaml#
>> +    unevaluatedProperties: false
>> +    description:
>> +      The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
>> +      read-only NVMEM device. This allows standard or vendor-specific SFDP
>> +      data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
>> +      consumed through NVMEM cells.
>> +    properties:
>> +      compatible:
>> +        const: jedec,sfdp
>> +    required:
>> +      - compatible
> 
> Where are any resources? What sort of sub-device is represented here by
> an empty device node?
The sub-device describes the flash's SFDP region exposed as a read-only 
NVMEM provider:the SPI NOR core reads the SFDP and registers it as an 
NVMEM device rooted at this node.Its contents are then consumed through 
NVMEM cells -- a "fixed-layout" for data at a known offset, or an 
"nvmem-layout" parser for data whose location must be discovered at 
runtime (the Microchip EUI layout driver in patch 4/7 does the latter).
It is not a bus-addressed hardware sub-device, so it has no reg.

This models the SFDP-as-NVMEM approach suggested during the v3 review, 
instead of special-casing the vendor table in the SPI NOR core:

https://lore.kernel.org/linux-arm-kernel/20250521070336.402202-1-manikandan.m@microchip.com/
> 
> Best regards,
> Krzysztof
> 


-- 
Thanks and Regards,
Manikandan M.

^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-07-02  6:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
	Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
	anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260624195704.5c29c0353163babb721585ca@linux-foundation.org>

On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous. Two techniques are used:
>
> Thanks.
>
> > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> >    segments
> > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> >    layers
> >
> > Besides accelerating the mapping path, this also enables large
> > mappings (PMD and cont-PTE) for vmap, which are currently not
> > supported.
> >
> > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > CONT-PTE regions instead of just one.
> >
> > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> >
> > Patch 4 extends the page table walk path to support page shifts other
> > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > to vmap_pages_range_noflush_walk().
> >
> > Patches 5-6 add huge vmap support for contiguous pages, including
> > support for non-compound pages with pfn alignment verification.
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> >   VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
>
> Nice.
>
> > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
>
> Indeed.
>
> I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> folks) have time to go through this.
>
> Is there any effect on anything other than arm64?  I'm wondering how
> much testing these changes will really get in mm.git and linux-next.
>
> How is our selftests coverage of these changes?  Is there some existing
> selftest which will exercise these new features?
>

Hi Andrew,

I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
x86_64, comparing base (v7.0.10) against the patched kernel.

All test_vmalloc subtests passed on both platforms. I do not see any
functional or performance regression. The small differences below look
like measurement noise.

ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
5 runs averaged):

 +------------------------------+------------+------------+--------+
 | Test                         | Base(usec) |Patch(usec) | Change |
 +------------------------------+------------+------------+--------+
 | fix_size_alloc_test          |     935371 |     913368 |  -2.4% |
 | full_fit_alloc_test          |    1208295 |    1244718 |  +3.0% |
 | long_busy_list_alloc_test    |   35669866 |   35854584 |  +0.5% |
 | random_size_alloc_test       |   20122611 |   20200013 |  +0.4% |
 | fix_align_alloc_test         |    3240373 |    3288431 |  +1.5% |
 | random_size_align_alloc_test |    4822107 |    4792305 |  -0.6% |
 | pcpu_alloc_test              |      87641 |      89429 |  +2.0% |
 | Total cycles                 | 1586173575 | 1593193228 |  +0.4% |
 +------------------------------+------------+------------+--------+

x86_64 (Intel i7-8700, bare metal, pinned to CPU 0, performance governor,
5 runs averaged):

 +------------------------------+-------------+-------------+--------+
 | Test                         |  Base(usec) | Patch(usec) | Change |
 +------------------------------+-------------+-------------+--------+
 | fix_size_alloc_test          |      447739 |      439655 |  -1.8% |
 | full_fit_alloc_test          |      572719 |      575582 |  +0.5% |
 | long_busy_list_alloc_test    |     8544326 |     8635052 |  +1.1% |
 | random_size_alloc_test       |     4475421 |     4490037 |  +0.3% |
 | fix_align_alloc_test         |     1725389 |     1712483 |  -0.7% |
 | random_size_align_alloc_test |     2192646 |     2215064 |  +1.0% |
 | pcpu_alloc_test              |       50354 |       51911 |  +3.1% |
 | Total cycles                 | 57494755150 | 57703906913 |  +0.4% |
 +------------------------------+-------------+-------------+--------+

> You diligently went through the Sashiko report against v3 (thanks).
> Please pass an eye across its v4 report, see if something new popped
> up?
>         https://sashiko.dev/#/patchset/20260618084726.1070022-1-jiangwen6@xiaomi.com
>

I've gone through the Sashiko findings:

- Patch 5 (CONFIG_HAVE_ARCH_HUGE_VMAP): Over-interpretation.
  CONFIG_HAVE_ARCH_HUGE_VMAP is correct — it gates
  arch_vmap_pmd_supported() and arch_vmap_pte_supported_shift() which
  this code calls.

- Patch 5 (__ffs(page_to_pfn())): Over-interpretation. Never appears.

- Patch 6 (GFP_KERNEL triggering reclaim on alignment failure):
  Over-interpretation. The same GFP_KERNEL is used by the
  existing get_vm_area_caller() — no behavioral change.

Best Regards,
Wen


^ permalink raw reply
* Re: [PATCH v3 2/2] i2c: cadence: Add support for Axiado AX3000
From: Michal Simek @ 2026-07-02  6:35 UTC (permalink / raw)
  To: Swark Yang, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc
In-Reply-To: <20260630-axiado-ax3000-cadence-i2c-support-v3-2-4e217cfe5904@axiado.com>



On 7/1/26 06:48, Swark Yang wrote:
> The Axiado AX3000 SoC integrates a Cadence I2C controller
> that supports SMBus Quick commands.
> 
> Introduce the "axiado,ax3000-i2c" compatible string and
> add a new quirk CDNS_I2C_ENABLE_SMBUS_QUICK to enable
> this functionality. This allows the controller to support
> I2C_FUNC_SMBUS_QUICK, enabling features such as bus scanning
> via quick write commands.
> 
> Additionally, enabling SMBus Quick emulation in the I2C core exposes
> the controller to potential 0-length reads. Because the Cadence IP
> does not natively support 0-length reads (writing 0 to the transfer
> size register leaves the hardware in an unsupported state), this patch
> also populates the adapter quirks with I2C_AQ_NO_ZERO_LEN_READ.

nit: Avoid "this patch". Just use ", populate ..."


> This ensures 0-length reads are safely rejected by the core, preventing
> potential bus hangs.
> 
> Signed-off-by: Swark Yang <syang@axiado.com>
> ---
>   drivers/i2c/busses/i2c-cadence.c | 23 +++++++++++++++++++++++
>   1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index 0fb728ade92e..1964ea1650c5 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -128,6 +128,7 @@
>   #define CDNS_I2C_TIMEOUT_MAX	0xFF
>   
>   #define CDNS_I2C_BROKEN_HOLD_BIT	BIT(0)
> +#define CDNS_I2C_ENABLE_SMBUS_QUICK	BIT(1)
>   #define CDNS_I2C_POLL_US	100000
>   #define CDNS_I2C_POLL_US_ATOMIC	10
>   #define CDNS_I2C_TIMEOUT_US	500000
> @@ -1175,10 +1176,14 @@ static int cdns_i2c_master_xfer_atomic(struct i2c_adapter *adap, struct i2c_msg
>    */
>   static u32 cdns_i2c_func(struct i2c_adapter *adap)
>   {
> +	struct cdns_i2c *id = adap->algo_data;
>   	u32 func = I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR |
>   			(I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
>   			I2C_FUNC_SMBUS_BLOCK_DATA;
>   
> +	if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
> +		func |= I2C_FUNC_SMBUS_QUICK;
> +
>   #if IS_ENABLED(CONFIG_I2C_SLAVE)
>   	func |= I2C_FUNC_SLAVE;
>   #endif
> @@ -1442,9 +1447,24 @@ static const struct cdns_platform_data r1p10_i2c_def = {
>   	.quirks = CDNS_I2C_BROKEN_HOLD_BIT,
>   };
>   
> +static const struct cdns_platform_data ax3000_i2c_def = {
> +	.quirks = CDNS_I2C_ENABLE_SMBUS_QUICK,
> +};
> +
> +/*
> + * The controller does not support zero-length reads. Enabling SMBus Quick
> + * commands would otherwise let the core emulate a Quick read as a zero-length
> + * read message, which writes 0 to the transfer size register and leaves the
> + * hardware in an unsupported state. Reject such transfers in the core.
> + */
> +static const struct i2c_adapter_quirks cdns_i2c_quirks = {
> +	.flags = I2C_AQ_NO_ZERO_LEN_READ,
> +};
> +
>   static const struct of_device_id cdns_i2c_of_match[] = {
>   	{ .compatible = "cdns,i2c-r1p10", .data = &r1p10_i2c_def },
>   	{ .compatible = "cdns,i2c-r1p14",},
> +	{ .compatible = "axiado,ax3000-i2c", .data = &ax3000_i2c_def },
>   	{ /* end of table */ }
>   };
>   MODULE_DEVICE_TABLE(of, cdns_i2c_of_match);
> @@ -1510,6 +1530,9 @@ static int cdns_i2c_probe(struct platform_device *pdev)
>   		id->quirks = data->quirks;
>   	}
>   
> +	if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
> +		id->adap.quirks = &cdns_i2c_quirks;
> +
>   	id->rinfo.pinctrl = devm_pinctrl_get(&pdev->dev);
>   	if (IS_ERR(id->rinfo.pinctrl)) {
>   		int err = PTR_ERR(id->rinfo.pinctrl);
> 

Wiring looks good to me.

Acked-by: Michal Simek <michal.simek@amd.com>

Thanks,
Michal


^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Krzysztof Kozlowski @ 2026-07-02  6:33 UTC (permalink / raw)
  To: Coia Prant
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
	Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
	linux-rockchip, linux-kernel
In-Reply-To: <20260701164543.3967388-7-coiaprant@gmail.com>

On Thu, Jul 02, 2026 at 12:45:45AM +0800, Coia Prant wrote:
> Document the Graperain G3568 v2, which is a development board based on
> the Rockchip RK3568 SoC.
> 
> Graperain G3568 series also have an SBC series with the suffix "box".
> 
> Graperain G3568 v2 belongs to development board series, not SBC series.
> 
> Link: https://www.graperain.cn/RK3568/RK3568-Development/ (China)
> Link: https://www.graperain.com/ARM-Embedded-RK3568-Development-Board/ (Global)
> Link: https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
> 
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof



^ permalink raw reply
* Re: [PATCH v2 05/19] ARM: turn CONFIG_ATAGS off by default
From: Arnd Bergmann @ 2026-07-02  6:31 UTC (permalink / raw)
  To: Ethan Nelson-Moore, Arnd Bergmann
  Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
	Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
	Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
	Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
	Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
	Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
	Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
	Will Deacon, Linus Walleij
In-Reply-To: <CADkSEUhif4s5sSHe-bMapxEiM4bksaNkS+R5EtWOV2kgsk-29w@mail.gmail.com>

On Thu, Jul 2, 2026, at 00:22, Ethan Nelson-Moore wrote:

>> --- a/arch/arm/configs/stm32_defconfig
>> +++ b/arch/arm/configs/stm32_defconfig
>> @@ -20,7 +20,8 @@ CONFIG_ARCH_STM32=y
>>  CONFIG_CPU_V7M_NUM_IRQ=240
>>  CONFIG_SET_MEM_PARAM=y
>>  CONFIG_DRAM_BASE=0x90000000
>> -# CONFIG_ATAGS is not set
>> +CONFIG_FLASH_MEM_BASE=0x08000000
>> +CONFIG_FLASH_SIZE=0x00200000
>
> ^ These shouldn't be here - they depend on CPU_ARM740T || CPU_ARM946E
> || CPU_ARM940T, and they were manually removed previously. If they got
> added when you did make savedefconfig, I'm not sure why, given that
> dependency.

This likely happened during a rebase

> Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> (assuming
> these issues are fixed)

Thanks, fixed all now for v3

      Arnd


^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Krzysztof Kozlowski @ 2026-07-02  6:16 UTC (permalink / raw)
  To: Manikandan Muralidharan
  Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
	vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
	arnd, michael, linux-mtd, devicetree, linux-kernel,
	linux-arm-kernel, netdev
In-Reply-To: <20260630092406.150587-2-manikandan.m@microchip.com>

On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its

What is SFDP?

> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
> 
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
> ---
>  .../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 587af4968255..98fd954598ab 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -103,6 +103,20 @@ properties:
>    spi-cpol: true
>    spi-cpha: true
>  
> +  sfdp:
> +    $ref: /schemas/nvmem/nvmem.yaml#
> +    unevaluatedProperties: false
> +    description:
> +      The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
> +      read-only NVMEM device. This allows standard or vendor-specific SFDP
> +      data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
> +      consumed through NVMEM cells.
> +    properties:
> +      compatible:
> +        const: jedec,sfdp
> +    required:
> +      - compatible

Where are any resources? What sort of sub-device is represented here by
an empty device node?

Best regards,
Krzysztof



^ permalink raw reply
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Krzysztof Kozlowski @ 2026-07-02  6:23 UTC (permalink / raw)
  To: Gokul Praveen
  Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
	linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
	vkoul, yamonkar
In-Reply-To: <20260701142457.81874-2-g-praveen@ti.com>

On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
> Update maxItems value of "clocks" property to 3 as description of
> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
> and phy_en_refclk(optional)).

But what if description is wrong? You need to provide rationale why you
are doing it and you cannot use existing code alone as that rationale,
because as you pointed out - existing code is not fully correct.

> 
> Update the maxItems and items value of "clock-names" property with multiple
> combination of clock-names possible since pll1_refclk and phy_en_refclk are
> optional clocks.

Why? You need to describe why you are doing this, not what you are
doing.

> 
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
>  .../bindings/phy/phy-cadence-torrent.yaml        | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646a..96c664d50629 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>  
>    clocks:
>      minItems: 1
> -    maxItems: 2
> +    maxItems: 3
>      description:
>        PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
>        pll1_refclk is optional and used for multi-protocol configurations requiring
> @@ -45,9 +45,17 @@ properties:
>  
>    clock-names:
>      minItems: 1
> -    items:
> -      - const: refclk
> -      - enum: [ pll1_refclk, phy_en_refclk ]
> +    maxItems: 3

Drop

> +    oneOf:
> +      - items:
> +          - const: refclk
> +      - items:
> +          - const: refclk
> +          - enum: [ pll1_refclk, phy_en_refclk ]

Drop these, pointless. You were supposed to grow existing syntax.

> +      - items:
> +          - const: refclk
> +          - const: pll1_refclk

So here is the enum.

> +          - const: phy_en_refclk

And this stays.

You make changes which do not make the binding better and are not
explained in commit msg. Focus on WHY you are doing things and also
explain WHY you did such complicated syntax (if you insist on rewriting
correct code into something odd we do not expect).

Best regards,
Krzysztof



^ permalink raw reply
* Re: [PATCH net v2] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-07-02  6:21 UTC (permalink / raw)
  To: Lorenzo Bianconi
  Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
	linux-kernel, aniket.negi
In-Reply-To: <akWYEf5wusTq9_ol@lore-desk>

> > Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
> 
> Hi Aniket,
> 
> just few nits inline. Fixing them:
> 
> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> 

Ok sure. I'll update.

> > +	dev->stats.mib_prev.tx_runt_cnt = val;
> > +
> > +	/* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
> > +	 * Accumulate RUNT delta in tx_runt_accum64, then assign tx_len[0] as
> > +	 * accum + E64_abs so each call gives the correct combined total.
> > +	 */
> 
> no new-line here.
> 
> > +
> > +	dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt_accum64;
> 

Sure, You are reffering to both the spaces above and below comment section?. Same for rx_runt and rx_long/tx_long.

I'll update as following:
 +	dev->stats.mib_prev.tx_runt_cnt = val;
 +	/* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
 +	 * Accumulate RUNT delta in tx_runt_accum64, then assign tx_len[0] as
 +	 * accum + E64_abs so each call gives the correct combined total.
 +	 */
 +	dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt_accum64;

> > +		u32 tx_drops;
> > +		u32 tx_broadcast;
> > +		u32 tx_multicast;
> > +		u32 tx_runt_cnt;
> 
> 		u32 tx_runt;
> 
> > +		u32 tx_long_cnt;
> 
> 		u32 tx_long;
> 
> > +		u64 tx_runt_accum64;
> 
> 		64 tx_runt64;
> 
> > +		u32 rx_drops;
> > +		u32 rx_broadcast;
> > +		u32 rx_multicast;
> > +		u32 rx_errors;
> > +		u32 rx_crc_error;
> > +		u32 rx_over_errors;
> > +		u32 rx_fragment;
> > +		u32 rx_jabber;
> > +		u32 rx_runt_cnt;
> 
> 		u32 rx_runt;
> 
> > +		u32 rx_long_cnt;
> 
> 		u32 rx_long;
> 
> > +		u64 rx_runt_accum64;
> 
> 		u64 rx_runt64;
> 
> > +	} mib_prev;
> >  };

Acked the change name from tx_runt_cnt to tx_run, tx_long_cnt to tx_long, tx_runt_accum64 to tx_runt64. Same for rx counters.

Best Regards,
Aniket Negi


^ permalink raw reply
* Re: [PATCH 0/5] Backport ARM64 VHE boot fixes to 6.6.y
From: Greg KH @ 2026-07-02  6:16 UTC (permalink / raw)
  To: Colton Lewis
  Cc: stable, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
	James Morse, Suzuki K Poulose, Zenghui Yu, Mingwei Zhang,
	linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701204342.2654385-1-coltonlewis@google.com>

On Wed, Jul 01, 2026 at 08:43:37PM +0000, Colton Lewis wrote:
> This series backports VHE CPU boot fixes to the 6.6.y stable branch.
> 
> These fixes are already present in the 6.12.y stable branch (and
> newer), but are missing in 6.6.y. They are required to enable booting
> L1 guests with nested virtualization enabled (kvm-arm.mode=nested).
> 
> Without these patches, a 6.6.y guest boots with HCR_EL2.E2H
> incorrectly configured (because it misses VHE-only detection or early
> initialization), causing early boot hangs/trap loops.

Why is this needed for 6.6.y?  Why not just use 6.12.y and newer for
systems that require this new feature?  What is preventing that from
happening?

thanks,

greg k-h


^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan.M @ 2026-07-02  6:13 UTC (permalink / raw)
  To: linusw, michael
  Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
	vigneshr, robh, krzk+dt, conor+dt, srini, Nicolas.Ferre,
	alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
	linux-mtd, devicetree, linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <CAD++jLntmnwU3gAQfDn2nd4CQ_7HY6S_kBguVtZvVT1PktFCPw@mail.gmail.com>

On 7/1/26 4:23 PM, Linus Walleij wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Wed, Jul 1, 2026 at 10:34 AM Michael Walle <michael@walle.cc> wrote:
> 
>> If I'm correct, this is the old style, see commit bd912c991d2e
>> ("dt-bindings: nvmem: layouts: add fixed-layout"). So it should
>> eventually look like:
>>
>> sfdp {
>>       compatible = "jedec,sfdp";
> (...)
>> Also I'm not sure if we really need to add the "nvmem-cells" here.
>> IIRC in MTD it was there to tell a driver to add an nvmem device to
>> an already existing compatible/node.
>>
>> Apart from the MTD case, I've just found qcom,smem-part,yaml which
>> has compatible = "nvmem-cells".
> 
> You're right, I was using old information, discard my comments...
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> 
> I think my comment in the driver to check for the compatible
> instead of the node name is still valid though.
Thank you Linus Wallejj and Michael.
I will address the driver changes in the next version.
> 
> Yours,
> Linus Walleij


-- 
Thanks and Regards,
Manikandan M.

^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-02  6:09 UTC (permalink / raw)
  To: Markus Probst, Alexandre Belloni
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Uwe Kleine-König, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
	linux-kernel
In-Reply-To: <74b32ed0a700e3900c0f34d730b2b5b69eb2ca19.camel@posteo.de>

On 01/07/2026 19:08, Markus Probst wrote:
> On Wed, 2026-07-01 at 18:48 +0200, Alexandre Belloni wrote:
>> On 01/07/2026 16:43:07+0000, Markus Probst wrote:
>>> On Wed, 2026-07-01 at 17:14 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/07/2026 15:25, Markus Probst wrote:
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>>>>
>>>>>> This should be someone caring about this hardware.
>>>>> He does have the majority of commits on this driver (excluding merge
>>>>> commits and commits not exclusive to this driver), although most of
>>>>> them are pretty tiny.
>>>>>
>>>>> Who would you suggest instead?
>>>>
>>>> Someone adding features for this driver, maybe driver maintainers. But
>>>> if Alexandre is fine, you can leave him.
>>>>
>>>>>>
>>>>>>> +
>>>>>>> +description:
>>>>>>> +  The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
>>>>>>> +  very low current consumption in the wide range of operation voltage.
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> +  - $ref: rtc.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    const: sii,s35390a
>>>>>>> +
>>>>>>> +  reg:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  sii,wakealarm-output-pin:
>>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>> +    enum: [1, 2]
>>>>>>> +    description: |
>>>>>>> +      The output pin to wake up the system.
>>>>>>> +      Default will use the output pin for interrupt signal 2.
>>>>>>> +        <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
>>>>>>> +        <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
>>>>>>
>>>>>> Does that mean device generates the interrupts?
>>>>> Yes.
>>>>>
>>>>
>>>>
>>>> Then I think you miss interrupts property.
>>> From what I can tell the line is used to generate a system wakeup
>>> event.
>>>
>>> There would be no obvious benefit of connecting it to an interrupt
>>> controller, so this property would be obsolete?
>>>
>>
>> Then you need proper wakeup-source support
> Wouldn't that break existing devicetrees?

How?

> 
> The current driver allows to wake up the system, even without
> having wakeup-source set.

Anyway, wakeup-source is already there in rtc, so this would be done. I
don't get though, why there is no benefit of routing it to interrupt
controller (interrupt controllers do wake up the system). Additionally,
if you do not connect it to any interrupt, then how does it wake up the
system?

Best regards,
Krzysztof


^ permalink raw reply
* Re: [PATCH v2 06/19] ARM: mark CPU_ENDIAN_BE8 as deprecated
From: Arnd Bergmann @ 2026-07-02  6:02 UTC (permalink / raw)
  To: Ethan Nelson-Moore, Arnd Bergmann
  Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
	Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
	Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
	Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
	Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
	Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
	Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
	Will Deacon
In-Reply-To: <CADkSEUgm4yX36W6dG-5WOm42Z3iDpHVcz73suWDN3=bsGgq+0g@mail.gmail.com>

On Wed, Jul 1, 2026, at 23:57, Ethan Nelson-Moore wrote:
>> At the moment, there are no known bugs with big-endian ARMv7 mode, but
>> it does break occasionally and require someone to fix it.  By marking
>> the code as 'depends on BROKEN' now, it will no longer be covered by CI
>> testing. If any users remain, they can keep patching out the dependency
>> but are more likely to run into regressions.
>>
>> The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
>> still used on Intel IXP4xx platform, and is the only currently supported
>> mode there, so this one can still be enabled.
>
> If IXP4xx is the only known remaining user, would it make sense for
> CPU_BIG_ENDIAN to instead depend on ARCH_IXP4XX || BROKEN? Is BE32
> mode known to work correctly on any other platforms?

This is essentially what we have, just expressed the other way round:
all ARMv4/v4t/v5 platforms depend on CONFIG_CPU_LITTLE_ENDIAN, except
for IXP4xx, which depends on CONFIG_CPU_BIG_ENDIAN.

        Arnd


^ permalink raw reply
* Re: [PATCH v2 18/19] ARM: mark axxia platform as deprecated
From: Arnd Bergmann @ 2026-07-02  5:57 UTC (permalink / raw)
  To: Ethan Nelson-Moore, Arnd Bergmann
  Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
	Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
	Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
	Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
	Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
	Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
	Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
	Will Deacon, Andre Przywara
In-Reply-To: <CADkSEUhWe9aLuM7AURDKjMkrpEKOog9X59fWuZXvUVjkT9BuBw@mail.gmail.com>

On Thu, Jul 2, 2026, at 00:41, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Wed, Jul 1, 2026 at 2:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>
> All of these patches have this line at the beginning but were sent
> from your kernel.org email - did something go wrong with git
> send-email?

I should fix this, but it's been like this for a while after
I had patch emails get rejected too much for coming from my
arndb.de domain.

>>  config ARCH_AXXIA
>> -       bool "LSI Axxia platforms"
>> +       bool "LSI Axxia platforms (DEPRECATED)"
>>         depends on ARCH_MULTI_V7 && ARM_LPAE
>
> The dependency on LPAE reminded me of two other 32-bit ARM platforms
> with lots of memory: Calxeda Midway and Highbank. Is anyone still
> using those? Maybe they could be removed, since people seem to want to
> remove highmem:
> https://lwn.net/Articles/813201/
> https://static.linaro.org/connect/lvc20/presentations/LVC20-106-0.pdf

Andre Przywara used to use those for testing, I don't think anyone
else has powered them on for a while, see

https://lore.kernel.org/all/9723b5df-e218-1ea9-e8eb-9e781b23af49@arm.com/

If it gets in the way, or Andre gets tired of maintaining it,
we can remove it, until then I would keep it. Axxia is different
because it's neither maintained nor functional.

There are a few more platforms that need highmem for the time
being:

 - TI keystone2 has users and is well maintained, so this will
   stay as long as we can justify holding up highmem removal
   for it. This one has a unique way of dealing with coherent
   DMA that requires LPAE and possibly highmem.

 - Renesas R-Car M1 need lpae support for (IIRC) >1GB
   configurations, and I have a prototype patch
   to make that one work with a modified virt_to_phys()
   implementation.

 - Amazon/Annapurna Alpine is similar to Axxia in the 
   current state of upstream support, but has someone
   working on an OpenWRT port using the downstream
   patches. The OpenWRT supported devices all have 2GB
   or less.

A few others need highmem for large memory configs
with more than 2GB of RAM but would stay working for
the common configurations with 2GB or less, using
CONFIG_VMSPLIT_2G_OPT.

     Arnd


^ permalink raw reply
* Re: [PATCH v5 11/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Kyrie Wu (吴晗) @ 2026-07-02  5:39 UTC (permalink / raw)
  To: conor@kernel.org
  Cc: AngeloGioacchino Del Regno, Kyrie Wu (吴晗),
	laurent.pinchart+renesas@ideasonboard.com,
	nicolas.dufresne@collabora.com, jacopo.mondi@ideasonboard.com,
	Yunfei Dong (董云飞), conor+dt@kernel.org,
	Irui Wang (王瑞), rongqianfeng@vivo.com,
	tzungbi@kernel.org, tfiga@chromium.org, robh@kernel.org,
	wenst@chromium.org, benjamin.gaignard@collabora.com,
	matthias.bgg@gmail.com, haoxiang_li2024@163.com,
	ribalda@chromium.org, Tiffany Lin (林慧珊),
	linux-mediatek@lists.infradead.org, p.zabel@pengutronix.de,
	sebastian.fricke@collabora.com, fshao@chromium.org,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	mchehab@kernel.org, fanwu01@zju.edu.cn,
	linux-arm-kernel@lists.infradead.org,
	Andrew-CT Chen (陳智迪), krzk+dt@kernel.org,
	hverkuil+cisco@kernel.org, linux-kernel@vger.kernel.org,
	kees@kernel.org, sakari.ailus@linux.intel.com
In-Reply-To: <20260603-pentagram-unleveled-8729d0003aa7@spud>

On Wed, 2026-06-03 at 17:14 +0100, Conor Dooley wrote:
> On Wed, Jun 03, 2026 at 04:40:41PM +0800, Kyrie Wu wrote:
> > From: Yunfei Dong <yunfei.dong@mediatek.com>
> > 
> > The MT8196 decoder differs from previous generations in several
> > key aspects, most notably in its use of VCP instead of SCP.
> > Additionally, the MT8196 enhances codec capabilities by supporting
> > HEVC Main10 profile decoding. To accommodate these hardware
> > changes,
> > the binding constraints specify a total of 12 clock inputs,
> > consisting of 9 decoder clocks and 3 VCP interface clocks,
> > along with 2 power domains covering both the decoder and VCP
> > subsystems.
> 
> I'm pretty pretty confused by this statement about constraints, since
> there's none added?
> The vcodec-dec node doesn't even seem to permit clocks at all?
> 
Dear Conor,

I apologize for any confusion my commit message caused. What I wanted
to convey was the hardware differences between the MT8196 and previous
ICs. If you feel that the VCP and clock information are not suitable
for this location, I would like to rewrite the commit message as
follows:
Compared to previous ICs, the MT8196 supports a 10-bit decoder and has
a decoding capability of 4K@120fps, using a dual hardware decoding
architecture of LAT+CORE.

Thanks.

Regards,
Kyrie.
> > 
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > ---
> >  .../bindings/media/mediatek,vcodec-subdev-decoder.yaml           | 
> > 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > index bf8082d87ac0..74e1d88d3056 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-
> > subdev-decoder.yaml
> > +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-
> > subdev-decoder.yaml
> > @@ -76,6 +76,7 @@ properties:
> >        - mediatek,mt8186-vcodec-dec
> >        - mediatek,mt8188-vcodec-dec
> >        - mediatek,mt8195-vcodec-dec
> > +      - mediatek,mt8196-vcodec-dec
> >  
> >    reg:
> >      minItems: 1
> > -- 
> > 2.45.2
> > 

^ permalink raw reply
* Re: [PATCH v2 07/19] ARM: update DEPRECATED_PARAM_STRUCT removal timeline
From: Arnd Bergmann @ 2026-07-02  5:36 UTC (permalink / raw)
  To: Ethan Nelson-Moore, Arnd Bergmann
  Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
	Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
	Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
	Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
	Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
	Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
	Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
	Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
	Will Deacon
In-Reply-To: <CADkSEUhO9nhzQZCS7ZziCtMna+ibfj9_PbSH5R+c0pyi5viCvg@mail.gmail.com>

On Thu, Jul 2, 2026, at 02:54, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Wed, Jul 1, 2026 at 2:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> This configuration option is for the older boot method that preceeded
>> ATAGS. This was scheduled for removal back in 2001, but the removal
>> never happened, presumably because nobody cared enough to actually do it,
>> not because there are any users left.
>
> Only netwinder_defconfig selects this option. Do the most recent
> NetWinder firmware versions actually need it? (LinusW, do you know
> this?) If not, can't we just drop it entirely?

If all StrongARM platforms are on the way out after the LTS kernel,
I don't see a need to remove this any earlier, even if the chance
that it's still needed is low.

       Arnd


^ permalink raw reply
* Re: [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Dev Jain @ 2026-07-02  5:18 UTC (permalink / raw)
  To: muchun.song, osalvador, akpm, ljs, david, liam
  Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
	linux-kernel, rcampbell, apopple, ziy, matthew.brost,
	joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
	nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
	catalin.marinas, will, linux-arm-kernel, ryan.roberts,
	anshuman.khandual
In-Reply-To: <20260702051341.126509-7-dev.jain@arm.com>



On 02/07/26 10:43 am, Dev Jain wrote:
> prot_none_hugetlb_entry() is the hugetlb callback for the early
> mprotect(PROT_NONE) PFN permission walk on x86.
> 
> The callback passes the decoded PFN to pfn_modify_allowed(). For a
> hugetlb callback, the pte pointer refers to a hugetlb entry. On
> architectures where hugetlb entries need huge_ptep_get(), reading that
> entry with ptep_get() can make the permission check use the wrong PFN.
> 
> Use huge_ptep_get() before decoding the hugetlb PFN.
> 
> Currently there is no path which can trigger a bug: huge_ptep_get() is a
> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
> 
> So no need to backport - use the correct helper anyways.
> 
> Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---

@Muchun, I did not do the change you suggested: if we do #ifdef around
the hugetlb callback, then for CONFIG_HUGETLB_PAGE=n, prot_none_hugetlb_entry()
is defined but not used, giving compile error.


>  mm/mprotect.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 9cbf932b028cf..23779632d18bf 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
>  		0 : -EACCES;
>  }
>  
> +#ifdef CONFIG_HUGETLB_PAGE
>  static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
>  				   unsigned long addr, unsigned long next,
>  				   struct mm_walk *walk)
>  {
> -	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
> +	pte_t entry = huge_ptep_get(walk->mm, addr, pte);
> +
> +	return pfn_modify_allowed(pte_pfn(entry),
>  				  *(pgprot_t *)(walk->private)) ?
>  		0 : -EACCES;
>  }
> +#else
> +#define prot_none_hugetlb_entry	NULL
> +#endif
>  
>  static int prot_none_test(unsigned long addr, unsigned long next,
>  			  struct mm_walk *walk)



^ permalink raw reply
* [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Dev Jain @ 2026-07-02  5:13 UTC (permalink / raw)
  To: muchun.song, osalvador, akpm, ljs, david, liam
  Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
	linux-kernel, rcampbell, apopple, ziy, matthew.brost,
	joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
	nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
	catalin.marinas, will, linux-arm-kernel, ryan.roberts,
	anshuman.khandual
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>

prot_none_hugetlb_entry() is the hugetlb callback for the early
mprotect(PROT_NONE) PFN permission walk on x86.

The callback passes the decoded PFN to pfn_modify_allowed(). For a
hugetlb callback, the pte pointer refers to a hugetlb entry. On
architectures where hugetlb entries need huge_ptep_get(), reading that
entry with ptep_get() can make the permission check use the wrong PFN.

Use huge_ptep_get() before decoding the hugetlb PFN.

Currently there is no path which can trigger a bug: huge_ptep_get() is a
simple ptep_get() for x86, and the prot_none walk occurs only for x86.

So no need to backport - use the correct helper anyways.

Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
 mm/mprotect.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/mprotect.c b/mm/mprotect.c
index 9cbf932b028cf..23779632d18bf 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 		0 : -EACCES;
 }
 
+#ifdef CONFIG_HUGETLB_PAGE
 static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
 				   struct mm_walk *walk)
 {
-	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
+	pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+	return pfn_modify_allowed(pte_pfn(entry),
 				  *(pgprot_t *)(walk->private)) ?
 		0 : -EACCES;
 }
+#else
+#define prot_none_hugetlb_entry	NULL
+#endif
 
 static int prot_none_test(unsigned long addr, unsigned long next,
 			  struct mm_walk *walk)
-- 
2.43.0



^ permalink raw reply related
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox