* [PATCH v16 00/12] Enable jpeg enc & dec multi-hardwares for MT8196
From: Kyrie Wu @ 2026-07-20 13:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Bin Liu, kyrie wu, Hans Verkuil, irui wang, Nicolas Dufresne,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Kyrie Wu
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 buffer state update timing
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 v15:
--Set max_hw_count from the DT child count and update hw_rdy from child hardware probes in patch 1.
--Fix patch 2 commit message wording per review.
--Rework patch 6 commit message per review.
--Remove redundant devm_clk_bulk_get() calls in patch 5 per review comments.
--Use %pe to print smmu_regmap error pointer in patch 12 to fix media-ci/static warnings.
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 buffer state update timing
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 | 156 +++++++++++++-----
.../platform/mediatek/jpeg/mtk_jpeg_core.h | 19 ++-
.../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 84 +++++++++-
.../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 82 ++++++++-
6 files changed, 300 insertions(+), 57 deletions(-)
--
2.51.0.windows.2
^ permalink raw reply
* [PATCH v16 04/12] media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop
From: Kyrie Wu @ 2026-07-20 13:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Bin Liu, kyrie wu, Hans Verkuil, irui wang, Nicolas Dufresne,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Kyrie Wu
In-Reply-To: <20260720133432.1042046-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>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.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 7856a556c..d0fb68bc8 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.51.0.windows.2
^ permalink raw reply related
* [PATCH v16 02/12] media: mediatek: jpeg: fix jpeg buffer payload size setting
From: Kyrie Wu @ 2026-07-20 13:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Bin Liu, kyrie wu, Hans Verkuil, irui wang, Nicolas Dufresne,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Kyrie Wu
In-Reply-To: <20260720133432.1042046-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 not matching the real
buffer length.
The payload size must be less than the real buffer length to avoid
warning logs.
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.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 41c4cf8dc..34135706a 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.51.0.windows.2
^ permalink raw reply related
* [PATCH v16 03/12] media: mediatek: jpeg: fix buffer structure size and layout
From: Kyrie Wu @ 2026-07-20 13:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Bin Liu, kyrie wu, Hans Verkuil, irui wang, Nicolas Dufresne,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Kyrie Wu
In-Reply-To: <20260720133432.1042046-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 34135706a..7856a556c 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 6be5cf30d..148fd4175 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.51.0.windows.2
^ permalink raw reply related
* Re: [PATCH 3/3] nvmem: mtk-efuse: add mt6572 support
From: Roman Vivchar @ 2026-07-20 13:33 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <2aa16ed7-5d36-4e78-929e-84b9d6befe77@collabora.com>
Hi Angelo,
On Monday, July 20th, 2026 at 3:48 PM, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote:
> On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> > From: Roman Vivchar <rva333@protonmail.com>
> >
> > Add a platform data struct for the efuse controller.
> >
> > Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> > ---
> > drivers/nvmem/mtk-efuse.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> > index 1462f2760818..a79434608465 100644
> > --- a/drivers/nvmem/mtk-efuse.c
> > +++ b/drivers/nvmem/mtk-efuse.c
> > @@ -124,6 +124,11 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> > return 0;
> > }
> >
> > +static const struct mtk_efuse_pdata mtk_mt6572_efuse_pdata = {
> > + .uses_post_processing = false,
>
> Are you sure this SoC (or any other compatible with it) doesn't have any GPU speed
> binning?
>
> If you're really sure
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
It does, but we can't really rely on it. The GPU is complicated here...
Something like this:
- mfgcfg
^- mfg_pre ('safe' UNIVPLL div or 'unsafe' mfg mux)
^- mfg (if you're here and your chip is NOT mt6572w then be prepared
for crashes)
^- whpll (or any other parent, but downstream uses WHPLL as GPU
clock source)
There is GPU speedbin, but it means either GPU scaling is fine and mfg
mux is safe (0, unfused) or that the GPU must stay at UNIVPLL divider
(1, fused off).
My current solution is using assigned-clocks and assigned-clock-parents
in the each board which we've tested manually.
&gpu {
/* Switch to WHPLL */
assigned-clocks = <&topckgen CLK_TOP_MFG_SEL>,
<&topckgen CLK_TOP_MFG_PRE_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_MFG_PRE_500M>,
<&topckgen CLK_TOP_MFG_SEL>;
operating-points-v2 = <&gpu_opp_table>;
nvmem-cells = <&gpu_speedbin>;
nvmem-cell-names = "speedbin";
status = "okay";
};
On boards with GPU frequency fused off the entire setup is omitted
except status = "okay";
Let me know if you have some other idea how this should be handled.
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH 3/3] soc: mediatek: pwrap: add MT6589 PWARP and MT6320 PMIC support
From: AngeloGioacchino Del Regno @ 2026-07-20 13:27 UTC (permalink / raw)
To: Akari Tsuyukusa, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Flora Fu, Alexandre Mergnat
Cc: open list:MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS,
open list:MULTIFUNCTION DEVICES (MFD),
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260716171733.300885-4-akkun11.open@gmail.com>
On 7/16/26 19:17, Akari Tsuyukusa wrote:
> Add support for MediaTek MT6589 PWRAP and MT6320 PMIC which are used
> together.
>
> Since the PWRAP Bridge hardware on MT6589 is identical to the one on
> MT8135, refactor the existing register definitions:
> - Rename the MT8135-specific "PWRAP_MT8135_BRIDGE_" prefix to a generic
> "PWRAP_BRIDGE_" prefix to reflect that they are shared across SoCs.
> - Add the full set of PWRAP Bridge registers to match the hardware
> specification, rather than defining only a subset of them.
>
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
> ---
> drivers/soc/mediatek/mtk-pmic-wrap.c | 292 +++++++++++++++++++++------
> 1 file changed, 235 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 0bcd85826375..3a5b007d60f5 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -17,15 +17,31 @@
> #define PWRAP_POLL_DELAY_US 10
> #define PWRAP_POLL_TIMEOUT_US 10000
>
> -#define PWRAP_MT8135_BRIDGE_IORD_ARB_EN 0x4
> -#define PWRAP_MT8135_BRIDGE_WACS3_EN 0x10
> -#define PWRAP_MT8135_BRIDGE_INIT_DONE3 0x14
> -#define PWRAP_MT8135_BRIDGE_WACS4_EN 0x24
> -#define PWRAP_MT8135_BRIDGE_INIT_DONE4 0x28
> -#define PWRAP_MT8135_BRIDGE_INT_EN 0x38
> -#define PWRAP_MT8135_BRIDGE_TIMER_EN 0x48
> -#define PWRAP_MT8135_BRIDGE_WDT_UNIT 0x50
> -#define PWRAP_MT8135_BRIDGE_WDT_SRC_EN 0x54
Yeah I understand why you're renaming those, but choose:
a. You avoid renaming and add the rest as PWRAP_MT8135_XXXX; or
b. You make two commits, one for the rename (and explaining why) and one
for introducing MT6589 support.
Your choice.
> +/* MT6589 and MT8135 specific PWARP Bridge registers */
> +#define PWRAP_BRIDGE_IARB_INIT 0x0
> +#define PWRAP_BRIDGE_IORD_ARB_EN 0x4
> +#define PWRAP_BRIDGE_IARB_STA0 0x8
> +#define PWRAP_BRIDGE_IARB_STA1 0xc
> +#define PWRAP_BRIDGE_WACS3_EN 0x10
> +#define PWRAP_BRIDGE_INIT_DONE3 0x14
> +#define PWRAP_BRIDGE_WACS3_CMD 0x18
> +#define PWRAP_BRIDGE_WACS3_RDATA 0x1c
> +#define PWRAP_BRIDGE_WACS3_VLDCLR 0x20
> +#define PWRAP_BRIDGE_WACS4_EN 0x24
> +#define PWRAP_BRIDGE_INIT_DONE4 0x28
> +#define PWRAP_BRIDGE_WACS4_CMD 0x2c
> +#define PWRAP_BRIDGE_WACS4_RDATA 0x30
> +#define PWRAP_BRIDGE_WACS4_VLDCLR 0x34
> +#define PWRAP_BRIDGE_INT_EN 0x38
> +#define PWRAP_BRIDGE_INT_FLG_RAW 0x3c
> +#define PWRAP_BRIDGE_INT_FLG 0x40
> +#define PWRAP_BRIDGE_INT_CLR 0x44
> +#define PWRAP_BRIDGE_TIMER_EN 0x48
> +#define PWRAP_BRIDGE_TIMER_STA 0x4c
> +#define PWRAP_BRIDGE_WDT_UNIT 0x50
> +#define PWRAP_BRIDGE_WDT_SRC_EN 0x54
> +#define PWRAP_BRIDGE_WDT_FLG 0x58
> +#define PWRAP_BRIDGE_DEBUG_INT_SEL 0x5c
>
> /* macro for wrapper status */
> #define PWRAP_GET_WACS_RDATA(x) (((x) >> 0) & 0x0000ffff)
> @@ -100,6 +116,24 @@ enum dew_regs {
> PWRAP_DEW_CIPHER_MODE,
> PWRAP_DEW_CIPHER_SWRST,
>
> + /* MT6320 only regs */
> + PWRAP_DEW_CIPHER_IV0,
> + PWRAP_DEW_CIPHER_IV1,
> + PWRAP_DEW_CIPHER_IV2,
> + PWRAP_DEW_CIPHER_IV3,
> + PWRAP_DEW_CIPHER_IV4,
> + PWRAP_DEW_CIPHER_IV5,
> +
> + /* MT6320 and MT6397 only regs */
> + PWRAP_DEW_EVENT_OUT_EN,
> + PWRAP_DEW_EVENT_SRC_EN,
> + PWRAP_DEW_EVENT_SRC,
> + PWRAP_DEW_EVENT_FLAG,
> + PWRAP_DEW_MON_FLAG_SEL,
> + PWRAP_DEW_EVENT_TEST,
> + PWRAP_DEW_CIPHER_LOAD,
> + PWRAP_DEW_CIPHER_START,
> +
> /* MT6323 only regs */
> PWRAP_DEW_CIPHER_EN,
> PWRAP_DEW_RDDMY_NO,
> @@ -142,16 +176,34 @@ enum dew_regs {
> PWRAP_DEW_RG_WDATA_MASK,
> PWRAP_DEW_RG_SPI_RECORD_CLR,
> PWRAP_DEW_RG_CMD_ALERT_CLR,
> +};
>
> - /* MT6397 only regs */
> - PWRAP_DEW_EVENT_OUT_EN,
> - PWRAP_DEW_EVENT_SRC_EN,
> - PWRAP_DEW_EVENT_SRC,
> - PWRAP_DEW_EVENT_FLAG,
> - PWRAP_DEW_MON_FLAG_SEL,
> - PWRAP_DEW_EVENT_TEST,
> - PWRAP_DEW_CIPHER_LOAD,
> - PWRAP_DEW_CIPHER_START,
> +static const u32 mt6320_regs[] = {
> + [PWRAP_DEW_EVENT_OUT_EN] = 0x0000,
> + [PWRAP_DEW_DIO_EN] = 0x0002,
> + [PWRAP_DEW_EVENT_SRC_EN] = 0x0004,
> + [PWRAP_DEW_EVENT_SRC] = 0x0006,
> + [PWRAP_DEW_EVENT_FLAG] = 0x0008,
> + [PWRAP_DEW_READ_TEST] = 0x000a,
> + [PWRAP_DEW_WRITE_TEST] = 0x000c,
> + [PWRAP_DEW_CRC_EN] = 0x000e,
> + [PWRAP_DEW_CRC_VAL] = 0x0010,
> + [PWRAP_DEW_MON_GRP_SEL] = 0x0012,
> + [PWRAP_DEW_MON_FLAG_SEL] = 0x0014,
> + [PWRAP_DEW_EVENT_TEST] = 0x0016,
> + [PWRAP_DEW_CIPHER_KEY_SEL] = 0x0018,
> + [PWRAP_DEW_CIPHER_IV_SEL] = 0x001a,
> + [PWRAP_DEW_CIPHER_LOAD] = 0x001c,
> + [PWRAP_DEW_CIPHER_START] = 0x001e,
> + [PWRAP_DEW_CIPHER_RDY] = 0x0020,
> + [PWRAP_DEW_CIPHER_MODE] = 0x0022,
> + [PWRAP_DEW_CIPHER_SWRST] = 0x0024,
> + [PWRAP_DEW_CIPHER_IV0] = 0x0026,
> + [PWRAP_DEW_CIPHER_IV1] = 0x0028,
> + [PWRAP_DEW_CIPHER_IV2] = 0x002a,
> + [PWRAP_DEW_CIPHER_IV3] = 0x002c,
> + [PWRAP_DEW_CIPHER_IV4] = 0x002e,
> + [PWRAP_DEW_CIPHER_IV5] = 0x0030,
> };
>
> static const u32 mt6323_regs[] = {
> @@ -386,6 +438,22 @@ enum pwrap_regs {
> PWRAP_EINT_STA1_ADR,
> PWRAP_SWINF_2_WDATA_31_0,
> PWRAP_SWINF_2_RDATA_31_0,
> + PWRAP_DVFS_ADR0,
> + PWRAP_DVFS_WDATA0,
> + PWRAP_DVFS_ADR1,
> + PWRAP_DVFS_WDATA1,
> + PWRAP_DVFS_ADR2,
> + PWRAP_DVFS_WDATA2,
> + PWRAP_DVFS_ADR3,
> + PWRAP_DVFS_WDATA3,
> + PWRAP_DVFS_ADR4,
> + PWRAP_DVFS_WDATA4,
> + PWRAP_DVFS_ADR5,
> + PWRAP_DVFS_WDATA5,
> + PWRAP_DVFS_ADR6,
> + PWRAP_DVFS_WDATA6,
> + PWRAP_DVFS_ADR7,
> + PWRAP_DVFS_WDATA7,
>
> /* MT2701 only regs */
> PWRAP_ADC_CMD_ADDR,
> @@ -394,6 +462,24 @@ enum pwrap_regs {
> PWRAP_ADC_RDATA_ADDR1,
> PWRAP_ADC_RDATA_ADDR2,
>
> + /* MT6589 only regs */
> + PWRAP_CIPHER_IV0,
> + PWRAP_CIPHER_IV1,
> + PWRAP_CIPHER_IV2,
> +
> + /* MT6589 and MT8135 only regs */
> + PWRAP_CSHEXT,
> + PWRAP_EVENT_IN_EN,
> + PWRAP_EVENT_DST_EN,
> + PWRAP_RRARB_INIT,
> + PWRAP_RRARB_EN,
> + PWRAP_RRARB_STA0,
> + PWRAP_RRARB_STA1,
> + PWRAP_EVENT_STA,
> + PWRAP_EVENT_STACLR,
> + PWRAP_CIPHER_LOAD,
> + PWRAP_CIPHER_START,
> +
> /* MT7622 only regs */
> PWRAP_STA,
> PWRAP_CLR,
> @@ -422,38 +508,9 @@ enum pwrap_regs {
> PWRAP_DVFS_STEP_CTRL2,
> PWRAP_SPI2_CTRL,
>
> - /* MT8135 only regs */
> - PWRAP_CSHEXT,
> - PWRAP_EVENT_IN_EN,
> - PWRAP_EVENT_DST_EN,
> - PWRAP_RRARB_INIT,
> - PWRAP_RRARB_EN,
> - PWRAP_RRARB_STA0,
> - PWRAP_RRARB_STA1,
> - PWRAP_EVENT_STA,
> - PWRAP_EVENT_STACLR,
> - PWRAP_CIPHER_LOAD,
> - PWRAP_CIPHER_START,
> -
Why are you reordering stuff around? I don't understand.
If you have a reason, make sure it's a good one, and make a different commit
just for the reordering, because otherwise the diff for this one gets a bit
hard to read.
Cheers,
Angelo
> /* MT8173 only regs */
> PWRAP_RDDMY,
> PWRAP_SI_CK_CON,
> - PWRAP_DVFS_ADR0,
> - PWRAP_DVFS_WDATA0,
> - PWRAP_DVFS_ADR1,
> - PWRAP_DVFS_WDATA1,
> - PWRAP_DVFS_ADR2,
> - PWRAP_DVFS_WDATA2,
> - PWRAP_DVFS_ADR3,
> - PWRAP_DVFS_WDATA3,
> - PWRAP_DVFS_ADR4,
> - PWRAP_DVFS_WDATA4,
> - PWRAP_DVFS_ADR5,
> - PWRAP_DVFS_WDATA5,
> - PWRAP_DVFS_ADR6,
> - PWRAP_DVFS_WDATA6,
> - PWRAP_DVFS_ADR7,
> - PWRAP_DVFS_WDATA7,
> PWRAP_SPMINF_STA,
> PWRAP_CIPHER_EN,
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: soc: mediatek: pwrap: Add compatible for MT6589 SoC
From: AngeloGioacchino Del Regno @ 2026-07-20 13:27 UTC (permalink / raw)
To: Akari Tsuyukusa, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Flora Fu, Alexandre Mergnat
Cc: open list:MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS,
open list:MULTIFUNCTION DEVICES (MFD),
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260716171733.300885-2-akkun11.open@gmail.com>
On 7/16/26 19:17, Akari Tsuyukusa wrote:
> Add compatible string for MediaTek MT6589 PWRAP.
> Also update the description since MT6589 has pwrap bridge.
>
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
> ---
> .../devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> index e7c4a3984c60..a487ed39e6cb 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> @@ -19,8 +19,8 @@ description:
>
> IP Pairing
>
> - On MT8135 the pins of some SoC internal peripherals can be on the PMIC.
> - The signals of these pins are routed over the SPI bus using the pwrap
> + On MT6589 and MT8135, the pins of some SoC internal peripherals can be on the
Soon, this will become
"On MT6589, MT8135, MT1234, MT3456, MT...." :-)
So, perhaps, it's a better idea if we say:
"In some SoCs, some of the internal peripherals may be accessible only
through the PMIC.
The signals of these pins are routed (blahblah)"
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v4 1/8] phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
From: Dmitry Baryshkov @ 2026-07-20 13:24 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov, kernel, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, Thomas Niederprüm,
Simon Wright
In-Reply-To: <20260612-hdptx-clk-fixes-v4-1-ce5e1d456cda@collabora.com>
On Fri, Jun 12, 2026 at 02:45:20AM +0300, Cristian Ciocaltea wrote:
> The PHY PLL can be programmed by an external component, e.g. the
> bootloader, just before the recalc_rate() callback is invoked during
> devm_clk_hw_register() in the probe path.
>
> Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and
> attempts to compute the clock rate, while making use of the bpc value
> from the HDMI PHY configuration, which always defaults to 8 because
> phy_configure() was not run at that point. As a consequence, the
> (re)calculated rate is incorrect when the actual bpc was higher than 8.
>
> Do not rely on any of the hdmi_cfg members when computing the clock rate
> and, instead, read the required input data (i.e. bpc), directly from the
> hardware registers.
>
> Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
> Tested-by: Thomas Niederprüm <dubito@online.de>
> Tested-by: Simon Wright <simon@symple.nz>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 0/5] KVM: arm64: Make ICH_VTR_EL2 accesses an inlined literal
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
I did it again.
I was looking at NV traces, and realised that we were trapping a whole
lot of accesses to ICH_VTR_EL2. But ICH_VTR_EL2 really is a constant
from a hypervisor perspective, and we usually cache this in memory, just
like any other ID register.
We do have a variable for this in kvm_vgic_global_state, but we don't
map this one at EL2 since 8aaf3f7dce746 ("KVM: arm64: Don't map
'kvm_vgic_global_state' at EL2 with pKVM").
So what can we do? We can revert back to mapping the global state, but
that's not a very good idea. Or we can be creative and turn the
ICH_VTR_EL2 accesses into a runtime constant patched into the
code. Since we already have a bunch of similar things for the GICv3
traps, that's no big deal.
And for consistency, let's kill kvm_vgic_global_state.ich_vtr_el2
altogether, so that there is only a single efficient way to read
ICH_VTR_EL2.
As usual, this has a significant impact on deeply nested workloads, a
solid 5% reduction in elapsed time for an L3 Linux guest running under
nested KVM instances. I expect this to benefit KVM running under other
hypervisors as well.
Patches on top of -rc3.
Marc Zyngier (5):
KVM: arm64: vgic-v3: Make vtr_to_* helpers use architectural field
symbols
KVM: arm64: Add a helper providing an inlined literal value for
ICH_VTR_EL2
KVM: arm64: Convert most ICH_VTR_EL2 accesses to inlined literal value
KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling
KVM: arm64: vgic-v3: Kill kvm_vgic_global_state.ich_vtr_el2
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/hyp/vgic-v3-sr.c | 29 ++++++--------
arch/arm64/kvm/nested.c | 3 +-
arch/arm64/kvm/vgic-sys-reg-v3.c | 8 ++--
arch/arm64/kvm/vgic/vgic-v3.c | 69 +++++++++++++++++++++++++++-----
arch/arm64/kvm/vgic/vgic-v5.c | 5 +--
arch/arm64/kvm/vgic/vgic.h | 39 +++++++++++++-----
include/kvm/arm_vgic.h | 2 -
8 files changed, 108 insertions(+), 48 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH 5/5] KVM: arm64: vgic-v3: Kill kvm_vgic_global_state.ich_vtr_el2
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
kvm_vgic_global_state.ich_vtr_el2 is the last bit of caching that
we can get rid of. Not as bad as a sysreg access, but still worse
than a constant.
Move over to the inlined stuff and remove the cached value.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/nested.c | 3 ++-
arch/arm64/kvm/vgic-sys-reg-v3.c | 8 ++++----
arch/arm64/kvm/vgic/vgic-v3.c | 5 ++---
arch/arm64/kvm/vgic/vgic-v5.c | 5 +----
arch/arm64/kvm/vgic/vgic.h | 22 +++++++++++-----------
include/kvm/arm_vgic.h | 2 --
6 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index fb54f6dad995c..54defcd8240df 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -16,6 +16,7 @@
#include <asm/sysreg.h>
#include "sys_regs.h"
+#include "vgic/vgic.h"
struct vncr_tlb {
/* The guest's VNCR_EL2 */
@@ -1904,7 +1905,7 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
/* ICH_HCR_EL2 */
resx.res0 = ICH_HCR_EL2_RES0;
resx.res1 = ICH_HCR_EL2_RES1;
- if (!(kvm_vgic_global_state.ich_vtr_el2 & ICH_VTR_EL2_TDS))
+ if (!(vgic_ich_vtr() & ICH_VTR_EL2_TDS))
resx.res0 |= ICH_HCR_EL2_TDIR;
/* No GICv4 is presented to the guest */
resx.res0 |= ICH_HCR_EL2_DVIM | ICH_HCR_EL2_vSGIEOICount;
diff --git a/arch/arm64/kvm/vgic-sys-reg-v3.c b/arch/arm64/kvm/vgic-sys-reg-v3.c
index bdc2d57370b27..89315336b9d3c 100644
--- a/arch/arm64/kvm/vgic-sys-reg-v3.c
+++ b/arch/arm64/kvm/vgic-sys-reg-v3.c
@@ -35,12 +35,12 @@ static int set_gic_ctlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
vgic_v3_cpu->num_id_bits = host_id_bits;
- host_seis = FIELD_GET(ICH_VTR_EL2_SEIS, kvm_vgic_global_state.ich_vtr_el2);
+ host_seis = FIELD_GET(ICH_VTR_EL2_SEIS, vgic_ich_vtr());
seis = FIELD_GET(ICC_CTLR_EL1_SEIS_MASK, val);
if (host_seis != seis)
return -EINVAL;
- host_a3v = FIELD_GET(ICH_VTR_EL2_A3V, kvm_vgic_global_state.ich_vtr_el2);
+ host_a3v = FIELD_GET(ICH_VTR_EL2_A3V, vgic_ich_vtr());
a3v = FIELD_GET(ICC_CTLR_EL1_A3V_MASK, val);
if (host_a3v != a3v)
return -EINVAL;
@@ -69,9 +69,9 @@ static int get_gic_ctlr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
val |= FIELD_PREP(ICC_CTLR_EL1_ID_BITS_MASK, vgic_v3_cpu->num_id_bits);
val |= FIELD_PREP(ICC_CTLR_EL1_SEIS_MASK,
FIELD_GET(ICH_VTR_EL2_SEIS,
- kvm_vgic_global_state.ich_vtr_el2));
+ vgic_ich_vtr()));
val |= FIELD_PREP(ICC_CTLR_EL1_A3V_MASK,
- FIELD_GET(ICH_VTR_EL2_A3V, kvm_vgic_global_state.ich_vtr_el2));
+ FIELD_GET(ICH_VTR_EL2_A3V, vgic_ich_vtr()));
/*
* The VMCR.CTLR value is in ICC_CTLR_EL1 layout.
* Extract it directly using ICC_CTLR_EL1 reg definitions.
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 68d4a486df0a1..7682cbbe3d8bf 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -490,9 +490,9 @@ void vgic_v3_reset(struct kvm_vcpu *vcpu)
}
vcpu->arch.vgic_cpu.num_id_bits = FIELD_GET(ICH_VTR_EL2_IDbits,
- kvm_vgic_global_state.ich_vtr_el2);
+ vgic_ich_vtr());
vcpu->arch.vgic_cpu.num_pri_bits = FIELD_GET(ICH_VTR_EL2_PRIbits,
- kvm_vgic_global_state.ich_vtr_el2) + 1;
+ vgic_ich_vtr()) + 1;
}
void vcpu_set_ich_hcr(struct kvm_vcpu *vcpu)
@@ -966,7 +966,6 @@ int vgic_v3_probe(const struct gic_kvm_info *info)
*/
kvm_vgic_global_state.nr_lr = (ich_vtr_el2 & 0xf) + 1;
kvm_vgic_global_state.can_emulate_gicv2 = false;
- kvm_vgic_global_state.ich_vtr_el2 = ich_vtr_el2;
/* GICv4 support? */
if (info->has_v4) {
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index 16bc0a670d3e5..4e3e4db24e773 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -40,7 +40,6 @@ static void vgic_v5_get_implemented_ppis(void)
int vgic_v5_probe(const struct gic_kvm_info *info)
{
bool v5_registered = false;
- u64 ich_vtr_el2;
int ret;
kvm_vgic_global_state.type = VGIC_V5;
@@ -83,14 +82,12 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
}
kvm_vgic_global_state.has_gcie_v3_compat = true;
- ich_vtr_el2 = vgic_ich_vtr();
- kvm_vgic_global_state.ich_vtr_el2 = (u32)ich_vtr_el2;
/*
* The ListRegs field is 5 bits, but there is an architectural
* maximum of 16 list registers. Just ignore bit 4...
*/
- kvm_vgic_global_state.nr_lr = (ich_vtr_el2 & 0xf) + 1;
+ kvm_vgic_global_state.nr_lr = (vgic_ich_vtr() & 0xf) + 1;
ret = kvm_register_vgic_device(KVM_DEV_TYPE_ARM_VGIC_V3);
if (ret) {
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index 4f65a210041ff..e709ef8dd97af 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -71,17 +71,6 @@
ICH_VTR_EL2_IDbits)
#define KVM_ICH_VTR_EL2_RES1 ICH_VTR_EL2_nV4
-static inline u64 kvm_get_guest_vtr_el2(void)
-{
- u64 vtr;
-
- vtr = kvm_vgic_global_state.ich_vtr_el2;
- vtr &= ~KVM_ICH_VTR_EL2_RES0;
- vtr |= KVM_ICH_VTR_EL2_RES1;
-
- return vtr;
-}
-
/*
* As per Documentation/virt/kvm/devices/arm-vgic-its.rst,
* below macros are defined for ITS table entry encoding.
@@ -197,6 +186,17 @@ static inline u64 vgic_ich_vtr(void)
return vtr;
}
+static inline u64 kvm_get_guest_vtr_el2(void)
+{
+ u64 vtr;
+
+ vtr = vgic_ich_vtr();
+ vtr &= ~KVM_ICH_VTR_EL2_RES0;
+ vtr |= KVM_ICH_VTR_EL2_RES1;
+
+ return vtr;
+}
+
/*
* This struct provides an intermediate representation of the fields contained
* in the GICH_VMCR and ICH_VMCR registers, such that code exporting the GIC
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index fe49fb56dc3c9..bd1bb03500b30 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -176,8 +176,6 @@ struct vgic_global {
/* GICv3 compat mode on a GICv5 host */
bool has_gcie_v3_compat;
- u32 ich_vtr_el2;
-
/* GICv5 PPI capabilities */
struct {
DECLARE_BITMAP(impl_ppi_mask, VGIC_V5_NR_PRIVATE_IRQS);
--
2.47.3
^ permalink raw reply related
* [PATCH 2/5] KVM: arm64: Add a helper providing an inlined litteral value for ICH_VTR_EL2
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
We already have two ways to deal with ICH_VTR_EL2:
- directly read the system register
- read a cached copy in the vgic global state
Add a third way, in the form of an inlined litteral value that will
eventually replace all of the above. This litteral value is computed
at boot time, and patched in the relevant code locations.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/vgic/vgic-v3.c | 51 ++++++++++++++++++++++++++++++++++
arch/arm64/kvm/vgic/vgic.h | 17 ++++++++++++
3 files changed, 69 insertions(+)
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index d4c7d45ae6bc8..459c33634ebd1 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -92,6 +92,7 @@ KVM_NVHE_ALIAS(spectre_bhb_patch_wa3);
KVM_NVHE_ALIAS(spectre_bhb_patch_clearbhb);
KVM_NVHE_ALIAS(alt_cb_patch_nops);
KVM_NVHE_ALIAS(kvm_compute_ich_hcr_trap_bits);
+KVM_NVHE_ALIAS(kvm_patch_ich_vtr_el2);
/* Global kernel state accessed by nVHE hyp code. */
KVM_NVHE_ALIAS(kvm_vgic_global_state);
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 9e841e7afd4a7..ef62dd498f5cf 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -876,6 +876,57 @@ void noinstr kvm_compute_ich_hcr_trap_bits(struct alt_instr *alt,
*updptr = cpu_to_le32(insn);
}
+void noinstr kvm_patch_ich_vtr_el2(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr,
+ int nr_inst)
+{
+ struct arm_smccc_res res = {};
+ u32 insn, oinsn, rd, vtr;
+
+ /* No KVM? Nothing to do */
+ if (!is_hyp_mode_available())
+ return;
+
+ /* No v3 (or v3 compat)? Nothing to do either */
+ if (!this_cpu_has_cap(ARM64_HAS_GICV5_LEGACY) &&
+ !this_cpu_has_cap(ARM64_HAS_GICV3_CPUIF))
+ return;
+
+ /*
+ * At the point where this is called, we are guaranteed that if
+ * we're running at EL1, then the EL2 stubs are still in place.
+ */
+ if (is_kernel_in_hyp_mode())
+ res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2);
+ else
+ arm_smccc_1_1_hvc(HVC_GET_ICH_VTR_EL2, &res);
+
+ if (WARN_ON(res.a0 == HVC_STUB_ERR))
+ return;
+
+ vtr = res.a1;
+
+ /* Compute target register */
+ oinsn = le32_to_cpu(*origptr);
+ rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
+
+ /* movz rd, #(vtr & 0xffff) */
+ insn = aarch64_insn_gen_movewide(rd,
+ (u16)vtr,
+ 0,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_ZERO);
+ *updptr++ = cpu_to_le32(insn);
+
+ /* movk rd, #((vtr >> 16) & 0xffff), lsl #16 */
+ insn = aarch64_insn_gen_movewide(rd,
+ (u16)(vtr >> 16),
+ 16,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_KEEP);
+ *updptr++ = cpu_to_le32(insn);
+}
+
void vgic_v3_enable_cpuif_traps(void)
{
u64 traps = vgic_ich_hcr_trap_bits();
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index f45f7e3ec4d6e..4f65a210041ff 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -180,6 +180,23 @@ static inline u64 vgic_ich_hcr_trap_bits(void)
return hcr;
}
+void kvm_patch_ich_vtr_el2(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr, int nr_inst);
+
+static inline u64 vgic_ich_vtr(void)
+{
+ u64 vtr;
+
+ /* All non-RES0 bits are in the bottom 32bits */
+ asm volatile(ALTERNATIVE_CB("movz %0, #0\n"
+ "movk %0, #0, lsl #16\n",
+ ARM64_ALWAYS_SYSTEM,
+ kvm_patch_ich_vtr_el2)
+ : "=r" (vtr));
+
+ return vtr;
+}
+
/*
* This struct provides an intermediate representation of the fields contained
* in the GICH_VMCR and ICH_VMCR registers, such that code exporting the GIC
--
2.47.3
^ permalink raw reply related
* [PATCH 2/5] KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
We already have two ways to deal with ICH_VTR_EL2:
- directly read the system register
- read a cached copy in the vgic global state
Add a third way, in the form of an inlined literal value that will
eventually replace all of the above. This literal value is computed
at boot time, and patched in the relevant code locations.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/vgic/vgic-v3.c | 51 ++++++++++++++++++++++++++++++++++
arch/arm64/kvm/vgic/vgic.h | 17 ++++++++++++
3 files changed, 69 insertions(+)
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index d4c7d45ae6bc8..459c33634ebd1 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -92,6 +92,7 @@ KVM_NVHE_ALIAS(spectre_bhb_patch_wa3);
KVM_NVHE_ALIAS(spectre_bhb_patch_clearbhb);
KVM_NVHE_ALIAS(alt_cb_patch_nops);
KVM_NVHE_ALIAS(kvm_compute_ich_hcr_trap_bits);
+KVM_NVHE_ALIAS(kvm_patch_ich_vtr_el2);
/* Global kernel state accessed by nVHE hyp code. */
KVM_NVHE_ALIAS(kvm_vgic_global_state);
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 9e841e7afd4a7..ef62dd498f5cf 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -876,6 +876,57 @@ void noinstr kvm_compute_ich_hcr_trap_bits(struct alt_instr *alt,
*updptr = cpu_to_le32(insn);
}
+void noinstr kvm_patch_ich_vtr_el2(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr,
+ int nr_inst)
+{
+ struct arm_smccc_res res = {};
+ u32 insn, oinsn, rd, vtr;
+
+ /* No KVM? Nothing to do */
+ if (!is_hyp_mode_available())
+ return;
+
+ /* No v3 (or v3 compat)? Nothing to do either */
+ if (!this_cpu_has_cap(ARM64_HAS_GICV5_LEGACY) &&
+ !this_cpu_has_cap(ARM64_HAS_GICV3_CPUIF))
+ return;
+
+ /*
+ * At the point where this is called, we are guaranteed that if
+ * we're running at EL1, then the EL2 stubs are still in place.
+ */
+ if (is_kernel_in_hyp_mode())
+ res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2);
+ else
+ arm_smccc_1_1_hvc(HVC_GET_ICH_VTR_EL2, &res);
+
+ if (WARN_ON(res.a0 == HVC_STUB_ERR))
+ return;
+
+ vtr = res.a1;
+
+ /* Compute target register */
+ oinsn = le32_to_cpu(*origptr);
+ rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
+
+ /* movz rd, #(vtr & 0xffff) */
+ insn = aarch64_insn_gen_movewide(rd,
+ (u16)vtr,
+ 0,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_ZERO);
+ *updptr++ = cpu_to_le32(insn);
+
+ /* movk rd, #((vtr >> 16) & 0xffff), lsl #16 */
+ insn = aarch64_insn_gen_movewide(rd,
+ (u16)(vtr >> 16),
+ 16,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_KEEP);
+ *updptr++ = cpu_to_le32(insn);
+}
+
void vgic_v3_enable_cpuif_traps(void)
{
u64 traps = vgic_ich_hcr_trap_bits();
diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
index f45f7e3ec4d6e..4f65a210041ff 100644
--- a/arch/arm64/kvm/vgic/vgic.h
+++ b/arch/arm64/kvm/vgic/vgic.h
@@ -180,6 +180,23 @@ static inline u64 vgic_ich_hcr_trap_bits(void)
return hcr;
}
+void kvm_patch_ich_vtr_el2(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr, int nr_inst);
+
+static inline u64 vgic_ich_vtr(void)
+{
+ u64 vtr;
+
+ /* All non-RES0 bits are in the bottom 32bits */
+ asm volatile(ALTERNATIVE_CB("movz %0, #0\n"
+ "movk %0, #0, lsl #16\n",
+ ARM64_ALWAYS_SYSTEM,
+ kvm_patch_ich_vtr_el2)
+ : "=r" (vtr));
+
+ return vtr;
+}
+
/*
* This struct provides an intermediate representation of the fields contained
* in the GICH_VMCR and ICH_VMCR registers, such that code exporting the GIC
--
2.47.3
^ permalink raw reply related
* [PATCH 1/5] KVM: arm64: vgic-v3: Make vtr_to_* helpers use architectural field symbols
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
vgic-v3-sr.c still contains some hardcoded constants for some of
the ICH)VTR_EL2 fields. Bring them into the modern world by using
the named symbols from the sysreg file.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vgic-v3-sr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index c4d2f1feea8b6..8da7a40ced58a 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -16,9 +16,9 @@
#include "../../vgic/vgic.h"
-#define vtr_to_max_lr_idx(v) ((v) & 0xf)
-#define vtr_to_nr_pre_bits(v) ((((u32)(v) >> 26) & 7) + 1)
-#define vtr_to_nr_apr_regs(v) (1 << (vtr_to_nr_pre_bits(v) - 5))
+#define vtr_to_max_lr_idx(v) FIELD_GET(ICH_VTR_EL2_ListRegs, (v))
+#define vtr_to_nr_pre_bits(v) (FIELD_GET(ICH_VTR_EL2_PREbits, (v)) + 1)
+#define vtr_to_nr_apr_regs(v) BIT(vtr_to_nr_pre_bits(v) - 5)
u64 __gic_v3_get_lr(unsigned int lr)
{
--
2.47.3
^ permalink raw reply related
* [PATCH 3/5] KVM: arm64: Convert most ICH_VTR_EL2 accesses to inlined literal value
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
Now that we have a new helper that inlines the value of ICH_VTR_EL2
into the code, use this to replace most of the sysreg accesses to
that register.
This avoids a lot of traps when running KVM under NV.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vgic-v3-sr.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 8da7a40ced58a..3e5d5ddf35a19 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -367,7 +367,7 @@ void __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if)
u64 val;
u32 nr_pre_bits;
- val = read_gicreg(ICH_VTR_EL2);
+ val = vgic_ich_vtr();
nr_pre_bits = vtr_to_nr_pre_bits(val);
switch (nr_pre_bits) {
@@ -400,7 +400,7 @@ static void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if)
u64 val;
u32 nr_pre_bits;
- val = read_gicreg(ICH_VTR_EL2);
+ val = vgic_ich_vtr();
nr_pre_bits = vtr_to_nr_pre_bits(val);
switch (nr_pre_bits) {
@@ -430,7 +430,7 @@ static void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if)
void __vgic_v3_init_lrs(void)
{
- int max_lr_idx = vtr_to_max_lr_idx(read_gicreg(ICH_VTR_EL2));
+ int max_lr_idx = vtr_to_max_lr_idx(vgic_ich_vtr());
int i;
for (i = 0; i <= max_lr_idx; i++)
@@ -455,7 +455,7 @@ u64 __vgic_v3_get_gic_config(void)
* system, so we first check if we have GICv5 support.
*/
if (cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF))
- return read_gicreg(ICH_VTR_EL2);
+ return vgic_ich_vtr();
sre = read_gicreg(ICC_SRE_EL1);
/*
@@ -498,7 +498,7 @@ u64 __vgic_v3_get_gic_config(void)
}
val = (val & ICC_SRE_EL1_SRE) ? 0 : (1ULL << 63);
- val |= read_gicreg(ICH_VTR_EL2);
+ val |= vgic_ich_vtr();
return val;
}
@@ -540,7 +540,7 @@ void __vgic_v3_restore_vmcr_aprs(struct vgic_v3_cpu_if *cpu_if)
static int __vgic_v3_bpr_min(void)
{
/* See Pseudocode for VPriorityGroup */
- return 8 - vtr_to_nr_pre_bits(read_gicreg(ICH_VTR_EL2));
+ return 8 - vtr_to_nr_pre_bits(vgic_ich_vtr());
}
static int __vgic_v3_get_group(struct kvm_vcpu *vcpu)
@@ -614,7 +614,7 @@ static int __vgic_v3_find_active_lr(struct kvm_vcpu *vcpu, int intid,
static int __vgic_v3_get_highest_active_priority(void)
{
- u8 nr_apr_regs = vtr_to_nr_apr_regs(read_gicreg(ICH_VTR_EL2));
+ u8 nr_apr_regs = vtr_to_nr_apr_regs(vgic_ich_vtr());
u32 hap = 0;
int i;
@@ -707,7 +707,7 @@ static void __vgic_v3_set_active_priority(u8 pri, u32 vmcr, int grp)
static int __vgic_v3_clear_highest_active_priority(void)
{
- u8 nr_apr_regs = vtr_to_nr_apr_regs(read_gicreg(ICH_VTR_EL2));
+ u8 nr_apr_regs = vtr_to_nr_apr_regs(vgic_ich_vtr());
u32 hap = 0;
int i;
@@ -1039,7 +1039,7 @@ static void __vgic_v3_read_ctlr(struct kvm_vcpu *vcpu, u32 vmcr, int rt)
{
u32 vtr, val;
- vtr = read_gicreg(ICH_VTR_EL2);
+ vtr = vgic_ich_vtr();
/* PRIbits */
val = ((vtr >> 29) & 7) << ICC_CTLR_EL1_PRI_BITS_SHIFT;
/* IDbits */
--
2.47.3
^ permalink raw reply related
* [PATCH 4/5] KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling
From: Marc Zyngier @ 2026-07-20 13:22 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260720132220.2143486-1-maz@kernel.org>
Now that we have our magic inline helper for ICH_VTR_EL2, we can
get rid of the hack that was reporting a combination of that
register and of the indication of the CPU interface supporting
GICv2 compatibility. We now only report the latter.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vgic-v3-sr.c | 9 ++-------
arch/arm64/kvm/vgic/vgic-v3.c | 13 +++++++------
arch/arm64/kvm/vgic/vgic-v5.c | 2 +-
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 3e5d5ddf35a19..8a15d6854d1bd 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -439,8 +439,6 @@ void __vgic_v3_init_lrs(void)
/*
* Return the GIC CPU configuration:
- * - [31:0] ICH_VTR_EL2
- * - [62:32] RES0
* - [63] MMIO (GICv2) capable
*/
u64 __vgic_v3_get_gic_config(void)
@@ -455,7 +453,7 @@ u64 __vgic_v3_get_gic_config(void)
* system, so we first check if we have GICv5 support.
*/
if (cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF))
- return vgic_ich_vtr();
+ return 0;
sre = read_gicreg(ICC_SRE_EL1);
/*
@@ -497,10 +495,7 @@ u64 __vgic_v3_get_gic_config(void)
isb();
}
- val = (val & ICC_SRE_EL1_SRE) ? 0 : (1ULL << 63);
- val |= vgic_ich_vtr();
-
- return val;
+ return (val & ICC_SRE_EL1_SRE) ? 0 : (1ULL << 63);
}
static void __vgic_v3_compat_mode_enable(void)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index ef62dd498f5cf..68d4a486df0a1 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -906,6 +906,9 @@ void noinstr kvm_patch_ich_vtr_el2(struct alt_instr *alt,
vtr = res.a1;
+ if (vgic_v3_broken_seis())
+ vtr &= ~ICH_VTR_EL2_SEIS;
+
/* Compute target register */
oinsn = le32_to_cpu(*origptr);
rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
@@ -950,12 +953,12 @@ void vgic_v3_enable_cpuif_traps(void)
*/
int vgic_v3_probe(const struct gic_kvm_info *info)
{
- u64 ich_vtr_el2 = kvm_call_hyp_ret(__vgic_v3_get_gic_config);
+ u64 ich_vtr_el2;
bool has_v2;
int ret;
- has_v2 = ich_vtr_el2 >> 63;
- ich_vtr_el2 = (u32)ich_vtr_el2;
+ has_v2 = kvm_call_hyp_ret(__vgic_v3_get_gic_config) >> 63;
+ ich_vtr_el2 = vgic_ich_vtr();
/*
* The ListRegs field is 5 bits, but there is an architectural
@@ -1010,10 +1013,8 @@ int vgic_v3_probe(const struct gic_kvm_info *info)
if (has_v2)
static_branch_enable(&vgic_v3_has_v2_compat);
- if (vgic_v3_broken_seis()) {
+ if (vgic_v3_broken_seis())
kvm_info("GICv3 with broken locally generated SEI\n");
- kvm_vgic_global_state.ich_vtr_el2 &= ~ICH_VTR_EL2_SEIS;
- }
vgic_v3_enable_cpuif_traps();
diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
index d4789ff3e7402..16bc0a670d3e5 100644
--- a/arch/arm64/kvm/vgic/vgic-v5.c
+++ b/arch/arm64/kvm/vgic/vgic-v5.c
@@ -83,7 +83,7 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
}
kvm_vgic_global_state.has_gcie_v3_compat = true;
- ich_vtr_el2 = kvm_call_hyp_ret(__vgic_v3_get_gic_config);
+ ich_vtr_el2 = vgic_ich_vtr();
kvm_vgic_global_state.ich_vtr_el2 = (u32)ich_vtr_el2;
/*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] ASoC: meson: Keep link pointers valid on realloc failure
From: Mark Brown @ 2026-07-19 20:11 UTC (permalink / raw)
To: Jerome Brunet, Linmao Li
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Neil Armstrong,
Kevin Hilman, Martin Blumenstingl, linux-sound, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20260717012433.1432285-1-lilinmao@kylinos.cn>
On Fri, 17 Jul 2026 09:24:33 +0800, Linmao Li wrote:
> ASoC: meson: Keep link pointers valid on realloc failure
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[1/1] ASoC: meson: Keep link pointers valid on realloc failure
https://git.kernel.org/broonie/sound/c/2aaa41cf974f
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 0/2] spi: axiado: cond_no_effect and kernel-doc fixes
From: Mark Brown @ 2026-07-19 22:56 UTC (permalink / raw)
To: Babanpreet Singh
Cc: Vladimir Moravcevic, Tzu-Hao Wei, Swark Yang, Prasad Bolisetty,
Karthikeyan Mitran, kernel test robot, Julia Lawall, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260713060807.7-1-bbnpreetsingh@gmail.com>
On Mon, 13 Jul 2026 06:08:05 +0000, Babanpreet Singh wrote:
> spi: axiado: cond_no_effect and kernel-doc fixes
>
> Two small cleanups for the Axiado SPI driver, both defects present
> since the driver was added in e75a6b00ad79 ("spi: axiado: Add driver
> for Axiado SPI DB controller").
>
> Patch 1 addresses the coccinelle cond_no_effect warning reported by
> the kernel test robot on 2026-07-12 [1]: the RX-only/full-duplex
> else-if arm and the trailing else arm in ax_transfer_one() have
> identical bodies, so the second condition has no effect. The arms are
> merged; no functional change (on x86_64/gcc 14, only
> ax_transfer_one()'s object code changes, dropping the dead condition
> evaluation).
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/2] spi: axiado: merge identical if/else branches in ax_transfer_one()
https://git.kernel.org/broonie/spi/c/fc46551cfa3b
[2/2] spi: axiado: fix kernel-doc comments
https://git.kernel.org/broonie/spi/c/7720f98d08fd
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: (subset) [PATCH v2 0/5] spi: atmel-quadspi: add support for LAN969x
From: Mark Brown @ 2026-07-19 21:15 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, nicolas.ferre, alexandre.belloni,
claudiu.beznea, tudor.ambarus, linux-spi, devicetree,
linux-arm-kernel, linux-kernel, daniel.machon, Robert Marko
Cc: luka.perkov
In-Reply-To: <20260709112006.390742-1-robert.marko@sartura.hr>
On Thu, 09 Jul 2026 13:19:06 +0200, Robert Marko wrote:
> spi: atmel-quadspi: add support for LAN969x
>
> This series adds QSPI support for the Microchip LAN969x which has two QSPI
> controllers based on SAMA7G5.
>
> It requires pad calibration, supports DMA, and supports 100 MHz operation.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/5] dt-bindings: spi: Document LAN969x QSPI
https://git.kernel.org/broonie/spi/c/f718ea6cb3f3
[2/5] spi: atmel-quadspi: add controller init callback
https://git.kernel.org/broonie/spi/c/cbbd5a945e85
[3/5] spi: atmel-quadspi: use init callback for gclk variants
https://git.kernel.org/broonie/spi/c/b881f1d8d1df
[4/5] spi: atmel-quadspi: add LAN969x QSPI support
https://git.kernel.org/broonie/spi/c/a3e4130b6ef9
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: Drop unused assignment of platform_device_id driver data
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-20 13:17 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <1420ce71c3be5056a384be9c733f5df3277bf61a.1781690829.git.u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
hello Catalin, hello Will,
On Wed, Jun 17, 2026 at 12:28:26PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The driver explicitly sets the .driver_data member of struct
> platform_device_id to zero without relying on that value. Drop this
> unused assignment.
>
> While touching this array use a named initializer for .name.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Do you have this patch still on your radar? Should I resend? To someone
else, too?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI: aspeed: Switch to irq_domain_create_linear()
From: Manivannan Sadhasivam @ 2026-07-20 13:17 UTC (permalink / raw)
To: bhelgaas, Jiri Slaby (SUSE)
Cc: linux-kernel, Thomas Gleixner, Jacky Chou, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Joel Stanley,
Andrew Jeffery, linux-aspeed, linux-pci, linux-arm-kernel
In-Reply-To: <20260708095814.385480-1-jirislaby@kernel.org>
On Wed, 08 Jul 2026 11:58:14 +0200, Jiri Slaby (SUSE) wrote:
> irq_domain_add_linear() is going away as being obsolete now. Switch to
> the preferred irq_domain_create_linear(). That differs in the first
> parameter: It takes more generic struct fwnode_handle instead of struct
> device_node. Therefore, of_fwnode_handle() is added around the
> parameter.
>
> Note some of the users can likely use dev->fwnode directly instead of
> indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
> guaranteed to be set for all, so this has to be investigated on case to
> case basis (by people who can actually test with the HW).
>
> [...]
Applied, thanks!
[1/1] PCI: aspeed: Switch to irq_domain_create_linear()
commit: f944349dcbaeaa9d6e1c8f2f8182f5560ba79581
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: reset: Add MT6589 toprgu reset IDs
From: AngeloGioacchino Del Regno @ 2026-07-20 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Leonardo Scorcia
Cc: linux-mediatek, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Philipp Zabel, linux-watchdog, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260720-gabby-strategic-goose-b61c4e@quoll>
On 7/20/26 08:25, Krzysztof Kozlowski wrote:
> On Fri, Jul 17, 2026 at 06:39:12PM +0200, Luca Leonardo Scorcia wrote:
>> Add reset constants for the 12 MT6589 toprgu resets.
>
>
> This is not a single-patch patchset. Seven patches.
>
> So one posting per 24h, so we actually have a possibility to review it.
>
krzk, that's because Sashiko provides reviews instantly, and people just go and
fix things to make it easier on us maintainers to provide reviews (and avoiding
to see the same Sashiko complaints from us).
That said, this gets into personal preference territory, and I'm not trying to
start any conversation about that specifically...
>>
>> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
>> ---
>> .../reset/mediatek,mt6589-resets.h | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 include/dt-bindings/reset/mediatek,mt6589-resets.h
>>
>> diff --git a/include/dt-bindings/reset/mediatek,mt6589-resets.h b/include/dt-bindings/reset/mediatek,mt6589-resets.h
>> new file mode 100644
>> index 000000000000..ee08c39df513
>> --- /dev/null
>> +++ b/include/dt-bindings/reset/mediatek,mt6589-resets.h
>
>
> Why is this header being added outside of patch documenting compatible?
> You have entire commit msg to say something useful instead of repeating
> the subject.
Because he wrote it all in the cover letter... which is something that gets
read right now, but gets lost once the commits are picked - so all context and
explaining are completely lost.
Luca, that's why krzk is complaining :-)
Just write the information in each commit's description, so that it doesn't get
lost, and so that the next one trying to understand what went on with the toprgu
can just read it there. :-)
Cheers,
Angelo
^ permalink raw reply
* [PATCH v2] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
From: Alexandru Elisei @ 2026-07-20 13:09 UTC (permalink / raw)
To: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
linux-arm-kernel, kvmarm, catalin.marinas, will
Cc: steven.price, fuad.tabba
The user cannot use MTE on VMAs created by mapping a guest_memfd file,
as arch_calc_vm_flag_bits() does not set VM_MTE_ALLOWED.
When creating a guest_memfd backed memslot,
kvm_arch_prepare_memory_region() rejects the memslot if MTE is enabled for
the VM and if guest_memfd has been mapped in a VMA that intersects the
memslot.
However, the documentation for KVM_SET_USER_MEMORY_REGION2 explicitly
states that the only condition for userspace_addr is for it to be a legal
userspace address, but the mapping is not required to be valid nor
populated at memslot creation.
If userspace sets userspace_addr to an address that hasn't been mapped, or
if userspace_addr belongs to a VMA that isn't backed by the guest_memfd
file, or if the VMA doesn't intersect the memslot, memslot creation is
successful and KVM ends up with a VM with MTE and guest_memfd-backed
memslots.
The same happens if the order is reversed: when userspace enables MTE, KVM
does not check if memslots backed by guest_memfd are already present.
Fix both issues by rejecting guest_memfd-backed memslots when MTE is
enabled, and by reject MTE when guest_memfd-backed memslots are already
present.
Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
v1 can be found at [1].
Changes in v2:
* Added the Fixes tag (Fuad)
* Split the condition in kvm_arch_prepare_memory_region() (Fuad)
* Added the check in kvm_vm_ioctl_enable_cap() (Fuad)
Tested by using Fuad's patches to add guest_memfd support for kvmtool at [2],
with the following changes:
diff --git a/arm64/kvm.c b/arm64/kvm.c
index 36b3284e4a92..de83b5d7e517 100644
--- a/arm64/kvm.c
+++ b/arm64/kvm.c
@@ -125,10 +125,12 @@ static void kvm__arch_enable_mte(struct kvm *kvm)
return;
}
+ /*
if (kvm->cfg.arch.guest_memfd) {
pr_debug("MTE is incompatible with guest_memfd");
return;
}
+ */
if (kvm->cfg.arch.mte_disabled) {
pr_debug("MTE disabled by user");
diff --git a/kvm.c b/kvm.c
index 96583f916442..cc8628b558ea 100644
--- a/kvm.c
+++ b/kvm.c
@@ -332,8 +332,15 @@ int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size,
.guest_memfd_offset = guest_memfd_offset,
};
+ if (munmap(userspace_addr, size) < 0)
+ die_perror("munmap hack");
+
ret = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION2,
&mem2);
+
+ if (mmap(userspace_addr, size, PROT_RW, MAP_SHARED | MAP_FIXED,
+ guest_memfd, guest_memfd_offset) == MAP_FAILED)
+ die_perror("mmap hack");
} else {
struct kvm_userspace_memory_region mem = {
.slot = slot,
(indentation is weird on purpose so git doesn't get confused). That's to
test that the user can create a guest_memfd memslot after MTE has been
enabled for the VM. Without this patch, I was able to create a VM with MTE
and guest_memfd backed ram (the guest reported MTE as enabled, but I didn't
test that it actually worked). With this patch, creating a VM with MTE is
rejected.
To test that KVM rejects enabling MTE *after* creating a guest_memfd backed
memslot, I modified kvmtool to enable MTE *after* creating the memslot.
Same situation: without this patch, KVM allows that, with this patch, KVM
rejects enabling MTE.
[1] https://lore.kernel.org/kvmarm/20260714110756.116950-1-alexandru.elisei@arm.com/
[2] https://lore.kernel.org/kvmarm/20260712142536.1391557-1-fuad.tabba@linux.dev/
arch/arm64/kvm/arm.c | 25 +++++++++++++++++++------
arch/arm64/kvm/mmu.c | 4 ++++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 50adfff75be8..9a6c72a18672 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -149,14 +149,27 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
set_bit(KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER,
&kvm->arch.flags);
break;
- case KVM_CAP_ARM_MTE:
- mutex_lock(&kvm->lock);
- if (system_supports_mte() && !kvm->created_vcpus) {
- r = 0;
- set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
+ case KVM_CAP_ARM_MTE: {
+ struct kvm_memory_slot *memslot;
+ int bkt;
+
+ guard(mutex)(&kvm->lock);
+ if (!system_supports_mte() || kvm->created_vcpus)
+ break;
+
+ r = 0;
+ guard(mutex)(&kvm->slots_lock);
+ kvm_for_each_memslot(memslot, bkt, kvm_memslots(kvm)) {
+ if (kvm_slot_has_gmem(memslot)) {
+ r = -EINVAL;
+ break;
+ }
}
- mutex_unlock(&kvm->lock);
+ if (r == 0)
+ set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
break;
+
+ }
case KVM_CAP_ARM_SYSTEM_SUSPEND:
r = 0;
set_bit(KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED, &kvm->arch.flags);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 6c941aaa10c6..2d95203386ba 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2652,6 +2652,10 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
if (kvm_slot_has_gmem(new) && !kvm_memslot_is_gmem_only(new))
return -EINVAL;
+ /* guest_memfd is incompatible with MTE. */
+ if (kvm_slot_has_gmem(new) && kvm_has_mte(kvm))
+ return -EINVAL;
+
hva = new->userspace_addr;
reg_end = hva + (new->npages << PAGE_SHIFT);
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems
From: Manivannan Sadhasivam @ 2026-07-20 13:04 UTC (permalink / raw)
To: Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Steffen Persvold
Cc: Rob Herring, linux-pci, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260709122446.3151899-1-spersvold@gmail.com>
On Thu, 09 Jul 2026 14:24:46 +0200, Steffen Persvold wrote:
> On 32-bit systems the config space is too large to ioremap in one go, so
> pci_ecam_create() maps each bus segment separately and relies on the
> ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in
> cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for
> every config access.
>
> The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus
> and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c
> do not. As a result, on a 32-bit host using "pci-host-cam-generic" the
> per-bus mapping is never set up and the first config read dereferences a
> NULL base, crashing during bus enumeration:
>
> [...]
Applied, thanks!
[1/1] PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems
commit: 008cb88edb41f3c7c8e0ed763ff9f26719830984
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()
From: Robin Murphy @ 2026-07-20 12:58 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andi Shyti,
Joerg Roedel (AMD), Will Deacon, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
Cc: brgl, driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu,
netdev, linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm,
linux-sound
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-3-2dee93f42c54@oss.qualcomm.com>
On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
This is very much non-portable code specific to OF-only platforms, but
if the intention is to remove platform_device_set_of_node() again
already, then FWIW,
Acked-by: Robin Murphy <robin.murphy@arm.com>
(Although I'm slightly puzzled by the cover letter - AFAICS in -next,
platform_device_set_of_node() is itself very much a user of
platform_device_set_fwnode(), however in terms of symbol exports,
perhaps the former could now just be a static inline wrapper?)
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/iommu/fsl_pamu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
> goto error_device_alloc;
> }
>
> - platform_device_set_of_node(pdev, np);
> + platform_device_set_fwnode(pdev, of_fwnode_handle(np));
>
> ret = pamu_domain_init();
> if (ret)
>
^ permalink raw reply
* Re: [PATCH v4 3/6] KVM: arm64: Add auto DBM support for hardware dirty tracking
From: Leonardo Bras @ 2026-07-20 12:58 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, Oliver Upton, maz, catalin.marinas, will,
yuzenghui, wangzhou1, yangjinqian1, caijian11, liuyonglong,
yezhenyu2, yubihong, linuxarm, joey.gouly, kvmarm, kvm,
linux-arm-kernel, linux-kernel, seiden, suzuki.poulose
In-Reply-To: <alpIfIOFfrudBzD5@LeoBrasDK>
On Fri, Jul 17, 2026 at 04:21:32PM +0100, Leonardo Bras wrote:
> On Fri, Jul 17, 2026 at 11:58:06AM +0800, Tian Zheng wrote:
> >
> > On 7/16/2026 3:39 PM, Oliver Upton wrote:
> > > Hi Tian,
> > >
> > > On Thu, Jul 09, 2026 at 06:40:23PM +0800, Tian Zheng wrote:
> > > > - if (prot & KVM_PGTABLE_PROT_W)
> > > > + if (prot & KVM_PGTABLE_PROT_W) {
> > > > set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
> > > >
> > > > + /*
> > > > + * No DEVICE filter needed here: relax_perms is only called
> > > > + * on FSC_PERM faults. Device pages always get full RW from
> > > > + * initial mapping and are never write-protected during
> > > > + * migration, so they never trigger a permission fault.
> > > > + */
> > > > + if (pgt->flags & KVM_PGTABLE_S2_DBM)
> > > > + set |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> > > > + } else {
> > > > + /*
> > > > + * Clear DBM on W→RO downgrade to prevent hardware from
> > > > + * silently upgrading RO+DBM back to W+dirty, which would
> > > > + * bypass KVM's write tracking and cause data corruption.
> > > > + */
> > > > + clr |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> > > > + }
> > > > +
> > > This block makes it pretty evident that the DBM bit really *is* the
> > > write permission bit. I'd much rather we introduce the concept of dirty
> > > state to the page table library and migrate the abstract write
> > > permission to the DBM field, even if we don't have FEAT_HAFDBS.
> > >
>
> Ohh, that's an amazing idea!
Thinking about that again...
If we adopt the encoding with DBM being the write-permission bit, and all
PTEs have it since the start, how can we have lazy-splitting happening?
Only way I think of is removing both DBM and S2_S2AP_W bit from writable
PTEs during dirty-track enable, and re-adding them during the first write
fault. If we don't remove the DBM bit, systems with HDBSS would just dirty
it by hardware, without causing a fault.
DBM=0 would need to happen only in the first write-protect (only on
lazy-splitting). All other write-protecting would just clean the S2_S2AP_W
bit, as everything is already split.
Is that what was intended?
Thanks!
Leo
^ permalink raw reply
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