* [PATCH] crypto: sun8i-ss - avoid hash and rng references
From: Arnd Bergmann @ 2026-04-23 6:55 UTC (permalink / raw)
To: Corentin Labbe, Herbert Xu, David S. Miller, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Eric Biggers
Cc: Arnd Bergmann, Ovidiu Panait, linux-crypto, linux-arm-kernel,
linux-sunxi, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
While the sun4i-ss and sun8i-ce drivers started selecting CRYPTO_RNG,
the sun8i-ss variant does not, and causes a link failure:
aarch64-linux-ld: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.o: in function `sun8i_ss_unregister_algs':
sun8i-ss-core.c:(.text.sun8i_ss_unregister_algs+0x94): undefined reference to `crypto_unregister_rng'
aarch64-linux-ld: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.o: in function `sun8i_ss_probe':
sun8i-ss-core.c:(.text.sun8i_ss_probe+0x40c): undefined reference to `crypto_register_rng'
Looking more closely, I see that all of the allwinner crypto drivers have the
same logic where the rng and hash parts of the driver are optional, but then the
generic code is still selected, which is a bit inconsistent, aside from the
missing CRYPTO_RNG select on sun8i-ss.
Change the approach so only the bits that are actually used are built, using
ifdef checks around the optional portions that match the optional references
to the sub-drivers.
Ideally the drivers would get reworked in a way that keeps all the bits
related to the skcipher/ahash/rng codecs in the respective sub-drivers,
rather than having a common driver that knows about all of these.
Fixes: cdadc1435937 ("crypto: cryptomgr - Select algorithm types only when CRYPTO_SELFTESTS")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The simpler approach would be to add even more 'select' statements
---
drivers/crypto/allwinner/Kconfig | 2 --
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 8 ++++++++
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 12 ++++++++++++
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 12 ++++++++++++
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index 7270e5fbc573..b8e75210a0e3 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -14,7 +14,6 @@ config CRYPTO_DEV_SUN4I_SS
select CRYPTO_SHA1
select CRYPTO_AES
select CRYPTO_LIB_DES
- select CRYPTO_RNG
select CRYPTO_SKCIPHER
help
Some Allwinner SoC have a crypto accelerator named
@@ -50,7 +49,6 @@ config CRYPTO_DEV_SUN8I_CE
select CRYPTO_CBC
select CRYPTO_AES
select CRYPTO_DES
- select CRYPTO_RNG
depends on CRYPTO_DEV_ALLWINNER
depends on PM
help
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
index 58a76e2ba64e..813c4bc6312a 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
@@ -247,12 +247,14 @@ static int sun4i_ss_debugfs_show(struct seq_file *seq, void *v)
ss_algs[i].stat_req, ss_algs[i].stat_opti, ss_algs[i].stat_fb,
ss_algs[i].stat_bytes);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
seq_printf(seq, "%s %s reqs=%lu tsize=%lu\n",
ss_algs[i].alg.rng.base.cra_driver_name,
ss_algs[i].alg.rng.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_bytes);
break;
+#endif
case CRYPTO_ALG_TYPE_AHASH:
seq_printf(seq, "%s %s reqs=%lu\n",
ss_algs[i].alg.hash.halg.base.cra_driver_name,
@@ -471,6 +473,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
goto error_alg;
}
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
err = crypto_register_rng(&ss_algs[i].alg.rng);
if (err) {
@@ -478,6 +481,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
ss_algs[i].alg.rng.base.cra_name);
}
break;
+#endif
}
}
@@ -497,9 +501,11 @@ static int sun4i_ss_probe(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(&ss_algs[i].alg.hash);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
crypto_unregister_rng(&ss_algs[i].alg.rng);
break;
+#endif
}
}
error_pm:
@@ -520,9 +526,11 @@ static void sun4i_ss_remove(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(&ss_algs[i].alg.hash);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
crypto_unregister_rng(&ss_algs[i].alg.rng);
break;
+#endif
}
}
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index c16bb6ce6ee3..f3b58ed6aed0 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -676,6 +676,7 @@ static int sun8i_ce_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tFallback due to SG numbers: %lu\n",
ce_algs[i].stat_fb_maxsg);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_HASH
case CRYPTO_ALG_TYPE_AHASH:
seq_printf(seq, "%s %s reqs=%lu fallback=%lu\n",
ce_algs[i].alg.hash.base.halg.base.cra_driver_name,
@@ -692,12 +693,15 @@ static int sun8i_ce_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tFallback due to SG numbers: %lu\n",
ce_algs[i].stat_fb_maxsg);
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG
case CRYPTO_ALG_TYPE_RNG:
seq_printf(seq, "%s %s reqs=%lu bytes=%lu\n",
ce_algs[i].alg.rng.base.cra_driver_name,
ce_algs[i].alg.rng.base.cra_name,
ce_algs[i].stat_req, ce_algs[i].stat_bytes);
break;
+#endif
}
}
#if defined(CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG) && \
@@ -905,6 +909,7 @@ static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
return err;
}
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_HASH
case CRYPTO_ALG_TYPE_AHASH:
id = ce_algs[i].ce_algo_id;
ce_method = ce->variant->alg_hash[id];
@@ -925,6 +930,8 @@ static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
return err;
}
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG
case CRYPTO_ALG_TYPE_RNG:
if (ce->variant->prng == CE_ID_NOTSUPP) {
dev_info(ce->dev,
@@ -942,6 +949,7 @@ static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
ce_algs[i].ce = NULL;
}
break;
+#endif
default:
ce_algs[i].ce = NULL;
dev_err(ce->dev, "ERROR: tried to register an unknown algo\n");
@@ -963,16 +971,20 @@ static void sun8i_ce_unregister_algs(struct sun8i_ce_dev *ce)
ce_algs[i].alg.skcipher.base.base.cra_name);
crypto_engine_unregister_skcipher(&ce_algs[i].alg.skcipher);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_HASH
case CRYPTO_ALG_TYPE_AHASH:
dev_info(ce->dev, "Unregister %d %s\n", i,
ce_algs[i].alg.hash.base.halg.base.cra_name);
crypto_engine_unregister_ahash(&ce_algs[i].alg.hash);
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG
case CRYPTO_ALG_TYPE_RNG:
dev_info(ce->dev, "Unregister %d %s\n", i,
ce_algs[i].alg.rng.base.cra_name);
crypto_unregister_rng(&ce_algs[i].alg.rng);
break;
+#endif
}
}
}
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index f45685707e0d..59c9bc45ec0f 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -501,12 +501,15 @@ static int sun8i_ss_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tFallback due to SG numbers: %lu\n",
ss_algs[i].stat_fb_sgnum);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
seq_printf(seq, "%s %s reqs=%lu tsize=%lu\n",
ss_algs[i].alg.rng.base.cra_driver_name,
ss_algs[i].alg.rng.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_bytes);
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_HASH
case CRYPTO_ALG_TYPE_AHASH:
seq_printf(seq, "%s %s reqs=%lu fallback=%lu\n",
ss_algs[i].alg.hash.base.halg.base.cra_driver_name,
@@ -523,6 +526,7 @@ static int sun8i_ss_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tFallback due to SG numbers: %lu\n",
ss_algs[i].stat_fb_sgnum);
break;
+#endif
}
}
return 0;
@@ -707,6 +711,7 @@ static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
return err;
}
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
err = crypto_register_rng(&ss_algs[i].alg.rng);
if (err) {
@@ -715,6 +720,8 @@ static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
ss_algs[i].ss = NULL;
}
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_HASH
case CRYPTO_ALG_TYPE_AHASH:
id = ss_algs[i].ss_algo_id;
ss_method = ss->variant->alg_hash[id];
@@ -735,6 +742,7 @@ static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
return err;
}
break;
+#endif
default:
ss_algs[i].ss = NULL;
dev_err(ss->dev, "ERROR: tried to register an unknown algo\n");
@@ -756,16 +764,20 @@ static void sun8i_ss_unregister_algs(struct sun8i_ss_dev *ss)
ss_algs[i].alg.skcipher.base.base.cra_name);
crypto_engine_unregister_skcipher(&ss_algs[i].alg.skcipher);
break;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG
case CRYPTO_ALG_TYPE_RNG:
dev_info(ss->dev, "Unregister %d %s\n", i,
ss_algs[i].alg.rng.base.cra_name);
crypto_unregister_rng(&ss_algs[i].alg.rng);
break;
+#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_HASH
case CRYPTO_ALG_TYPE_AHASH:
dev_info(ss->dev, "Unregister %d %s\n", i,
ss_algs[i].alg.hash.base.halg.base.cra_name);
crypto_engine_unregister_ahash(&ss_algs[i].alg.hash);
break;
+#endif
}
}
}
--
2.39.5
^ permalink raw reply related
* Re: [PATCH net v4 0/2] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: patchwork-bot+netdevbpf @ 2026-04-23 7:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 17 Apr 2026 08:36:30 +0200 you wrote:
> Add missing bits in airoha_qdma_cleanup_tx_queue routine.
> Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
> '3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
> DMA tx descriptors")'.
>
> ---
> Changes in v4:
> - Drop patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Link to v3: https://lore.kernel.org/r/20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org
>
> [...]
Here is the summary with links:
- [net,v4,1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
https://git.kernel.org/netdev/net/c/f329924bb494
- [net,v4,2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
https://git.kernel.org/netdev/net/c/3309965fe44c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v17 1/5] ring-buffer: Flush and stop persistent ring buffer on panic
From: Geert Uytterhoeven @ 2026-04-23 7:28 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Steven Rostedt, Catalin Marinas, Will Deacon, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, Ian Rogers, linux-arm-kernel
In-Reply-To: <177687459412.932171.8121855108122534476.stgit@mhiramat.tok.corp.google.com>
On Wed, 22 Apr 2026 at 18:26, Masami Hiramatsu (Google)
<mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> On real hardware, panic and machine reboot may not flush hardware cache
> to memory. This means the persistent ring buffer, which relies on a
> coherent state of memory, may not have its events written to the buffer
> and they may be lost. Moreover, there may be inconsistency with the
> counters which are used for validation of the integrity of the
> persistent ring buffer which may cause all data to be discarded.
>
> To avoid this issue, stop recording of the ring buffer on panic and
> flush the cache of the ring buffer's memory.
>
> Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance")
> Cc: stable@vger.kernel.org
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> arch/m68k/include/asm/Kbuild | 1 +
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v6 1/6] media: dt-bindings: mediatek,vcodec-encoder: Add MT8196
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Rob Herring (Arm)
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Add support for MT8196 video encoder which uses VCP (Video Co-Processor)
for firmware management. Unlike previous platforms that use SCP/VPU, MT8196
requires VCP to load and execute the video encoding firmware, with the
encoder communicating through VCP to perform encoding operations.
Add the "mediatek,mt8196-vcodec-enc" compatible string and introduce
the "mediatek,vcp" property to reference the VCP device, which is
required for MT8196 encoder operation.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../media/mediatek,vcodec-encoder.yaml | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index ebc615584f92..72698456374a 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -24,6 +24,7 @@ properties:
- mediatek,mt8188-vcodec-enc
- mediatek,mt8192-vcodec-enc
- mediatek,mt8195-vcodec-enc
+ - mediatek,mt8196-vcodec-enc
- items:
- const: mediatek,mt8186-vcodec-enc
- const: mediatek,mt8183-vcodec-enc
@@ -58,6 +59,13 @@ properties:
description:
Describes point to scp.
+ mediatek,vcp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Reference to the VCP (Video Co-Processor) device that loads and executes
+ the video encoding firmware. The encoder communicates with the firmware
+ through VCP to perform encoding operations.
+
power-domains:
maxItems: 1
@@ -76,6 +84,20 @@ required:
- iommus
allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8196-vcodec-enc
+
+ then:
+ required:
+ - mediatek,vcp
+ else:
+ properties:
+ mediatek,vcp: false
+
- if:
properties:
compatible:
--
2.45.2
^ permalink raw reply related
* [PATCH v6 0/6] Add support for MT8196 video encoder
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
This patch series add support for MT8196 video encoder.
patch 1: Add dt-bindings.
patch 2~4: Add a new encoder driver interface for new VCP firmware.
patch 5: Add new encoder driver platform data.
patch 6: Add compatible data.
About adding new driver support, the v4l2-compliance report shows:
"Total for mtk-vcodec-enc device /dev/video3: 47, Succeeded: 46, Failed: 1, Warnings: 0"
The 1 Failed case is not caused by current patch set:
fail: v4l2-test-controls.cpp(1171): node->codec_mask & STATEFUL_ENCODER
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
This patch set depends on "media: mediatek: vcodec: support video decoder in mt8196"[1]
[1] https://patchwork.linuxtv.org/project/linux-media/list/?series=23518
Change in v6:
- Move dt-bindings to patch 1.
- Rebase patch onto decoder's patch set.
- Link to v5: https://patchwork.linuxtv.org/project/linux-media/cover/20260302035244.8994-1-irui.wang@mediatek.com/
Change in v5:
- Rewrite patch5 commit subject.
- Add else statement in patch5.
- Link to v4: https://patchwork.linuxtv.org/project/linux-media/list/?series=21757
Change in v4:
- Rework patch3 commit message.
- Rework patch5 commit with more details.
- Rebase patch onto decoder's patch set.
- Link to v3: https://patchwork.linuxtv.org/project/linux-media/cover/20250814085642.17343-1-kyrie.wu@mediatek.com/
Change in v3:
- Add venc rc buffer alloc failure error handling.
- Add mediatek,vcp property definition in dt-bindning.
Change in v2:
- Add support for VCP encode process.
- Add MT8196 encoder driver platform data.
- Rebase encoder patch onto decoder's patch set.
- Fix some review comments in v1.
Irui Wang (6):
media: dt-bindings: mediatek,vcodec-encoder: Add MT8196
media: mediatek: encoder: Add a new encoder driver interface
media: mediatek: encoder: Add support for common firmware interface
media: mediatek: encoder: Add support for VCP encode process
media: mediatek: encoder: Add a new platform data member
media: mediatek: encoder: Add MT8196 encoder compatible data
.../media/mediatek,vcodec-encoder.yaml | 22 +
.../mediatek/vcodec/common/mtk_vcodec_fw.c | 19 +
.../mediatek/vcodec/common/mtk_vcodec_fw.h | 2 +
.../vcodec/common/mtk_vcodec_fw_priv.h | 1 +
.../vcodec/common/mtk_vcodec_fw_vcp.c | 6 +
.../platform/mediatek/vcodec/encoder/Makefile | 1 +
.../mediatek/vcodec/encoder/mtk_vcodec_enc.c | 36 +-
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 28 +
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 15 +-
.../vcodec/encoder/venc/venc_common_if.c | 685 ++++++++++++++++++
.../vcodec/encoder/venc/venc_h264_if.c | 8 +-
.../mediatek/vcodec/encoder/venc_drv_if.c | 3 +-
.../mediatek/vcodec/encoder/venc_drv_if.h | 11 +-
.../mediatek/vcodec/encoder/venc_ipi_msg.h | 26 +
.../mediatek/vcodec/encoder/venc_vpu_if.c | 47 +-
15 files changed, 858 insertions(+), 52 deletions(-)
create mode 100644 drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
--
2.45.2
^ permalink raw reply
* [PATCH v6 4/6] media: mediatek: encoder: Add support for VCP encode process
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Adapt the encoder driver to support VCP firmware interface.
Set the encoder driver firmware type to 'VCP'.
Allocate RC buffers using the VCP device.
Send the shared memory address to VCP and map the encoder VSI address
to the CPU address space using the VCP shared memory address.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
.../mediatek/vcodec/common/mtk_vcodec_fw.c | 6 +++++
.../mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
.../vcodec/common/mtk_vcodec_fw_priv.h | 1 +
.../vcodec/common/mtk_vcodec_fw_vcp.c | 6 +++++
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 3 +++
.../vcodec/encoder/venc/venc_common_if.c | 23 ++++++++++++++-----
.../mediatek/vcodec/encoder/venc_vpu_if.c | 14 ++++++++++-
7 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
index 0381acceda25..7a504f093bd8 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
@@ -105,3 +105,9 @@ int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw)
return fw->type;
}
EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_type);
+
+struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw)
+{
+ return fw->ops->get_fw_dev(fw);
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_dev);
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
index e7304a7dd3e0..56c26b91651e 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
@@ -43,5 +43,6 @@ int mtk_vcodec_fw_ipi_send(struct mtk_vcodec_fw *fw, int id,
int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw);
int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id);
int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type);
+struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw);
#endif /* _MTK_VCODEC_FW_H_ */
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
index 0a2a9b010244..710c83c871f4 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
@@ -29,6 +29,7 @@ struct mtk_vcodec_fw_ops {
int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
unsigned int len, unsigned int wait);
void (*release)(struct mtk_vcodec_fw *fw);
+ struct device *(*get_fw_dev)(struct mtk_vcodec_fw *fw);
};
#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VCODEC_VPU)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
index 6b69ce44d4bb..2859fe78f67d 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
@@ -500,6 +500,11 @@ static void mtk_vcodec_vcp_release(struct mtk_vcodec_fw *fw)
}
+static struct device *mtk_vcodec_vcp_get_fw_dev(struct mtk_vcodec_fw *fw)
+{
+ return fw->vcp->vcp_device->dev;
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_vcp_msg = {
.load_firmware = mtk_vcodec_vcp_load_firmware,
.get_vdec_capa = mtk_vcodec_vcp_get_vdec_capa,
@@ -508,6 +513,7 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vcp_msg = {
.ipi_register = mtk_vcodec_vcp_set_ipi_register,
.ipi_send = mtk_vcodec_vcp_ipi_send,
.release = mtk_vcodec_vcp_release,
+ .get_fw_dev = mtk_vcodec_vcp_get_fw_dev,
};
struct mtk_vcodec_fw *mtk_vcodec_fw_vcp_init(void *priv, enum mtk_vcodec_fw_use fw_use)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 4e4541b2fc8e..2f6ee0cd15e3 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -262,6 +262,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
} else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
&rproc_phandle)) {
fw_type = SCP;
+ } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vcp",
+ &rproc_phandle)) {
+ fw_type = VCP;
} else {
dev_err(&pdev->dev, "[MTK VCODEC] Could not get venc IPI device");
return -ENODEV;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
index 050b827f0fd0..d981155aeb8c 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
@@ -480,8 +480,13 @@ static void venc_free_rc_buf(struct venc_inst *inst,
{
int i;
struct device *dev;
+ struct mtk_vcodec_fw *fw = inst->ctx->dev->fw_handler;
+
+ if (mtk_vcodec_fw_get_type(fw) == VCP)
+ dev = mtk_vcodec_fw_get_dev(fw);
+ else
+ dev = &inst->ctx->dev->plat_dev->dev;
- dev = &inst->ctx->dev->plat_dev->dev;
mtk_venc_mem_free(inst, dev, &bufs->rc_code);
for (i = 0; i < core_num; i++)
@@ -530,12 +535,18 @@ static int venc_alloc_rc_buf(struct venc_inst *inst,
struct device *dev;
void *tmp_va;
- dev = &inst->ctx->dev->plat_dev->dev;
- if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
- return -ENOMEM;
+ if (mtk_vcodec_fw_get_type(fw) == VCP) {
+ dev = mtk_vcodec_fw_get_dev(fw);
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
+ } else {
+ dev = &inst->ctx->dev->plat_dev->dev;
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
- tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
- memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+ tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
+ memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+ }
for (i = 0; i < core_num; i++) {
if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_info[i]))
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
index 7772b8442ebc..0f4693e04a9f 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
@@ -8,13 +8,23 @@
#include "venc_ipi_msg.h"
#include "venc_vpu_if.h"
+#define VSI_OFFSET_MASK 0x0FFFFFFF
+
static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
{
const struct venc_vpu_ipi_msg_init_comm *msg = data;
struct mtk_vcodec_fw *fw = vpu->ctx->dev->fw_handler;
+ u64 pa_start, vsi_offset;
vpu->inst_addr = msg->init_ack.vpu_inst_addr;
- vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, vpu->inst_addr);
+
+ if (mtk_vcodec_fw_get_type(fw) == VCP) {
+ pa_start = (u64)fw->vcp->iova_addr;
+ vsi_offset = (msg->vpu_vsi_addr & VSI_OFFSET_MASK) - (pa_start & VSI_OFFSET_MASK);
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, ENCODER_MEM) + vsi_offset;
+ } else {
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, msg->vpu_vsi_addr);
+ }
/* Firmware version field value is unspecified on MT8173. */
if (mtk_vcodec_fw_get_type(fw) == VPU)
@@ -155,6 +165,8 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
out.base.venc_inst = (unsigned long)vpu;
if (MTK_ENC_DRV_IS_COMM(vpu->ctx)) {
out.codec_type = vpu->ctx->q_data[MTK_Q_DATA_DST].fmt->fourcc;
+ if (mtk_vcodec_fw_get_type(vpu->ctx->dev->fw_handler) == VCP)
+ out.shared_iova = vpu->ctx->dev->fw_handler->vcp->iova_addr;
msg_size = sizeof(struct venc_ap_ipi_msg_init_comm);
} else {
msg_size = sizeof(struct venc_ap_ipi_msg_init);
--
2.45.2
^ permalink raw reply related
* [PATCH v6 5/6] media: mediatek: encoder: Add a new platform data member
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Add a new platform data member to indicate each encoder IC, so that the
get chip name function by 'of_device_is_compatible' can be removed.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../mediatek/vcodec/encoder/mtk_vcodec_enc.c | 22 ++-----------------
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 6 +++++
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 2 ++
3 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
index f0344888f2cf..b2f911746c01 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
@@ -198,33 +198,15 @@ static int vidioc_enum_fmt_vid_out(struct file *file, void *priv,
pdata->num_output_formats);
}
-static int mtk_vcodec_enc_get_chip_name(struct mtk_vcodec_enc_ctx *ctx)
-{
- struct device *dev = &ctx->dev->plat_dev->dev;
-
- if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-enc"))
- return 8173;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-enc"))
- return 8183;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-enc"))
- return 8192;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-enc"))
- return 8195;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-enc"))
- return 8188;
- else
- return 8173;
-}
-
static int vidioc_venc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
struct mtk_vcodec_enc_ctx *ctx = file_to_enc_ctx(file);
+ const struct mtk_vcodec_enc_pdata *pdata = ctx->dev->venc_pdata;
struct device *dev = &ctx->dev->plat_dev->dev;
- int platform_name = mtk_vcodec_enc_get_chip_name(ctx);
strscpy(cap->driver, dev->driver->name, sizeof(cap->driver));
- snprintf(cap->card, sizeof(cap->card), "MT%d video encoder", platform_name);
+ snprintf(cap->card, sizeof(cap->card), "MT%d video encoder", pdata->venc_model_num);
return 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 2f6ee0cd15e3..7b644f55963b 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -390,6 +390,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata = {
+ .venc_model_num = 8173,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
.output_formats = mtk_video_formats_output,
@@ -400,6 +401,7 @@ static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8173_vp8_pdata = {
+ .venc_model_num = 8173,
.capture_formats = mtk_video_formats_capture_vp8,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_vp8),
.output_formats = mtk_video_formats_output,
@@ -410,6 +412,7 @@ static const struct mtk_vcodec_enc_pdata mt8173_vp8_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
+ .venc_model_num = 8183,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -421,6 +424,7 @@ static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8188_pdata = {
+ .venc_model_num = 8188,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -433,6 +437,7 @@ static const struct mtk_vcodec_enc_pdata mt8188_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
+ .venc_model_num = 8192,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -444,6 +449,7 @@ static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8195_pdata = {
+ .venc_model_num = 8195,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 0529564027c4..769fb5009964 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -21,6 +21,7 @@
/**
* struct mtk_vcodec_enc_pdata - compatible data for each IC
*
+ * @venc_model_num: encoder model number
* @uses_ext: whether the encoder uses the extended firmware messaging format
* @min_bitrate: minimum supported encoding bitrate
* @max_bitrate: maximum supported encoding bitrate
@@ -33,6 +34,7 @@
* @uses_common_fw_iface: whether the encoder uses common driver interface
*/
struct mtk_vcodec_enc_pdata {
+ u16 venc_model_num;
bool uses_ext;
u64 min_bitrate;
u64 max_bitrate;
--
2.45.2
^ permalink raw reply related
* [PATCH v6 2/6] media: mediatek: encoder: Add a new encoder driver interface
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Introduce a new encoder kernel driver interface to ensure compatibility
with the updated encoder software driver running in firmware.
The new driver interface is expected to support more encoder formats,
share more encode parameters between kernel and firmware.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../mediatek/vcodec/common/mtk_vcodec_fw.c | 13 +
.../mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
.../platform/mediatek/vcodec/encoder/Makefile | 1 +
.../mediatek/vcodec/encoder/mtk_vcodec_enc.c | 14 +-
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 8 +-
.../vcodec/encoder/venc/venc_common_if.c | 674 ++++++++++++++++++
.../vcodec/encoder/venc/venc_h264_if.c | 8 +-
.../mediatek/vcodec/encoder/venc_drv_if.h | 11 +-
8 files changed, 712 insertions(+), 18 deletions(-)
create mode 100644 drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
index 4ed7639dfa30..0381acceda25 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
@@ -18,6 +18,19 @@ int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id)
}
EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_ipi);
+int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type)
+{
+ switch (type) {
+ case SCP:
+ return SCP_IPI_VENC_H264;
+ case VCP:
+ return VCP_IPI_ENCODER;
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_venc_ipi);
+
struct mtk_vcodec_fw *mtk_vcodec_fw_select(void *priv, enum mtk_vcodec_fw_type type,
enum mtk_vcodec_fw_use fw_use)
{
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
index 142e2e87905c..e7304a7dd3e0 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
@@ -42,5 +42,6 @@ int mtk_vcodec_fw_ipi_send(struct mtk_vcodec_fw *fw, int id,
void *buf, unsigned int len, unsigned int wait);
int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw);
int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id);
+int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type);
#endif /* _MTK_VCODEC_FW_H_ */
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/Makefile b/drivers/media/platform/mediatek/vcodec/encoder/Makefile
index e621b5b7e5e6..9d3229d56e39 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/Makefile
+++ b/drivers/media/platform/mediatek/vcodec/encoder/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o
mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
+ venc/venc_common_if.o \
mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
index 48cb5dded70a..f0344888f2cf 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
@@ -81,11 +81,11 @@ static int vidioc_venc_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_PROFILE val = %d", ctrl->val);
- p->h264_profile = ctrl->val;
+ p->profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_LEVEL val = %d", ctrl->val);
- p->h264_level = ctrl->val;
+ p->level = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_I_PERIOD:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_I_PERIOD val = %d", ctrl->val);
@@ -385,8 +385,8 @@ static void mtk_venc_set_param(struct mtk_vcodec_enc_ctx *ctx,
mtk_v4l2_venc_err(ctx, "Unsupported fourcc =%d", q_data_src->fmt->fourcc);
break;
}
- param->h264_profile = enc_params->h264_profile;
- param->h264_level = enc_params->h264_level;
+ param->profile = enc_params->profile;
+ param->level = enc_params->level;
/* Config visible resolution */
param->width = q_data_src->visible_width;
@@ -402,8 +402,8 @@ static void mtk_venc_set_param(struct mtk_vcodec_enc_ctx *ctx,
mtk_v4l2_venc_dbg(0, ctx,
"fmt 0x%x, P/L %d/%d w/h %d/%d buf %d/%d fps/bps %d/%d gop %d i_per %d",
- param->input_yuv_fmt, param->h264_profile,
- param->h264_level, param->width, param->height,
+ param->input_yuv_fmt, param->profile,
+ param->level, param->width, param->height,
param->buf_width, param->buf_height,
param->frm_rate, param->bitrate,
param->gop_size, param->intra_period);
@@ -1157,6 +1157,8 @@ static void mtk_venc_worker(struct work_struct *work)
frm_buf.fb_addr[i].size =
(size_t)src_buf->vb2_buf.planes[i].length;
}
+ frm_buf.num_planes = src_buf->vb2_buf.num_planes;
+
bs_buf.va = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
bs_buf.dma_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
bs_buf.size = (size_t)dst_buf->vb2_buf.planes[0].length;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 0cddfa13594f..53369adc083b 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -69,8 +69,8 @@ enum mtk_encode_param {
* @framerate_denom: frame rate denominator. ex: framerate_num=30 and
* framerate_denom=1 means FPS is 30
* @h264_max_qp: Max value for H.264 quantization parameter
- * @h264_profile: V4L2 defined H.264 profile
- * @h264_level: V4L2 defined H.264 level
+ * @profile: V4L2 defined profile
+ * @level: V4L2 defined level
* @force_intra: force/insert intra frame
*/
struct mtk_enc_params {
@@ -84,8 +84,8 @@ struct mtk_enc_params {
unsigned int framerate_num;
unsigned int framerate_denom;
unsigned int h264_max_qp;
- unsigned int h264_profile;
- unsigned int h264_level;
+ unsigned int profile;
+ unsigned int level;
unsigned int force_intra;
};
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
new file mode 100644
index 000000000000..050b827f0fd0
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
@@ -0,0 +1,674 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2025 MediaTek Inc.
+ */
+
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_drv.h"
+#include "../venc_drv_base.h"
+#include "../venc_drv_if.h"
+#include "../venc_vpu_if.h"
+#include "../../common/mtk_vcodec_intr.h"
+#include "../../common/mtk_vcodec_util.h"
+
+#define SEQ_HEADER_SIZE 1024
+#define PPS_SIZE 128
+#define MAX_DPB_SIZE 16
+#define MAX_VENC_CORE 3
+#define VENC_CONFIG_LENGTH 115
+#define VENC_CONFIG_DATA 128
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_bs_mode - encode bitstream mode
+ * @VENC_BS_MODE_SPS: encode sps
+ * @VENC_BS_MODE_PPS: encode pps
+ * @VENC_BS_MODE_VPS: encode vps
+ * @VENC_BS_MODE_SEQ_HDR: encode sequence header
+ * @VENC_BS_MODE_FRAME: encode frame
+ * @VENC_BS_MODE_FRAME_FINAL: encode final frame
+ * @VENC_BS_MODE_MAX: max value
+ */
+enum venc_bs_mode {
+ VENC_BS_MODE_SPS = 0,
+ VENC_BS_MODE_PPS,
+ VENC_BS_MODE_VPS,
+ VENC_BS_MODE_SEQ_HDR,
+ VENC_BS_MODE_FRAME,
+ VENC_BS_MODE_FRAME_FINAL,
+ VENC_BS_MODE_MAX
+};
+
+/**
+ * struct venc_config - Structure for encoder configuration
+ * AP-W/R : AP is writer/reader on this item
+ * MCU-W/R: MCU is write/reader on this item
+ * @input_fourcc: input format fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: visible width of resolution
+ * @pic_h: visible height of resolution
+ * @buf_w: buffer alignment width of resolution
+ * @buf_h: buffer alignment height of resolution
+ * @gop_size: group of picture size (IDR frame period)
+ * @intra_period: I frame period
+ * @framerate: frame rate in fps
+ * @profile: profile_idc in SPS
+ * @level: level_idc in SPS
+ * @core_num: encoder core num
+ * @dpb_size: encode dpb size
+ * @reserved: reserved fields config
+ */
+struct venc_config {
+ __u32 input_fourcc;
+ __u32 bitrate;
+ __u32 pic_w;
+ __u32 pic_h;
+ __u32 buf_w;
+ __u32 buf_h;
+ __u32 gop_size;
+ __u32 intra_period;
+ __u32 framerate;
+ __u32 profile;
+ __u32 level;
+ __u32 core_num;
+ __u32 dpb_size;
+ __u32 reserved[VENC_CONFIG_LENGTH];
+};
+
+/**
+ * struct venc_config_data - Structure for configuration data
+ * @config_data: extended configuration data besides the basic configuration
+ */
+struct venc_config_data {
+ unsigned int config_data[VENC_CONFIG_DATA];
+};
+
+/**
+ * struct venc_work_buf - Structure for working buffer information
+ * AP-W/R : AP is writer/reader on this item
+ * MCU-W/R: MCU is write/reader on this item
+ * @iova: IO virtual address
+ * @pa: physical address
+ * @pa_64: for 64bit pa padding
+ * @va: virtual address
+ * @va_padding: for 64bit va padding
+ * @size: buffer size
+ * @size_padding: for 64bit size padding
+ */
+struct venc_work_buf {
+ unsigned long long iova;
+ union {
+ unsigned int pa;
+ unsigned long long pa_64;
+ };
+ union {
+ void *va;
+ unsigned long long va_padding;
+ };
+ union {
+ unsigned int size;
+ unsigned long long size_padding;
+ };
+};
+
+/**
+ * struct venc_work_buf_list - Structure for encode working buffer list
+ * @rc_code: RC code buffer
+ * @rc_info: RC info buffer
+ * @luma: luma buffer
+ * @chroma: chroma buffer
+ * @sub_luma: sub luma buffer
+ * @sub_write: sub write buffer
+ * @col_mv: col_mv buffer
+ * @wpp: wpp buffer
+ * @wpp_nbm: wpp nbm buffer
+ * @skip_frame: skip frame buffer
+ */
+struct venc_work_buf_list {
+ struct venc_work_buf rc_code;
+ struct venc_work_buf rc_info[MAX_VENC_CORE];
+ struct venc_work_buf luma[MAX_DPB_SIZE];
+ struct venc_work_buf chroma[MAX_DPB_SIZE];
+ struct venc_work_buf sub_luma[MAX_DPB_SIZE];
+ struct venc_work_buf sub_write[MAX_DPB_SIZE];
+ struct venc_work_buf col_mv[MAX_DPB_SIZE];
+ struct venc_work_buf wpp[MAX_VENC_CORE];
+ struct venc_work_buf wpp_nbm[MAX_VENC_CORE];
+ struct venc_work_buf skip_frame;
+};
+
+/**
+ * struct venc_info - Structure for encode frame and bs information
+ * @fb_addr: frame buffer address array
+ * @fb_size: frame buffer size array
+ * @bs_addr: bitstream buffer address
+ * @bs_size: bitstream buffer size
+ */
+struct venc_info {
+ unsigned long long fb_addr[VIDEO_MAX_PLANES];
+ unsigned int fb_size[VIDEO_MAX_PLANES];
+ unsigned long long bs_addr;
+ unsigned long long bs_size;
+};
+
+/**
+ * struct venc_vsi - Structure for VCP driver control and info share
+ * AP-W/R : AP is writer/reader on this item
+ * VCP-W/R: VCP is write/reader on this item
+ * @config: encoder configuration
+ * @data: encoder configuration data
+ * @bufs: encoder working buffers
+ * @venc: encoder information
+ */
+struct venc_vsi {
+ struct venc_config config;
+ struct venc_config_data data;
+ struct venc_work_buf_list bufs;
+ struct venc_info venc;
+};
+
+/**
+ * struct venc_inst - Structure for encoder instance
+ * @hw_base: hardware io address
+ * @pps_buf: PPS buffer
+ * @seq_buf: sequence header buffer
+ * @work_buf_allocated: work buffer allocated or not
+ * @frm_cnt: encoded frame count
+ * @skip_frm_cnt: encoded skip frame count
+ * @prepend_hdr: prepend header flag
+ * @vpu_inst: vpu instance
+ * @vsi: encode vsi
+ * @ctx: encoder context
+ */
+struct venc_inst {
+ void __iomem *hw_base;
+ struct mtk_vcodec_mem pps_buf;
+ struct mtk_vcodec_mem seq_buf;
+ bool work_buf_allocated;
+ unsigned int frm_cnt;
+ unsigned int skip_frm_cnt;
+ unsigned int prepend_hdr;
+ struct venc_vpu_inst vpu_inst;
+ struct venc_vsi *vsi;
+ struct mtk_vcodec_enc_ctx *ctx;
+};
+
+static int venc_init(struct mtk_vcodec_enc_ctx *ctx)
+{
+ int ret = 0;
+ struct venc_inst *inst;
+
+ inst = kzalloc_obj(inst, GFP_KERNEL);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->ctx = ctx;
+ inst->vpu_inst.ctx = ctx;
+ inst->vpu_inst.id = mtk_vcodec_fw_get_venc_ipi(ctx->dev->fw_handler->type);
+ inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx->dev->reg_base, VENC_SYS);
+
+ ret = vpu_enc_init(&inst->vpu_inst);
+ inst->vsi = (struct venc_vsi *)inst->vpu_inst.vsi;
+
+ if (ret) {
+ kfree(inst);
+ return ret;
+ }
+
+ ctx->drv_handle = inst;
+
+ return 0;
+}
+
+static inline u32 venc_read_reg(struct venc_inst *inst, u32 addr)
+{
+ return readl(inst->hw_base + addr);
+}
+
+static unsigned int venc_wait_encode_done(struct venc_inst *inst)
+{
+ unsigned int irq_status = 0;
+ struct mtk_vcodec_enc_ctx *ctx = (struct mtk_vcodec_enc_ctx *)inst->ctx;
+
+ if (!mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+ WAIT_INTR_TIMEOUT_MS, 0)) {
+ irq_status = ctx->irq_status;
+ mtk_venc_debug(ctx, "irq_status %x <-", irq_status);
+ }
+ return irq_status;
+}
+
+static void venc_set_bufs(struct venc_inst *inst,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf)
+{
+ unsigned int i;
+
+ if (frm_buf) {
+ for (i = 0; i < frm_buf->num_planes; i++) {
+ inst->vsi->venc.fb_addr[i] = frm_buf->fb_addr[i].dma_addr;
+ inst->vsi->venc.fb_size[i] = frm_buf->fb_addr[i].size;
+ mtk_venc_debug(inst->ctx, "%s: fb_buf[%d]: %llx(%d)\n",
+ __func__, i,
+ inst->vsi->venc.fb_addr[i],
+ inst->vsi->venc.fb_size[i]);
+ }
+ }
+
+ if (bs_buf) {
+ inst->vsi->venc.bs_addr = bs_buf->dma_addr;
+ inst->vsi->venc.bs_size = bs_buf->size;
+ mtk_venc_debug(inst->ctx, "%s: bs_buf: %llx(%d)\n",
+ __func__,
+ inst->vsi->venc.bs_addr,
+ (unsigned int)inst->vsi->venc.bs_size);
+ }
+}
+
+static int venc_encode_sps(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, NULL, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_SPS, NULL, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_SPS) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_SPS);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+ mtk_venc_debug(inst->ctx, "sps bs size %d <-", *bs_size);
+
+ return ret;
+}
+
+static int venc_encode_pps(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, NULL, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_PPS, NULL, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_PPS) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_PPS);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+ mtk_venc_debug(inst->ctx, "pps bs size %d <-", *bs_size);
+
+ return ret;
+}
+
+static int venc_encode_header(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int bs_size_sps;
+ unsigned int bs_size_pps;
+
+ ret = venc_encode_sps(inst, bs_buf, &bs_size_sps);
+ if (ret)
+ return ret;
+
+ ret = venc_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
+ if (ret)
+ return ret;
+
+ memcpy(bs_buf->va + bs_size_sps, inst->pps_buf.va, bs_size_pps);
+ *bs_size = bs_size_sps + bs_size_pps;
+
+ return ret;
+}
+
+static int venc_encode_frame(struct venc_inst *inst,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, frm_buf, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_FRAME, frm_buf, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_FRM) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_FRM);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+
+ ++inst->frm_cnt;
+
+ return ret;
+}
+
+static int venc_encode(void *handle,
+ enum venc_start_opt opt,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf,
+ struct venc_done_result *result)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+ struct mtk_vcodec_enc_ctx *ctx;
+ unsigned int bs_size_hdr;
+
+ if (WARN_ON(!inst || !inst->vsi))
+ return -EINVAL;
+
+ ctx = inst->ctx;
+
+ mtk_venc_debug(ctx, "%s: opt: %d\n", __func__, opt);
+
+ enable_irq(ctx->dev->enc_irq);
+ switch (opt) {
+ case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
+ ret = venc_encode_header(inst, bs_buf, &bs_size_hdr);
+ if (ret)
+ goto encode_err;
+
+ result->bs_size = bs_size_hdr;
+ result->is_key_frm = false;
+ break;
+ }
+
+ case VENC_START_OPT_ENCODE_FRAME: {
+ if (!inst->prepend_hdr) {
+ ret = venc_encode_frame(inst, frm_buf, bs_buf, &result->bs_size);
+ if (ret)
+ goto encode_err;
+
+ result->is_key_frm = inst->vpu_inst.is_key_frm;
+ break;
+ }
+
+ ret = venc_encode_header(inst, &inst->seq_buf, &bs_size_hdr);
+ if (ret)
+ goto encode_err;
+
+ ret = venc_encode_frame(inst, frm_buf, bs_buf, &result->bs_size);
+ if (ret)
+ goto encode_err;
+
+ memmove(bs_buf->va + bs_size_hdr, bs_buf->va, result->bs_size);
+ memcpy(bs_buf->va, inst->seq_buf.va, bs_size_hdr);
+ result->bs_size += bs_size_hdr;
+
+ inst->prepend_hdr = 0;
+ result->is_key_frm = inst->vpu_inst.is_key_frm;
+ break;
+ }
+
+ default:
+ mtk_venc_err(inst->ctx, "venc_opt %d not supported", opt);
+ ret = -EINVAL;
+ break;
+ }
+
+encode_err:
+ disable_irq(ctx->dev->enc_irq);
+ mtk_venc_debug(ctx, "opt %d, return %d", opt, ret);
+
+ return ret;
+}
+
+static int mtk_venc_mem_alloc(struct venc_inst *inst,
+ struct device *dev,
+ struct venc_work_buf *buf)
+{
+ dma_addr_t dma_addr;
+
+ if (WARN_ON(!dev || !buf))
+ return -EINVAL;
+
+ if (buf->size == 0)
+ return 0;
+
+ buf->va = dma_alloc_coherent(dev, buf->size, &dma_addr, GFP_KERNEL);
+ if (!buf->va)
+ return -ENOMEM;
+
+ buf->iova = (unsigned long long)dma_addr;
+
+ mtk_venc_debug(inst->ctx, "allocate buffer, size: %d, va: %p, iova: 0x%llx",
+ buf->size, buf->va, buf->iova);
+
+ return 0;
+}
+
+static void mtk_venc_mem_free(struct venc_inst *inst,
+ struct device *dev,
+ struct venc_work_buf *buf)
+{
+ if (WARN_ON(!dev || !buf))
+ return;
+
+ if (!buf->va)
+ return;
+
+ mtk_venc_debug(inst->ctx, "free buffer, size: %d, va: %p, iova: 0x%llx",
+ buf->size, buf->va, buf->iova);
+
+ dma_free_coherent(dev, buf->size, buf->va, buf->iova);
+ buf->va = NULL;
+ buf->iova = 0;
+ buf->size = 0;
+}
+
+static void venc_free_rc_buf(struct venc_inst *inst,
+ struct venc_work_buf_list *bufs,
+ unsigned int core_num)
+{
+ int i;
+ struct device *dev;
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+ mtk_venc_mem_free(inst, dev, &bufs->rc_code);
+
+ for (i = 0; i < core_num; i++)
+ mtk_venc_mem_free(inst, dev, &bufs->rc_info[i]);
+}
+
+static void venc_free_work_buf(struct venc_inst *inst)
+{
+ int i;
+ struct venc_work_buf_list *bufs = &inst->vsi->bufs;
+ unsigned int core_num = inst->vsi->config.core_num;
+ unsigned int dpb_size = inst->vsi->config.dpb_size;
+ struct device *dev;
+
+ if (bufs->rc_code.va)
+ venc_free_rc_buf(inst, bufs, core_num);
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+
+ for (i = 0; i < core_num; i++) {
+ mtk_venc_mem_free(inst, dev, &bufs->wpp[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->wpp_nbm[i]);
+ }
+
+ for (i = 0; i < dpb_size; i++) {
+ mtk_venc_mem_free(inst, dev, &bufs->luma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->chroma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->sub_luma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->sub_write[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->col_mv[i]);
+ }
+
+ if (inst->pps_buf.va)
+ mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+
+ if (inst->seq_buf.va)
+ mtk_vcodec_mem_free(inst->ctx, &inst->seq_buf);
+}
+
+static int venc_alloc_rc_buf(struct venc_inst *inst,
+ struct venc_work_buf_list *bufs,
+ unsigned int core_num)
+{
+ int i;
+ struct mtk_vcodec_fw *fw = inst->ctx->dev->fw_handler;
+ struct device *dev;
+ void *tmp_va;
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
+
+ tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
+ memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+
+ for (i = 0; i < core_num; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_info[i]))
+ goto err_rc_buf;
+ }
+
+ return 0;
+
+err_rc_buf:
+ venc_free_rc_buf(inst, bufs, core_num);
+
+ return -ENOMEM;
+}
+
+static int venc_alloc_work_buf(struct venc_inst *inst)
+{
+ int i, ret;
+ struct venc_work_buf_list *bufs = &inst->vsi->bufs;
+ unsigned int core_num = inst->vsi->config.core_num;
+ unsigned int dpb_size = inst->vsi->config.dpb_size;
+ struct device *dev;
+
+ if (bufs->rc_code.size != 0) {
+ ret = venc_alloc_rc_buf(inst, bufs, core_num);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate rc buf");
+ return -ENOMEM;
+ }
+ }
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+
+ for (i = 0; i < core_num; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->wpp[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->wpp_nbm[i]))
+ goto err_alloc;
+ }
+
+ for (i = 0; i < dpb_size; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->luma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->chroma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->sub_luma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->sub_write[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->col_mv[i]))
+ goto err_alloc;
+ }
+
+ /* the pps_buf and seq_buf are used by AP side only */
+ inst->pps_buf.size = PPS_SIZE;
+ ret = mtk_vcodec_mem_alloc(inst->ctx, &inst->pps_buf);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate pps_buf");
+ goto err_alloc;
+ }
+
+ inst->seq_buf.size = SEQ_HEADER_SIZE;
+ ret = mtk_vcodec_mem_alloc(inst->ctx, &inst->seq_buf);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate seq_buf");
+ goto err_alloc;
+ }
+ return 0;
+
+err_alloc:
+ venc_free_work_buf(inst);
+ return -ENOMEM;
+}
+
+static int venc_set_param(void *handle,
+ enum venc_set_param_type type,
+ struct venc_enc_param *enc_prm)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+
+ switch (type) {
+ case VENC_SET_PARAM_ENC:
+ if (WARN_ON(!inst->vsi))
+ return -EINVAL;
+ inst->vsi->config.input_fourcc = enc_prm->input_yuv_fmt;
+ inst->vsi->config.bitrate = enc_prm->bitrate;
+ inst->vsi->config.pic_w = enc_prm->width;
+ inst->vsi->config.pic_h = enc_prm->height;
+ inst->vsi->config.buf_w = enc_prm->buf_width;
+ inst->vsi->config.buf_h = enc_prm->buf_height;
+ inst->vsi->config.gop_size = enc_prm->gop_size;
+ inst->vsi->config.framerate = enc_prm->frm_rate;
+ inst->vsi->config.intra_period = enc_prm->intra_period;
+ inst->vsi->config.profile = enc_prm->profile;
+ inst->vsi->config.level = enc_prm->level;
+
+ ret = vpu_enc_set_param(&inst->vpu_inst, type, enc_prm);
+ if (ret)
+ break;
+
+ if (inst->work_buf_allocated) {
+ venc_free_work_buf(inst);
+ inst->work_buf_allocated = false;
+ }
+ ret = venc_alloc_work_buf(inst);
+ if (ret)
+ break;
+ inst->work_buf_allocated = true;
+ break;
+ case VENC_SET_PARAM_PREPEND_HEADER:
+ inst->prepend_hdr = 1;
+ break;
+ default:
+ ret = vpu_enc_set_param(&inst->vpu_inst, type, enc_prm);
+ break;
+ }
+
+ return ret;
+}
+
+static int venc_deinit(void *handle)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+
+ ret = vpu_enc_deinit(&inst->vpu_inst);
+
+ if (inst->work_buf_allocated)
+ venc_free_work_buf(inst);
+
+ kfree(inst);
+
+ return ret;
+}
+
+const struct venc_common_if venc_if = {
+ .init = venc_init,
+ .encode = venc_encode,
+ .set_param = venc_set_param,
+ .deinit = venc_deinit,
+};
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
index d2f4d732d2f7..320c505cdb21 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
@@ -723,9 +723,9 @@ static void h264_enc_set_vsi_configs(struct venc_h264_inst *inst,
inst->vsi->config.framerate = enc_prm->frm_rate;
inst->vsi->config.intra_period = enc_prm->intra_period;
inst->vsi->config.profile =
- h264_get_profile(inst, enc_prm->h264_profile);
+ h264_get_profile(inst, enc_prm->profile);
inst->vsi->config.level =
- h264_get_level(inst, enc_prm->h264_level);
+ h264_get_level(inst, enc_prm->level);
inst->vsi->config.wfd = 0;
}
@@ -742,9 +742,9 @@ static void h264_enc_set_vsi_34_configs(struct venc_h264_inst *inst,
inst->vsi_34->config.framerate = enc_prm->frm_rate;
inst->vsi_34->config.intra_period = enc_prm->intra_period;
inst->vsi_34->config.profile =
- h264_get_profile(inst, enc_prm->h264_profile);
+ h264_get_profile(inst, enc_prm->profile);
inst->vsi_34->config.level =
- h264_get_level(inst, enc_prm->h264_level);
+ h264_get_level(inst, enc_prm->level);
inst->vsi_34->config.wfd = 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
index 889440a436b6..3c2a1b5e9312 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
@@ -66,8 +66,8 @@ enum venc_set_param_type {
* struct venc_enc_prm - encoder settings for VENC_SET_PARAM_ENC used in
* venc_if_set_param()
* @input_fourcc: input yuv format
- * @h264_profile: V4L2 defined H.264 profile
- * @h264_level: V4L2 defined H.264 level
+ * @profile: V4L2 defined profile
+ * @level: V4L2 defined level
* @width: image width
* @height: image height
* @buf_width: buffer width
@@ -79,8 +79,8 @@ enum venc_set_param_type {
*/
struct venc_enc_param {
enum venc_yuv_fmt input_yuv_fmt;
- unsigned int h264_profile;
- unsigned int h264_level;
+ unsigned int profile;
+ unsigned int level;
unsigned int width;
unsigned int height;
unsigned int buf_width;
@@ -107,9 +107,11 @@ struct venc_frame_info {
/*
* struct venc_frm_buf - frame buffer information used in venc_if_encode()
* @fb_addr: plane frame buffer addresses
+ * @num_planes: number of planes
*/
struct venc_frm_buf {
struct mtk_vcodec_fb fb_addr[MTK_VCODEC_MAX_PLANES];
+ unsigned int num_planes;
};
/*
@@ -124,6 +126,7 @@ struct venc_done_result {
extern const struct venc_common_if venc_h264_if;
extern const struct venc_common_if venc_vp8_if;
+extern const struct venc_common_if venc_if;
/*
* venc_if_init - Create the driver handle
--
2.45.2
^ permalink raw reply related
* [PATCH v6 6/6] media: mediatek: encoder: Add MT8196 encoder compatible data
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
MT8196 encoder use common firmware interface, add compatible data to
support MT8196 encoding, and need set dma mask to support 34bit.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 19 +++++++++++++++++++
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 7b644f55963b..d7328d013ff6 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -20,6 +20,8 @@
#include "mtk_vcodec_enc_pm.h"
#include "../common/mtk_vcodec_intr.h"
+#define VENC_DMA_BIT_MASK 34
+
static const struct mtk_video_fmt mtk_video_formats_output[] = {
{
.fourcc = V4L2_PIX_FMT_NV12M,
@@ -309,6 +311,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_res;
}
+ if (dev->venc_pdata->set_dma_bit_mask)
+ dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(VENC_DMA_BIT_MASK));
+
mutex_init(&dev->enc_mutex);
mutex_init(&dev->dev_mutex);
spin_lock_init(&dev->dev_ctx_lock);
@@ -460,6 +465,19 @@ static const struct mtk_vcodec_enc_pdata mt8195_pdata = {
.core_id = VENC_SYS,
};
+static const struct mtk_vcodec_enc_pdata mt8196_pdata = {
+ .venc_model_num = 8196,
+ .capture_formats = mtk_video_formats_capture_h264,
+ .num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
+ .output_formats = mtk_video_formats_output,
+ .num_output_formats = ARRAY_SIZE(mtk_video_formats_output),
+ .min_bitrate = 64,
+ .max_bitrate = 100000000,
+ .core_id = VENC_SYS,
+ .uses_common_fw_iface = true,
+ .set_dma_bit_mask = true,
+};
+
static const struct of_device_id mtk_vcodec_enc_match[] = {
{.compatible = "mediatek,mt8173-vcodec-enc",
.data = &mt8173_avc_pdata},
@@ -469,6 +487,7 @@ static const struct of_device_id mtk_vcodec_enc_match[] = {
{.compatible = "mediatek,mt8188-vcodec-enc", .data = &mt8188_pdata},
{.compatible = "mediatek,mt8192-vcodec-enc", .data = &mt8192_pdata},
{.compatible = "mediatek,mt8195-vcodec-enc", .data = &mt8195_pdata},
+ {.compatible = "mediatek,mt8196-vcodec-enc", .data = &mt8196_pdata},
{},
};
MODULE_DEVICE_TABLE(of, mtk_vcodec_enc_match);
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 769fb5009964..475953d39aa4 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -32,6 +32,7 @@
* @core_id: stand for h264 or vp8 encode index
* @uses_34bit: whether the encoder uses 34-bit iova
* @uses_common_fw_iface: whether the encoder uses common driver interface
+ * @set_dma_bit_mask: whether the encoder need set extra DMA bit mask
*/
struct mtk_vcodec_enc_pdata {
u16 venc_model_num;
@@ -45,6 +46,7 @@ struct mtk_vcodec_enc_pdata {
u8 core_id;
bool uses_34bit;
bool uses_common_fw_iface;
+ bool set_dma_bit_mask;
};
/*
--
2.45.2
^ permalink raw reply related
* [PATCH v6 3/6] media: mediatek: encoder: Add support for common firmware interface
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
The existing encoder firmware interface implied just one type of codec:
H.264. Future encoders may support additional codecs; however adding
entire sets of interfaces for them is not scalable.
Instead, a new "common" firmware interface is defined for non codec
specific messages. The new messages encapsulate the old ones for
backward compatibility.
This patch adds support for these new messages.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 3 ++
.../mediatek/vcodec/encoder/venc_drv_if.c | 3 +-
.../mediatek/vcodec/encoder/venc_ipi_msg.h | 26 +++++++++++++++
.../mediatek/vcodec/encoder/venc_vpu_if.c | 33 ++++++++++++-------
4 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 53369adc083b..0529564027c4 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -16,6 +16,7 @@
#define MTK_ENC_CTX_IS_EXT(ctx) ((ctx)->dev->venc_pdata->uses_ext)
#define MTK_ENC_IOVA_IS_34BIT(ctx) ((ctx)->dev->venc_pdata->uses_34bit)
+#define MTK_ENC_DRV_IS_COMM(ctx) (((ctx)->dev->venc_pdata->uses_common_fw_iface))
/**
* struct mtk_vcodec_enc_pdata - compatible data for each IC
@@ -29,6 +30,7 @@
* @num_output_formats: number of entries in output_formats
* @core_id: stand for h264 or vp8 encode index
* @uses_34bit: whether the encoder uses 34-bit iova
+ * @uses_common_fw_iface: whether the encoder uses common driver interface
*/
struct mtk_vcodec_enc_pdata {
bool uses_ext;
@@ -40,6 +42,7 @@ struct mtk_vcodec_enc_pdata {
size_t num_output_formats;
u8 core_id;
bool uses_34bit;
+ bool uses_common_fw_iface;
};
/*
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
index e83747b8d69a..f8c9349c18c0 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
@@ -19,13 +19,14 @@
int venc_if_init(struct mtk_vcodec_enc_ctx *ctx, unsigned int fourcc)
{
int ret = 0;
+ const bool uses_common_fw_iface = MTK_ENC_DRV_IS_COMM(ctx);
switch (fourcc) {
case V4L2_PIX_FMT_VP8:
ctx->enc_if = &venc_vp8_if;
break;
case V4L2_PIX_FMT_H264:
- ctx->enc_if = &venc_h264_if;
+ ctx->enc_if = uses_common_fw_iface ? &venc_if : &venc_h264_if;
break;
default:
return -EINVAL;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h b/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
index bb16d96a7f57..ce3c2c8059fb 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
@@ -45,6 +45,20 @@ struct venc_ap_ipi_msg_init {
uint64_t venc_inst;
};
+/**
+ * struct venc_ap_ipi_msg_init_comm - AP to VPU init cmd structure
+ * @base: AP to VPU init cmd structure
+ * @codec_type: encoder type
+ * @reserved: reserved field
+ * @shared_iova: shared iova
+ */
+struct venc_ap_ipi_msg_init_comm {
+ struct venc_ap_ipi_msg_init base;
+ u32 codec_type;
+ u32 reserved;
+ u64 shared_iova;
+};
+
/**
* struct venc_ap_ipi_msg_set_param - AP to VPU set_param cmd structure
* @msg_id: message id (AP_IPIMSG_XXX_ENC_SET_PARAM)
@@ -175,6 +189,18 @@ struct venc_vpu_ipi_msg_init {
uint32_t venc_abi_version;
};
+/**
+ * struct venc_vpu_ipi_msg_init_comm - VPU ack AP init cmd structure
+ * @init_ack: AP init cmd structure
+ * @vpu_vsi_addr: VSI address from VPU
+ * @reserved: reserved field
+ */
+struct venc_vpu_ipi_msg_init_comm {
+ struct venc_vpu_ipi_msg_init init_ack;
+ u32 vpu_vsi_addr;
+ u32 reserved;
+};
+
/**
* struct venc_vpu_ipi_msg_set_param - VPU ack AP set_param cmd structure
* @msg_id: message id (VPU_IPIMSG_XXX_ENC_SET_PARAM_DONE)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
index 0c825aa7224d..7772b8442ebc 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
@@ -10,24 +10,25 @@
static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
{
- const struct venc_vpu_ipi_msg_init *msg = data;
+ const struct venc_vpu_ipi_msg_init_comm *msg = data;
+ struct mtk_vcodec_fw *fw = vpu->ctx->dev->fw_handler;
- vpu->inst_addr = msg->vpu_inst_addr;
- vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
- msg->vpu_inst_addr);
+ vpu->inst_addr = msg->init_ack.vpu_inst_addr;
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, vpu->inst_addr);
/* Firmware version field value is unspecified on MT8173. */
- if (mtk_vcodec_fw_get_type(vpu->ctx->dev->fw_handler) == VPU)
+ if (mtk_vcodec_fw_get_type(fw) == VPU)
return;
/* Check firmware version. */
- mtk_venc_debug(vpu->ctx, "firmware version: 0x%x\n", msg->venc_abi_version);
- switch (msg->venc_abi_version) {
+ mtk_venc_debug(vpu->ctx, "firmware version: 0x%x\n",
+ msg->init_ack.venc_abi_version);
+ switch (msg->init_ack.venc_abi_version) {
case 1:
break;
default:
mtk_venc_err(vpu->ctx, "unhandled firmware version 0x%x\n",
- msg->venc_abi_version);
+ msg->init_ack.venc_abi_version);
vpu->failure = 1;
break;
}
@@ -133,7 +134,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
int vpu_enc_init(struct venc_vpu_inst *vpu)
{
int status;
- struct venc_ap_ipi_msg_init out = { };
+ size_t msg_size;
+ struct venc_ap_ipi_msg_init_comm out = { };
init_waitqueue_head(&vpu->wq_hd);
vpu->signaled = 0;
@@ -149,9 +151,16 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
return -EINVAL;
}
- out.msg_id = AP_IPIMSG_ENC_INIT;
- out.venc_inst = (unsigned long)vpu;
- if (vpu_enc_send_msg(vpu, &out, sizeof(out))) {
+ out.base.msg_id = AP_IPIMSG_ENC_INIT;
+ out.base.venc_inst = (unsigned long)vpu;
+ if (MTK_ENC_DRV_IS_COMM(vpu->ctx)) {
+ out.codec_type = vpu->ctx->q_data[MTK_Q_DATA_DST].fmt->fourcc;
+ msg_size = sizeof(struct venc_ap_ipi_msg_init_comm);
+ } else {
+ msg_size = sizeof(struct venc_ap_ipi_msg_init);
+ }
+
+ if (vpu_enc_send_msg(vpu, &out, msg_size)) {
mtk_venc_err(vpu->ctx, "AP_IPIMSG_ENC_INIT fail");
return -EINVAL;
}
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net] net: airoha: stop net_device TX queue before updating CPU index
From: Lorenzo Bianconi @ 2026-04-23 7:42 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
> Currently, airoha_eth driver updates the CPU index register prior of
> verifying whether the number of free descriptors has fallen below the
> threshold.
> Move net_device TX queue length check before updating the TX CPU index
> in order to update TX CPU index even if there are more packets to be
> transmitted but the net_device TX queue is going to be stopped
> accounting the inflight packets.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..5d327237e274 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2058,17 +2058,16 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> skb_tx_timestamp(skb);
> netdev_tx_sent_queue(txq, skb->len);
> + if (q->ndesc - q->queued < q->free_thr) {
> + netif_tx_stop_queue(txq);
> + q->txq_stopped = true;
> + }
>
> if (netif_xmit_stopped(txq) || !netdev_xmit_more())
> airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid),
> TX_RING_CPU_IDX_MASK,
> FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
>
> - if (q->ndesc - q->queued < q->free_thr) {
> - netif_tx_stop_queue(txq);
> - q->txq_stopped = true;
> - }
> -
> spin_unlock_bh(&q->lock);
>
> return NETDEV_TX_OK;
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-xmit-stop-condition-344dc0292a19
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467%40kernel.org
- Could this cause a deadlock if exactly q->free_thr descriptors are free?
This does not seem a problem to me since, even if the netdev tx queue is
stopped as described in the report, the airoha_qdma_tx_napi_poll() will free
space in the queue and subsequent packets will update REG_TX_CPU_IDX register.
- Is it possible for this loop to read past the end of the frags array?
As pointed out by Sashiko, this issue is not introduced by this patch and I
will fix with a dedicated patch.
- Might this lead to memory corruption if the tcp header is not in the linear area?
This issue is not introduced by this patch and I will fix with a dedicated patch.
- If an error occurs during transmission, the driver jumps to the error label
frees the skb, and returns NETDEV_TX_OK without ringing the qdma cpu index doorbell?
Similar to the first issue, this does not seem a problem to me since subsequent
packets will update REG_TX_CPU_IDX register.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
From: Ard Biesheuvel @ 2026-04-23 7:43 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-2-l.rubusch@gmail.com>
Hi Lothar,
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The driver allocated memory for work_data in the non-blocking read
> path but never free'd it again. After first read-out the memory pointer
> seemed to be recycled and never was allocated again, due to some errors
> in the logic, so that the leak was not growing.
>
Why can't we just reuse the work_data, instead of alloc/freeing it every time?
> Add kfree(work_data) in the completion callback on error. then add
> kfree(work_data) after the data is consumed in the subsequent read
> call. Finally ensure atomic_dec() is called only after the data has
> been consumed or an error occurred to prevent race conditions.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 43 ++++++++++++++++++++--------------
> 1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index dbb39ed0cea1..19720bdd446d 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -25,13 +25,17 @@ static void atmel_sha204a_rng_done(struct
> atmel_i2c_work_data *work_data,
> struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
> struct hwrng *rng = areq;
>
> - if (status)
> + if (status) {
> dev_warn_ratelimited(&i2c_priv->client->dev,
> "i2c transaction failed (%d)\n",
> status);
> + kfree(work_data);
> + rng->priv = 0;
> + atomic_dec(&i2c_priv->tfm_count);
> + return;
> + }
>
> rng->priv = (unsigned long)work_data;
> - atomic_dec(&i2c_priv->tfm_count);
> }
>
> static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void
> *data,
> @@ -42,31 +46,36 @@ static int
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> - /* keep maximum 1 asynchronous read in flight at any time */
> - if (!atomic_add_unless(&i2c_priv->tfm_count, 1, 1))
> - return 0;
> -
> + /* Verify if data available from last run */
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> max = min(sizeof(work_data->cmd.data), max);
> memcpy(data, &work_data->cmd.data, max);
> - rng->priv = 0;
> - } else {
> - work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> - if (!work_data) {
> - atomic_dec(&i2c_priv->tfm_count);
> - return -ENOMEM;
> - }
> - work_data->ctx = i2c_priv;
> - work_data->client = i2c_priv->client;
>
> - max = 0;
> + /* Now, free memory */
> + kfree(work_data);
> + rng->priv = 0;
> + atomic_dec(&i2c_priv->tfm_count);
> + return max;
> }
>
> + /* When a request is still in-flight but not processed */
> + if (atomic_read(&i2c_priv->tfm_count) > 0)
> + return 0;
> +
> + /* Start a new request */
> + work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> + if (!work_data)
> + return -ENOMEM;
> +
> + atomic_inc(&i2c_priv->tfm_count);
> + work_data->ctx = i2c_priv;
> + work_data->client = i2c_priv->client;
> +
> atmel_i2c_init_random_cmd(&work_data->cmd);
> atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
>
> - return max;
> + return 0;
> }
>
> static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 2/8] xor/arm: Replace vectorized implementation with arm64's intrinsics
From: Christoph Hellwig @ 2026-04-23 7:44 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-12-ardb+git@google.com>
Nice!
Acked-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-04-23 7:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-13-ardb+git@google.com>
> +extern void __xor_eor3_2(unsigned long bytes, unsigned long * __restrict p1,
> + const unsigned long * __restrict p2);
Does the alias magic prevent this from being in a header? If so a comment
would be nice, otherwise moving it to a header would be even better.
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Christoph Hellwig @ 2026-04-23 7:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-17-ardb+git@google.com>
On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> arm_neon.h is a compiler header which needs some scaffolding to work
> correctly in the linux context, and so it is better not to include it
> directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
> takes care of this.
This could potentially clash with the raid6 library rework I'm doing
for 7.2. Although git has become pretty good about renamed files, so
maybe it won't be so bad.
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: mediatek: Convert mtk-btcvsd-snd to DT Schema
From: Krzysztof Kozlowski @ 2026-04-23 7:48 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-sound, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260421193858.347258-1-l.scorcia@gmail.com>
On Tue, Apr 21, 2026 at 08:38:35PM +0100, Luca Leonardo Scorcia wrote:
> +title: Mediatek ALSA BT SCO CVSD/MSBC Driver
s/Driver//
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +properties:
> + compatible:
> + const: mediatek,mtk-btcvsd-snd
> +
> + reg:
> + minItems: 2
Drop
> + maxItems: 2
and actually drop this too and list the items with description - PKV and
SRAM_BANK2 regions
> +
> + reg-names:
> + items:
> + - const: pkv
> + - const: sram-bank2
Old binding did not have reg-names and nothing in commit msg explains
changes done to the binding.
To remind: if you change the binding, you must mention it and explain
WHY.
I don't see any use of that, so why did you add it?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Ard Biesheuvel @ 2026-04-23 7:48 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Russell King,
Arnd Bergmann, Eric Biggers
In-Reply-To: <20260423074614.GB31018@lst.de>
On Thu, 23 Apr 2026, at 09:46, Christoph Hellwig wrote:
>> +extern void __xor_eor3_2(unsigned long bytes, unsigned long * __restrict p1,
>> + const unsigned long * __restrict p2);
>
> Does the alias magic prevent this from being in a header?
Yes, it emits the ELF symbol for the alias, and this is only permitted
in the compilation unit that defines the original.
> If so a comment
> would be nice, otherwise moving it to a header would be even better.
Ack.
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-23 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]
> Do not wake every netdev TX queue across all ports sharing the QDMA
> running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
> but only the ones that are mapped the specific QDMA stopped hw TX queue.
> This patch can potentially avoid waking already stopped netdev TX queues
> that are mapped to a different QDMA hw TX queue.
> Introduce airoha_qdma_get_txq utility routine.
>
> Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..2ca569501045 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
> {
> struct airoha_qdma *qdma = q->qdma;
> struct airoha_eth *eth = qdma->eth;
> - int i;
> + int i, qid = q - &qdma->q_tx[0];
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
>
> - if (port && port->qdma == qdma)
> - netif_tx_wake_all_queues(port->dev);
> + if (port->qdma != qdma)
> + continue;
> +
> + for (j = 0; j < port->dev->num_tx_queues; j++) {
> + if (airoha_qdma_get_txq(qdma, j) != qid)
> + continue;
> +
> + netif_wake_subqueue(port->dev, j);
> + }
> }
> q->txq_stopped = false;
> }
> @@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u16 index;
> u8 fport;
>
> - qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
> + qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
> tag = airoha_get_dsa_tag(skb, dev);
>
> msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 87b328cfefb0..c3ea7aadbd82 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
> #define airoha_qdma_clear(qdma, offset, val) \
> airoha_rmw((qdma)->regs, (offset), (val), 0)
>
> +static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
> +{
> + return qid % ARRAY_SIZE(qdma->q_tx);
> +}
> +
> static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
> {
> /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53%40kernel.org
- Can this cause an infinite NETDEV_TX_BUSY livelock when a QDMA hardware queue is full?
The issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Ard Biesheuvel @ 2026-04-23 7:55 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-3-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> implementation was incorrectly copying data starting from the
> count byte, leading to offset data and truncated entropy.
>
> Additionally, the chip requires significant execution time to
> generate random numbers, going by the datasheet. Reading the I2C bus
> too early results in the chip NACK-ing or returning a partial buffer
> followed by zeros.
>
> Verification:
> Tests before showed repeadetly reading only 8 bytes of entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After this patch applied, the result will be as follows:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fix these issues by:
> Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> hardware response. Eventually, correct the memcpy() offset to index 1 of
> the data buffer to skip the count byte and retrieve exactly 32 bytes of
> entropy.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 19720bdd446d..f7dc00d0f4cd 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,9 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +#define ATMEL_RNG_BLOCK_SIZE 32
> +#define ATMEL_RNG_EXEC_TIME 30
> +
> static void atmel_sha204a_rng_done(struct atmel_i2c_work_data
> *work_data,
> void *areq, int status)
> {
> @@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng
> *rng, void *data, size_t max,
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> atmel_i2c_init_random_cmd(&cmd);
> + cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + cmd.rxsize = RANDOM_RSP_SIZE;
>
Please fix atmel_i2c_init_random_cmd() instead if it doesn't set the right
values for these fields. But afaict, you are decreasing the execution time
here, so I struggle to see how this could explain the improved behavior.
> ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
>
This looks correct - better to put this in a separate patch.
> return max;
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic
From: Ard Biesheuvel @ 2026-04-23 7:56 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-4-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The non-blocking path was (also) failing to provide valid entropy
> due to improper buffer management and a lack of hardware execution
> time.
>
> Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
> enqueuing the background work. Fix the data offset to skip the
> 1-byte hardware count header when copying bits to the caller. Correctly
> return 0 (busy) to the hwrng core while hardware execution is in
> progress, preventing zero-filled buffers, which was the situation
> before.
>
> With this fix applied, tests will look similar to this:
> $ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
> 00000000 23 cc 42 3c 90 b1 38 fc 54 37 35 4b 09 c5 e1 0d
> |#.B<..8.T75K....|
> 2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource
> temporarily unavailable
> 00000010 73 3b af d9 02 70 76 bd 2d 59 4b 12 01 ac ae 2b
> |s;...pv.-YK....+|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index f7dc00d0f4cd..04cbf80c1411 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -33,7 +33,6 @@ static void atmel_sha204a_rng_done(struct
> atmel_i2c_work_data *work_data,
> "i2c transaction failed (%d)\n",
> status);
> kfree(work_data);
> - rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return;
> }
> @@ -49,20 +48,19 @@ static int
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> - /* Verify if data available from last run */
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
>
Please combine this with the buffer size fix in the previous patch.
> - /* Now, free memory */
> + /* Free memory and clear the in-flight flag */
> kfree(work_data);
> rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return max;
> }
>
> - /* When a request is still in-flight but not processed */
> + /* If a request is still in-flight, return 0 (busy) */
> if (atomic_read(&i2c_priv->tfm_count) > 0)
> return 0;
>
> @@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct
> hwrng *rng, void *data,
> work_data->client = i2c_priv->client;
>
> atmel_i2c_init_random_cmd(&work_data->cmd);
> +
> + /* Set the execution time for the RNG command (from datasheet) */
> + work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + work_data->cmd.rxsize = RANDOM_RSP_SIZE;
> +
Again, this is either redundant or wrong.
> atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
>
> + /* Return 0 to indicate 'busy', data will be ready on next call */
> return 0;
> }
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v3 06/11] iommu: Defer __iommu_group_free_device() to be outside group->mutex
From: Baolu Lu @ 2026-04-23 7:55 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Bjorn Helgaas, Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <3f5d229267d1f4d918641bc5b896f54b5c4b7782.1776381841.git.nicolinc@nvidia.com>
On 4/17/26 07:28, Nicolin Chen wrote:
> __iommu_group_remove_device() holds group->mutex across the entire call to
> __iommu_group_free_device() that performs sysfs removals, tracing, and the
> final kfree_rcu(). But in fact, most of these operations don't really need
> the group->mutex.
>
> The group_device structure will support a work_struct to quarantine broken
> devices asynchronously. The work function must hold group->mutex to safely
> update group state. cancel_work_sync() must be called, to cancel that work
> before freeing the device. But doing so under group->mutex would deadlock
> if the worker is already running and waiting to acquire the same lock.
>
> Separate the assertion from __iommu_group_free_device() to another helper
> __iommu_group_empty_assert_owner_cnt().
>
> Defer the __iommu_group_free_device() until the mutex is released.
>
> This is a preparatory refactor with no functional change.
>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
> drivers/iommu/iommu.c | 35 +++++++++++++++++++++++------------
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d1be62a07904a..810e7b94a1ae2 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -627,6 +627,19 @@ static struct iommu_domain *pasid_array_entry_to_domain(void *entry)
>
> DEFINE_MUTEX(iommu_probe_device_lock);
>
> +static void __iommu_group_empty_assert_owner_cnt(struct iommu_group *group)
> +{
> + lockdep_assert_held(&group->mutex);
> + /*
> + * If the group has become empty then ownership must have been
> + * released, and the current domain must be set back to NULL or
> + * the default domain.
> + */
Nit: this comment doesn't quite match the following code. The code
doesn't check "group->domain != NULL". Or perhaps in that case,
group->default_domain must be NULL?
Furthermore, if a device is currently quarantined, group->domain will be
the blocking_domain. If that quarantined device is then hot-removed and
happens to be the last device in the group, will this WARN_ON trigger
unnecessarily?
> + if (list_empty(&group->devices))
> + WARN_ON(group->owner_cnt ||
> + group->domain != group->default_domain);
> +}
> +
> static int __iommu_probe_device(struct device *dev, struct list_head *group_list)
> {
> struct iommu_group *group;
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio: drop bitmap_complement() where feasible
From: Bartosz Golaszewski @ 2026-04-23 7:58 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Yury Norov,
linux-gpio, linux-kernel, linux-arm-kernel, Yury Norov
Cc: Bartosz Golaszewski
In-Reply-To: <20260417175955.375275-1-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:59:52 -0400, Yury Norov wrote:
> The gpio drivers reproduce the following pattern:
>
> bitmap_complement(tmp, data1, nbits);
> bitmap_and(dst, data2, tmp, nbits);
>
> This can be done in a single pass:
>
> [...]
Tweaked the grammar in commit messages and applied, thanks!
[1/2] gpio: pca953x: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/a56604e397575647bfc425a8df176948577a364e
[2/2] gpio: xilinx: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/2757a5b1bca76a1b6378496b669a2baf1faddec5
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
From: Marc Zyngier @ 2026-04-23 8:04 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, smostafa, kees, catalin.marinas, Jinjie Ruan,
linux-kernel, mrigendra.chaubey, leitao, will, linux-arm-kernel
In-Reply-To: <ae6f2b57-4644-424e-aab7-84042dca23e6@arm.com>
On Thu, 23 Apr 2026 06:29:09 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
>
> On 20/03/26 1:58 PM, Jinjie Ruan wrote:
> > Add DEFINE_COND_CHECK macro to define the simple __check_* functions
> > to simplify the condition codes check.
> >
> > No functional changes.
> >
> > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> > ---
> > arch/arm64/kernel/traps.c | 59 ++++++++++-----------------------------
> > 1 file changed, 15 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index 914282016069..6216fe9e8e42 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -49,45 +49,21 @@
> > #include <asm/system_misc.h>
> > #include <asm/sysreg.h>
> >
> > -static bool __kprobes __check_eq(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_ne(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_cs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_cc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_mi(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_pl(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_vs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_vc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) == 0;
> > -}
> > +#define DEFINE_COND_CHECK(name, flag, expected) \
> > +static bool __kprobes __check_##name(unsigned long pstate) \
> > +{ \
> > + return ((pstate & (flag)) != 0) == (expected); \
> > +}
> > +
> > +DEFINE_COND_CHECK(eq, PSR_Z_BIT, true)
> > +DEFINE_COND_CHECK(ne, PSR_Z_BIT, false)
> > +DEFINE_COND_CHECK(cs, PSR_C_BIT, true)
> > +DEFINE_COND_CHECK(cc, PSR_C_BIT, false)
> > +DEFINE_COND_CHECK(mi, PSR_N_BIT, true)
> > +DEFINE_COND_CHECK(pl, PSR_N_BIT, false)
> > +DEFINE_COND_CHECK(vs, PSR_V_BIT, true)
> > +DEFINE_COND_CHECK(vc, PSR_V_BIT, false)
> > +DEFINE_COND_CHECK(al, 0, false) /* Always true */
>
> (((pstate & 0 == 0) != 0) == false) ---> return true
>
> Although this looks OK but wondering if __check_al() should
> be left unchanged for simplicity. OR could all its call sites
> be changed assuming an unconditional 'true' return thus later
> __check_al() can be dropped.
Which call site? We emulate an instruction, and we're not in control
of the condition code associated with it. The condition code directly
indexes into aarch32_opcode_cond_checks[].
Anyway, this is a moot point, as we have consensus to not touch that
code at all.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Marc Zyngier @ 2026-04-23 8:08 UTC (permalink / raw)
To: Sebastian Ene
Cc: oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable
In-Reply-To: <aejOu98q1lEZoFfW@google.com>
On Wed, 22 Apr 2026 14:35:55 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> > On Wed, 22 Apr 2026 11:25:40 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header and enforce a strict placement for it
> > > when validating an FF-A memory lend/share transaction.
>
> Hello Marc,
>
> >
> > As I read this, you want to remove a bad assumption...
> >
> > >
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this:
> > >
> > > Field name | Offset
> > > -- 0
> > > [ Header (ffa_mem_region) |__ ep_mem_offset
> > > EMAD 1 (ffa_mem_region_attributes) |
> > > ]
> > >
> > > Reject the host from specifying a memory access descriptor offset
> > > that is different than the size of the memory region header.
> >
> > And yet you decide that you want to enforce this assumption. I don't
> > understand how you arrive to this conclusion.
> >
> > Looking at the spec, it appears that the offset is *designed* to allow
> > a gap between the header and the EMAD. Refusing to handle a it seems to be a
> > violation of the spec.
> >
> > What am I missing?
>
> While the spec allows the gap to be variable (since version 1.1), the
> arm ff-a driver places it at a fixed position in:
> ffa_mem_region_additional_setup()
> https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671
That's an implementation detail, and you shouldn't rely on this.
> and makes use of the same assumption in: ffa_mem_desc_offset().
> https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448
> The later one seems wrong IMO. because we should compute the offset
> based on the value stored in ep_mem_offset and not adding it up with
> sizeof(struct ffa_mem_region).
>
> Maybe this should be the fix instead and not the one in pKVM ? What do
> you think ?
I think you should parse the buffers as the spec intends them, without
assumptions or limitations.
>
> The current implementation in pKVM makes use of the
> ffa_mem_desc_offset() to validate the first EMAD. If a compromised host
> places an EMAD at a different offset than sizeof(struct ffa_mem_region),
> then pKVM will not validate that EMAD.
Why compromised? Isn't that a perfectly valid thing to do? What I
understand is that the FFA 1.1 implementation in pKVM doesn't match
the expectations of the spec. If that's indeed the case, pKVM should
be fixed to accept these messages correctly, or stop using FFA 1.1.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] crypto: ixp4xx: Fix null-pointer dereference in chainup_buffers()
From: Herbert Xu @ 2026-04-23 8:11 UTC (permalink / raw)
To: Ruoyu Wang
Cc: clabbe, linusw, kaloz, davem, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260421093917.1001688-1-ruoyuw560@gmail.com>
On Tue, Apr 21, 2026 at 05:39:17PM +0800, Ruoyu Wang wrote:
> chainup_buffers() builds a linked list of buffer descriptors for a
> scatterlist. If dma_pool_alloc() fails while constructing the list, the
> current code sets buf to NULL and later dereferences it unconditionally
> at the end of the function:
>
> buf->next = NULL;
> buf->phys_next = 0;
>
> This can lead to a null-pointer dereference on allocation failure.
>
> If the failure happens after part of the descriptor chain has already
> been allocated and DMA-mapped, the partially constructed chain also
> needs to be released.
>
> Fix this by unwinding the partially constructed chain, resetting the
> caller-provided hook descriptor, and returning NULL on allocation
> failure.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 24 +++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> index fcc0cf4df637..63ef28cd5766 100644
> --- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> +++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> @@ -874,6 +874,11 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> struct buffer_desc *buf, gfp_t flags,
> enum dma_data_direction dir)
> {
> + struct buffer_desc *first = buf;
> +
> + first->next = NULL;
> + first->phys_next = 0;
> +
> for (; nbytes > 0; sg = sg_next(sg)) {
> unsigned int len = min(nbytes, sg->length);
> struct buffer_desc *next_buf;
> @@ -883,10 +888,15 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> nbytes -= len;
> ptr = sg_virt(sg);
> next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
> - if (!next_buf) {
> - buf = NULL;
> - break;
> - }
> + if (!next_buf)
> + goto err_unwind;
> +
> + /*
> + * Keep the chain well-formed even on partial construction,
> + * so free_buf_chain() can safely unwind it on failure.
> + */
> + next_buf->next = NULL;
> + next_buf->phys_next = 0;
> sg_dma_address(sg) = dma_map_single(dev, ptr, len, dir);
> buf->next = next_buf;
> buf->phys_next = next_buf_phys;
> @@ -899,6 +909,12 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> buf->next = NULL;
> buf->phys_next = 0;
> return buf;
> +
> +err_unwind:
> + free_buf_chain(dev, first->next, first->phys_next);
> + first->next = NULL;
> + first->phys_next = 0;
> + return NULL;
All callers of chainup_buffers try to unwind by calling free_buf_chain
too, although a couple of them might do so incorrectly.
It looks like the callers need the unwind path anyway, so perhaps
just fix up the callers so that their unwind paths actually work?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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