* [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 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 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
* 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
* 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
* [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: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-23 5:55 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <82803bb3b471898a77084c449b73c7f7b4eb2149.camel@linux.ibm.com>
> On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > Hi Mimi,
> > >
> > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > the TPM driver must be built as built-in and
> > > > > must be probed before the IMA subsystem is initialized.
> > > > >
> > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > >
> > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > the CRB interface is probed before IMA initialization,
> > > > > the following conditions must be met:
> > > > >
> > > > > 1. The corresponding ffa_device must be registered,
> > > > > which is done via ffa_init().
> > > > >
> > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > tpm_crb_ffa_init().
> > > > >
> > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > be probed successfully. (See crb_acpi_add() and
> > > > > tpm_crb_ffa_init() for reference.)
> > > > >
> > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > >
> > > > > When this occurs, probing the TPM device is deferred.
> > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > has already been initialized, since IMA initialization is performed
> > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > at the same level.
> > > > >
> > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > log though TPM device presents in the system.
> > > > >
> > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > >
> > > > A lot of change for just detecting whether ima_init() is being called on
> > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > changes (e.g. ima_init_core).
> > > >
> > > > Please just limit the change to just calling ima_init() twice.
> > >
> > > My concern is that ima_update_policy_flags() will be called
> > > when ima_init() is deferred -- not initialised anything.
> > > though functionally, it might be okay however,
> > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > works logically.
> > >
> > > This change I think not much quite a lot. just wrapper ima_init() with
> > > ima_init_core() with some error handling.
> > >
> > > Am I missing something?
> >
> > Also, if we handle in ima_init() only, but it failed with other reason,
> > we shouldn't call again ima_init() in the late_initcall_sync.
> >
> > To handle this, It wouldn't do in the ima_init() but we need to handle
> > it by caller of ima_init().
>
> Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> instead of going into TPM-bypass mode, return immediately. There are no calls
> to anything else. Just call ima_init() a second time.
I’m not fully convinced this is sufficient.
What I meant is the case where ima_init() fails due to other
initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
If it fails at the late_initcall stage for such reasons, then we
should not call ima_init() again at late_initcall_sync.
For this reason, instead of adding a static variable inside
ima_init(), I think it would be better to manage the state in the
caller and introduce something like an ima_initialised flag. Also, if
initialisation fails for other reasons, the notifier block should be
unregistered.
I’d also like to ask again whether it is fine to call
ima_update_policy_flags() and keep the notifier registered in the
deferred TPM case. While this may be functionally acceptable, it seems
logically questionable to do so when ima_init() has not completed.
There is also a possibility that a deferred case ultimately fails (e.g.
deferred at late_initcall, but then failing at late_initcall_sync
for another reason, even while entering TPM bypass mode). In that case,
it seems more appropriate to handle this state in the caller of
ima_init(), rather than inside ima_init() itself.
Am I still missing something?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Dmitry Vyukov @ 2026-04-23 5:53 UTC (permalink / raw)
To: Jinjie Ruan, linux-man
Cc: Thomas Gleixner, Mark Rutland, Mathias Stearn, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Chris Kennelly, regressions, linux-kernel, linux-arm-kernel,
Peter Zijlstra, Ingo Molnar, Blake Oler
In-Reply-To: <c5331cd6-76c8-430d-978e-fcad164e48f6@huawei.com>
On Thu, 23 Apr 2026 at 03:48, Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> On 4/23/2026 3:47 AM, Thomas Gleixner wrote:
> > On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:
> >> On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
> >> Conceptually we just need to use syscall_enter_from_user_mode() and
> >> irqentry_enter_from_user_mode() appropriately.
> >
> > Right. I figured that out.
> >
> >> In practice, I can't use those as-is without introducing the exception
> >> masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
> >> so I'll need to do some similar refactoring first.
> >
> > See below.
> >
> >> I haven't paged everything in yet, so just to cehck, is there anything
> >> that would behave incorrectly if current->rseq.event.user_irq were set
> >> for syscall entry? IIUC it means we'll effectively do the slow path, and
> >> I was wondering if that might be acceptable as a one-line bodge for
> >> stable.
> >
> > It might work, but it's trivial enough to avoid that. See below. That on
> > top of 6.19.y makes the selftests pass too.
>
> This aligns with my thoughts when convert arm64 to generic syscall
> entry. Currently, the arm64 entry code does not distinguish between IRQ
> and syscall entries. It fails to call rseq_note_user_irq_entry() for IRQ
> entries as the generic entry framework does, because arm64 uses
> enter_from_user_mode() exclusively instead of
> irqentry_enter_from_user_mode().
>
> https://lore.kernel.org/all/20260320102620.1336796-10-ruanjinjie@huawei.com/
>
> >
> > Thanks,
> >
> > tglx
> > ---
> > arch/arm64/kernel/entry-common.c | 14 ++++++++++----
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
> > irqentry_exit(regs, state);
> > }
> >
> > +static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
> > +{
> > + enter_from_user_mode(regs);
> > + mte_disable_tco_entry(current);
> > +}
> > +
> > /*
> > * Handle IRQ/context state management when entering from user mode.
> > * Before this function is called it is not safe to call regular kernel code,
> > @@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
> > */
> > static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
> > {
> > - enter_from_user_mode(regs);
> > - mte_disable_tco_entry(current);
> > + arm64_enter_from_user_mode_syscall(regs);
> > + rseq_note_user_irq_entry();
> > }
> >
> > /*
> > @@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_
> >
> > static void noinstr el0_svc(struct pt_regs *regs)
> > {
> > - arm64_enter_from_user_mode(regs);
> > + arm64_enter_from_user_mode_syscall(regs);
> > cortex_a76_erratum_1463225_svc_handler();
> > fpsimd_syscall_enter();
> > local_daif_restore(DAIF_PROCCTX);
> > @@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r
> >
> > static void noinstr el0_svc_compat(struct pt_regs *regs)
> > {
> > - arm64_enter_from_user_mode(regs);
> > + arm64_enter_from_user_mode_syscall(regs);
> > cortex_a76_erratum_1463225_svc_handler();
> > local_daif_restore(DAIF_PROCCTX);
> > do_el0_svc_compat(regs);
+linux-man
This part of the rseq man page needs to be fixed as well I think. The
kernel no longer reliably provides clearing of rseq_cs on preemption,
right?
https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241
"and set to NULL by the kernel when it restarts an assembly
instruction sequence block,
as well as when the kernel detects that it is preempting or delivering
a signal outside of the range targeted by the rseq_cs."
^ permalink raw reply
* Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
From: Anshuman Khandual @ 2026-04-23 5:29 UTC (permalink / raw)
To: Jinjie Ruan, catalin.marinas, will, mark.rutland, kees, maz,
ada.coupriediaz, smostafa, leitao, mrigendra.chaubey,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260320082846.1235016-1-ruanjinjie@huawei.com>
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.
>
> static bool __kprobes __check_hi(unsigned long pstate)
> {
> @@ -131,11 +107,6 @@ static bool __kprobes __check_le(unsigned long pstate)
> return (temp & PSR_N_BIT) != 0;
> }
>
> -static bool __kprobes __check_al(unsigned long pstate)
> -{
> - return true;
> -}
> -
> /*
> * Note that the ARMv8 ARM calls condition code 0b1111 "nv", but states that
> * it behaves identically to 0b1110 ("al").
^ permalink raw reply
* Re: [PATCH v3 01/11] PCI: Propagate FLR return values to callers
From: Nicolin Chen @ 2026-04-23 4:29 UTC (permalink / raw)
To: Baolu Lu
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Jason Gunthorpe, 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: <cbcbea4e-c857-4b75-a55d-ba3f89cdf22d@linux.intel.com>
On Wed, Apr 22, 2026 at 02:13:49PM +0800, Baolu Lu wrote:
> On 4/17/26 07:28, Nicolin Chen wrote:
> > @@ -4060,7 +4061,7 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev, bool probe)
> > PCI_MSIX_FLAGS_ENABLE |
> > PCI_MSIX_FLAGS_MASKALL);
> > - pcie_flr(dev);
> > + ret = pcie_flr(dev);
>
> It makes more sense to return early here on failure. There is no need to
> perform the subsequent steps if pcie_flr() fails. Would something like
> the following work?
[...]
> @@ -4060,7 +4061,9 @@ static int reset_chelsio_generic_dev(struct pci_dev
> *dev, bool probe)
> PCI_MSIX_FLAGS_ENABLE |
> PCI_MSIX_FLAGS_MASKALL);
>
> - pcie_flr(dev);
> + ret = pcie_flr(dev);
> + if (ret)
> + return ret;
Yea, I was a bit worried to change the behavior, skipping the rest
part. But that's probably the right thing to do.
Thanks
Nicolin
^ permalink raw reply
* [PATCH 2/2] ASoC: dt-bindings: drop redundant wakeup-source definitions
From: phucduc.bui @ 2026-04-23 4:28 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Joseph Chen, Chris Zhong, Zhang Qing, David Rau, Animesh Agarwal,
devicetree, linux-sound, linux-rockchip, linux-arm-kernel,
linux-kernel, bui duc phuc
In-Reply-To: <20260423042831.21114-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The 'wakeup-source' property already has its type defined in the core
schema. A number of sound binding files redundantly specify the
'type: boolean' and provide descriptions which only repeat the generic
meaning of the property.
Drop these redundant definitions and descriptions to clean up the binding
files and rely on the core schema instead.
No functional change intended.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/sound/dialog,da7219.yaml | 5 +----
Documentation/devicetree/bindings/sound/realtek,rt5514.yaml | 4 +---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
index 19137abdba3e..fab37cd92e0d 100644
--- a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
+++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
@@ -45,10 +45,7 @@ properties:
- wakeup
- irq
- wakeup-source:
- type: boolean
- description:
- Flag to indicate this device can wake system (suspend/resume).
+ wakeup-source: true
"#clock-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml
index 7fbf7739c371..57e5c09c05c0 100644
--- a/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml
@@ -48,9 +48,7 @@ properties:
spi-max-frequency: true
- wakeup-source:
- type: boolean
- description: Flag to indicate this device can wake system (suspend/resume).
+ wakeup-source: true
required:
- compatible
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: mfd: rockchip: drop redundant wakeup-source definitions
From: phucduc.bui @ 2026-04-23 4:28 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Joseph Chen, Chris Zhong, Zhang Qing, David Rau, Animesh Agarwal,
devicetree, linux-sound, linux-rockchip, linux-arm-kernel,
linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
The 'wakeup-source' property already has its type defined in the core
schema. The Rockchip MFD bindings redundantly specify 'type: boolean'
and provide descriptions which only repeat the generic meaning of the
property. Drop these redundant definitions and descriptions to clean
up the binding files and rely on the core schema instead.
No functional change intended.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml | 5 +----
Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml | 5 +----
Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml | 5 +----
Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml | 5 +----
Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml | 5 +----
5 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
index 7c71447200ba..8e394ab6879b 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk801.yaml
@@ -29,10 +29,7 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
index da2391530c16..548ba1f30712 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
@@ -48,10 +48,7 @@ properties:
system-power-controller: true
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
index 50dfffac8fbf..40f8f23afad3 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
@@ -43,10 +43,7 @@ properties:
system-power-controller: true
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
index 2cb6d176a84c..b99aaff100fb 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
@@ -55,10 +55,7 @@ properties:
system-power-controller: true
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
index 90d944c27ba1..b7af774b1395 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
@@ -43,10 +43,7 @@ properties:
system-power-controller: true
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
+ wakeup-source: true
vcc1-supply:
description:
--
2.43.0
^ permalink raw reply related
* RE: [PATCH v2 2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Chancel Liu @ 2026-04-23 3:11 UTC (permalink / raw)
To: Frank Li
Cc: lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz,
tiwai@suse.com, shengjiu.wang@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, nicoleotsuka@gmail.com,
s.hauer@pengutronix.de, kernel@pengutronix.de,
shumingf@realtek.com, rander.wang@linux.intel.com,
pierre-louis.bossart@linux.dev, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <aeIWLvMWKv6OmX4h@lizhi-Precision-Tower-5810>
> > Some audio systems require specific DAPM widgets to remain powered
> > during system suspend. Introduce a generic and reusable mechanism in
> > the ASoC core to mark selected DAPM widgets as ignore_suspend.
> >
> > The unified mechanism consists of two parts:
> > 1. Parse and store the name list of widgets to ignore suspend in
> > struct snd_soc_card
> >
> > The list of widgets can be provided either by the machine driver or
> > parsed from Device Tree. Different machines have different routing and
> > power requirements. Each machine can specify its own widgets to ignore
> > suspend through DT property. It enables flexible policy without hard
> > code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
> > for this purpose.
> >
> > 2. Apply ignore_suspend flags during snd_soc_bind_card()
> >
> > After all components have been probed and all DAPM widgets have been
> > registered, snd_soc_bind_card() performs a unified lookup of the
> > configured widget names across all DAPM contexts of the card and marks
> > the matching widgets with ignore_suspend = 1.
> >
> > Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> > ---
> ...
> > @@ -3294,6 +3298,45 @@ int snd_soc_of_parse_aux_devs(struct
> > snd_soc_card *card, const char *propname) }
> > EXPORT_SYMBOL_GPL(snd_soc_of_parse_aux_devs);
> >
> > +int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card,
> > + const char *propname)
>
> propname is fixed value "ignore-suspend-widgets"，needn't this agument.
> you funciton include "ignore_suspend_widgets", suppose only parse property.
> ignore_suspend_widgets
>
> Frank
The motivation for keeping the propname argument is to align with
existing snd_soc_of_parse_*() helper prototypes, which always take
(struct snd_soc_card *card, const char *propname).
I agree that in this case the property name is fixed to
"ignore-suspend-widgets". We can simplify the helper by removing it if
preferred.
Regards,
Chancel Liu
^ permalink raw reply
* RE: [PATCH v2 1/3] ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
From: Chancel Liu @ 2026-04-23 3:03 UTC (permalink / raw)
To: Frank Li
Cc: lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz,
tiwai@suse.com, shengjiu.wang@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, nicoleotsuka@gmail.com,
s.hauer@pengutronix.de, kernel@pengutronix.de,
shumingf@realtek.com, rander.wang@linux.intel.com,
pierre-louis.bossart@linux.dev, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <aeITn0SXl-wqgAyA@lizhi-Precision-Tower-5810>
> subject suggest change to
>
> ASoC: dapm: Use snd_soc_dapm_widget_name_cmp() to fix widget lookup
> failures
>
> Frank
OK, this looks more simplified and clearer.
Regards,
Chancel Liu
> > Currently dapm_find_widget() manually constructs a prefixed widget name
> > based on the provided DAPM context and compares it using strcmp(). This
> > happens to work in most cases because callers usually know which DAPM
> > context the target widget belongs to and pass in the matching DAPM
> > context.
> >
> > However, this assumption breaks when search_other_contexts is enabled.
> > In such cases, callers may intentionally pass a different DAPM context,
> > while searching for a widget that actually belongs to another DAPM
> > context.
> >
> > For example, when searching for a "DAC" widget, the widget belongs to
> > the codec DAPM and be registered with a codec prefix, while the caller
> > passes card->dapm and intends to search across all DAPM contexts. The
> > current implementation incorrectly applies the caller card DAPM causing
> > the lookup to fail even though the widget exists on the card.
> >
> > Use snd_soc_dapm_widget_name_cmp() instead, which compares widget
> names
> > using the widget's own DAPM context and prefix. It fixes widget lookup
> > failures when searching across different DAPM contexts on the card.
> >
> > Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking
> widget names")
> > Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> > Assisted-by: Cody:Claude-3.5-Sonnet
> > ---
> > sound/soc/soc-dapm.c | 13 +------------
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
> > index d6192204e613..c5b80d9ed64b 100644
> > --- a/sound/soc/soc-dapm.c
> > +++ b/sound/soc/soc-dapm.c
> > @@ -2906,20 +2906,9 @@ static struct snd_soc_dapm_widget
> *dapm_find_widget(
> > {
> > struct snd_soc_dapm_widget *w;
> > struct snd_soc_dapm_widget *fallback = NULL;
> > - char prefixed_pin[80];
> > - const char *pin_name;
> > - const char *prefix = dapm_prefix(dapm);
> > -
> > - if (prefix) {
> > - snprintf(prefixed_pin, sizeof(prefixed_pin), "%s %s",
> > - prefix, pin);
> > - pin_name = prefixed_pin;
> > - } else {
> > - pin_name = pin;
> > - }
> >
> > for_each_card_widgets(dapm->card, w) {
> > - if (!strcmp(w->name, pin_name)) {
> > + if (!snd_soc_dapm_widget_name_cmp(w, pin)) {
> > if (w->dapm == dapm)
> > return w;
> > else
> > --
> > 2.50.1
> >
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260421-cherubic-urban-beluga-49ee00@quoll>
On 4/21/26 10:02 AM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 01:31:40AM +0200, Marek Vasut wrote:
>> Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>> Cc: Conor Dooley <conor+dt@kernel.org>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: Michael Turquette <mturquette@baylibre.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Stephen Boyd <sboyd@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-clk@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> V2: Add ztr/zt clock at the end of the list to match bindings
>> ---
>> arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
>
>> include/dt-bindings/clock/r8a7740-clock.h | 2 ++
>
> This goes to the binding patch.
>
> Didn't you have also a checkpatch warning?
I only got this warning, but the docs 1/4 and includes 3/4 are a
separate patch in this series:
"
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
"
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260421-attentive-cockle-of-finesse-e5bfb1@quoll>
On 4/21/26 10:01 AM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 01:31:38AM +0200, Marek Vasut wrote:
>> Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>
> This might affect ABI, because you are basically requiring DTS to have
> additional two clocks. Probably it does not affect anyone, but
> technically is an ABI change, so should be explained in commit msg WHY
> you are doing it and what is the impact, instead of saying WHAT you did.
>
> If there is going to be a new version, please fix it and please keep the
> feedback for future commits.
I hope this is addressed in V3.
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Jinjie Ruan @ 2026-04-23 1:48 UTC (permalink / raw)
To: Thomas Gleixner, Mark Rutland
Cc: Mathias Stearn, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Blake Oler
In-Reply-To: <87wlxy22x7.ffs@tglx>
On 4/23/2026 3:47 AM, Thomas Gleixner wrote:
> On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:
>> On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
>> Conceptually we just need to use syscall_enter_from_user_mode() and
>> irqentry_enter_from_user_mode() appropriately.
>
> Right. I figured that out.
>
>> In practice, I can't use those as-is without introducing the exception
>> masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
>> so I'll need to do some similar refactoring first.
>
> See below.
>
>> I haven't paged everything in yet, so just to cehck, is there anything
>> that would behave incorrectly if current->rseq.event.user_irq were set
>> for syscall entry? IIUC it means we'll effectively do the slow path, and
>> I was wondering if that might be acceptable as a one-line bodge for
>> stable.
>
> It might work, but it's trivial enough to avoid that. See below. That on
> top of 6.19.y makes the selftests pass too.
This aligns with my thoughts when convert arm64 to generic syscall
entry. Currently, the arm64 entry code does not distinguish between IRQ
and syscall entries. It fails to call rseq_note_user_irq_entry() for IRQ
entries as the generic entry framework does, because arm64 uses
enter_from_user_mode() exclusively instead of
irqentry_enter_from_user_mode().
https://lore.kernel.org/all/20260320102620.1336796-10-ruanjinjie@huawei.com/
>
> Thanks,
>
> tglx
> ---
> arch/arm64/kernel/entry-common.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
> irqentry_exit(regs, state);
> }
>
> +static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
> +{
> + enter_from_user_mode(regs);
> + mte_disable_tco_entry(current);
> +}
> +
> /*
> * Handle IRQ/context state management when entering from user mode.
> * Before this function is called it is not safe to call regular kernel code,
> @@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
> */
> static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
> {
> - enter_from_user_mode(regs);
> - mte_disable_tco_entry(current);
> + arm64_enter_from_user_mode_syscall(regs);
> + rseq_note_user_irq_entry();
> }
>
> /*
> @@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_
>
> static void noinstr el0_svc(struct pt_regs *regs)
> {
> - arm64_enter_from_user_mode(regs);
> + arm64_enter_from_user_mode_syscall(regs);
> cortex_a76_erratum_1463225_svc_handler();
> fpsimd_syscall_enter();
> local_daif_restore(DAIF_PROCCTX);
> @@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r
>
> static void noinstr el0_svc_compat(struct pt_regs *regs)
> {
> - arm64_enter_from_user_mode(regs);
> + arm64_enter_from_user_mode_syscall(regs);
> cortex_a76_erratum_1463225_svc_handler();
> local_daif_restore(DAIF_PROCCTX);
> do_el0_svc_compat(regs);
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Peng Fan @ 2026-04-23 1:17 UTC (permalink / raw)
To: Sudeep Holla
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Cristian Marussi, linux-kernel, linux-clk,
devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260422-satisfied-rough-mongrel-aabca1@sudeepholla>
On Wed, Apr 22, 2026 at 07:51:03PM +0100, Sudeep Holla wrote:
>On Wed, Apr 22, 2026 at 10:00:23PM +0800, Peng Fan wrote:
>> Hi Sudeep,
>>
>> Thanks for giving a look.
>>
>> On Wed, Apr 22, 2026 at 02:14:56PM +0100, Sudeep Holla wrote:
>> >On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
>> >> From: Peng Fan <peng.fan@nxp.com>
>> >>
>> >> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
>> >> when setting a clock rate. The previously added dt-bindings header
>> >> defines three modes:
>> >>
>> >> ROUND_DOWN / ROUND_UP / ROUND_AUTO
>> >>
>> >> To enable device tree clients to select a rounding mode, extend the
>> >> SCMI clock provider to support "#clock-cells = <2>", where the second
>> >> cell encodes the desired rounding mode. The default remains
>> >> ROUND_DOWN for backwards compatibility with existing device trees.
>> >>
>> >
>> >Where is the binding update documented ? It's not in 1/2.
>>
>> This was missed in this patchset, I will fix in new version, if this
>> patchset does not have big design flaw.
>>
>> >
>> >Also if it can be static in the device tree, why can't it be
>> >autonomously handled in the platform firmware ? I think I know the
>>
>> Linux passes ROUND_DOWN, SCMI firmware uses round down for clk calculation.
>>
>> >answer for this but I want to make sure it is a valid use-case and
>> >gets documented here as part of binding updates.
>>
>> Per info from our video software team.
>> We have some video modes where the best pixel clock rate is slightly above the
>> nominal rate, and the default round down rule (CLOCK_ROUND_RULE_CEILING in SM
>> firmware) can cause the resulting clock rate to be much lower than expected.
>>
>> disp1pix = 96200000 Hz (desired pixel clock rate)
>>
>> The MIPI DPHY cannot hit the exact frequency of 288600000 Hz needed for this
>> pixel clock rate, so the next best DPHY PLL frequency is 289000000 Hz. This
>> corresponds to a pixel clock frequency of 96333333 Hz, which is slightly higher
>> than the nominal rate of 96200000 Hz the video mode specifies.
>>
>> Setting the VIDEOPLL (disp1pix parent) to 289000000 Hz should divide down to
>> the adjusted disp1pix frequency of 96333333 Hz, but here is what happens in the
>> SM firmware:
>>
>> quotient = 289000000 / (96200000 + 1) = 3.004 => 3 (notice that the SM always
>> receives the nominal clock rate, not the adjusted rate)
>>
>> If the rounding rule is round down (CLOCK_ROUND_RULE_CEILING),
>> quotient = quotient + 1. Therefore, quotient becomes 4.
>>
>> disp1pix = 289000000 / 4 = 72250000, which is nowhere close to the target of
>> 96333333.
>>
>
>I do not think this is the correct interpretation of `CLOCK_ROUND_DOWN/UP`.
>
>`CLOCK_ROUND_DOWN/UP` should apply to the requested `disp1pix` rate itself,
>not to the divider choice in a way that forces selection of the next integer
>divisor and produces a much lower output clock.
>
>Here, the requested `disp1pix` is `96,200,000 Hz`, and the parent rate is
>`289,000,000 Hz`. The achievable child rates nearby are:
>
>`289,000,000 / 3 = 96,333,333 Hz`
>`289,000,000 / 4 = 72,250,000 Hz`
>
>Given those options, the firmware should be able to round the request
>autonomously to the nearest supported `disp1pix` rate, which is `96,333,333
>Hz` (`289,000,000 / 3`).
>
>Under that interpretation:
>
>`CLOCK_ROUND_UP` would permit choosing `96,333,333`
>`CLOCK_ROUND_AUTO` would also likely choose `96,333,333`
>Choosing `/4` and ending up at `72,250,000` does not look like a meaningful
>rounding of `96,200,000`
>
>So the issue appears to be that the firmware is applying the rounding rule to
>divider selection rather than to the resulting `disp1pix` frequency.
User requests 96.2 MHz with ROUND_DOWN semantics, expecting the closest
achievable frequency that does not meaningfully deviate from the request.
Firmware evaluates the parent rate of 289,000,000 Hz and computes:
289,000,000 / 3 = 96,333,333 Hz
Since this resulting frequency is slightly higher than the requested
96.2 MHz, the firmware, applying a strict `output <= requested` rule,
rejects divider 3 and selects divider 4 instead, producing:
289,000,000 / 4 = 72,250,000 Hz
This leads to an output frequency that is much farther from the requested
value.
My question is: if the firmware were to select divider 3 and produce
96,333,333 Hz (only ~0.13% higher than the request), would that be
considered a violation of ROUND_DOWN semantics, or is ROUND_DOWN intended
to select the closest achievable output frequency rather than enforcing
a strict inequality against the requested rate?
Thanks,
Peng
>
>> However, if we can use `ROUND_AUTO` the SM firmware would select a quotient of 3
>> in this case, and `disp1pix` would match our target: `289000000 / 3 = 96333333`.
>
>Given the explanation above, I would not support this approach. `ROUND_AUTO`
>should be sufficient for this case if the firmware is making a sensible
>selection.
>
>--
>Regards,
>Sudeep
>
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: renesas: r8a7740: Describe coresight on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Describe coresight topology on R-Mobile A1. Extend the current PTM node
with connection funnel, TPIU, ETB and replicator. The coresight on this
hardware is clocked from the ZT/ZTR trace clock.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: No change
V3: No change
---
arch/arm/boot/dts/renesas/r8a7740.dtsi | 114 ++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index f7136db7a2eae..c7056b96ec0b7 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -18,7 +18,7 @@ / {
cpus {
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x0>;
@@ -59,9 +59,117 @@ pmu {
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
};
- ptm {
- compatible = "arm,coresight-etm3x";
+ replicator {
+ compatible = "arm,coresight-static-replicator";
+ clocks = <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "atclk";
power-domains = <&pd_d4>;
+
+ out-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port@0 {
+ reg = <0>;
+
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etb_in_port>;
+ };
+ };
+ };
+
+ in-ports {
+ /* replicator input port */
+ port {
+ replicator_in_port0: endpoint {
+ remote-endpoint = <&funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etb@e6fa1000 {
+ compatible = "arm,coresight-etb10", "arm,primecell";
+ reg = <0xe6fa1000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ power-domains = <&pd_d4>;
+
+ in-ports {
+ port {
+ etb_in_port: endpoint {
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+ };
+
+ tpiu@e6fa3000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0xe6fa3000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ power-domains = <&pd_d4>;
+
+ in-ports {
+ port {
+ tpiu_in_port: endpoint {
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+ };
+
+ funnel {
+ compatible = "arm,coresight-static-funnel";
+
+ /* funnel output ports */
+ out-ports {
+ port {
+ funnel_out_port: endpoint {
+ remote-endpoint =
+ <&replicator_in_port0>;
+ };
+ };
+ };
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* funnel input ports */
+ port@0 {
+ reg = <0>;
+ funnel0_in_port0: endpoint {
+ remote-endpoint = <&ptm0_out_port>;
+ };
+ };
+ };
+ };
+
+ ptm@e6fbc000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xe6fbc000 0x1000>;
+ clocks = <&cpg_clocks R8A7740_CLK_ZT>, <&cpg_clocks R8A7740_CLK_ZTR>;
+ clock-names = "apb_pclk", "atclk";
+ cpu = <&cpu0>;
+ power-domains = <&pd_d4>;
+
+ out-ports {
+ port {
+ ptm0_out_port: endpoint {
+ remote-endpoint = <&funnel0_in_port0>;
+ };
+ };
+ };
};
ceu0: ceu@fe910000 {
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Add ZT trace bus and ZTR trace clock on the R-Mobile A1.
These clock supply the coresight tracing modules, PTM, TPIU,
ETB and replicator. Without these clock, the coresight tracing
can not be operated.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Add ztr/zt clock at the end of the list to match bindings
V3: Keep only the trace clock DT part here, extend the commit message.
---
arch/arm/boot/dts/renesas/r8a7740.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index d13ab86c3ab47..f7136db7a2eae 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -553,7 +553,7 @@ cpg_clocks: cpg_clocks@e6150000 {
"usb24s",
"i", "zg", "b", "m1", "hp",
"hpp", "usbp", "s", "zb", "m3",
- "cp";
+ "cp", "ztr", "zt";
};
/* Variable factor clocks (DIV6) */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Document ZT trace bus and ZTR trace clock on the R-Mobile A1.
These clock supply the coresight tracing modules, PTM, TPIU,
ETB and replicator. Without these clock, the coresight tracing
can not be operated. While this does change the ABI, it does so
by extending the existing clock-output-names, therefore if an
old software is used with new DT, the coresight tracing parts
will likely fail to probe, otherwise if new software is used
with an old DT, there is no impact.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Reorder new clock at the end to match bindings
V3: - Clarify why this change has to be done and its impact
- Include include/dt-bindings/clock/r8a7740-clock.h change here
- Add RB from Krzysztof
---
.../devicetree/bindings/clock/renesas,cpg-clocks.yaml | 6 ++++--
include/dt-bindings/clock/r8a7740-clock.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
index a0e09b7002f07..925ed35d6658a 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
@@ -41,7 +41,7 @@ properties:
clock-output-names:
minItems: 3
- maxItems: 17
+ maxItems: 19
renesas,mode:
description: Board-specific settings of the MD_CK* bits on R-Mobile A1
@@ -123,6 +123,8 @@ allOf:
- const: zb
- const: m3
- const: cp
+ - const: ztr
+ - const: zt
required:
- renesas,mode
@@ -240,6 +242,6 @@ examples:
#clock-cells = <1>;
clock-output-names = "system", "pllc0", "pllc1", "pllc2", "r",
"usb24s", "i", "zg", "b", "m1", "hp", "hpp",
- "usbp", "s", "zb", "m3", "cp";
+ "usbp", "s", "zb", "m3", "cp", "ztr", "zt";
renesas,mode = <0x05>;
};
diff --git a/include/dt-bindings/clock/r8a7740-clock.h b/include/dt-bindings/clock/r8a7740-clock.h
index 1b3fdb39cc426..8a8816b2ff6ac 100644
--- a/include/dt-bindings/clock/r8a7740-clock.h
+++ b/include/dt-bindings/clock/r8a7740-clock.h
@@ -24,6 +24,8 @@
#define R8A7740_CLK_ZB 14
#define R8A7740_CLK_M3 15
#define R8A7740_CLK_CP 16
+#define R8A7740_CLK_ZTR 17
+#define R8A7740_CLK_ZT 18
/* MSTP1 */
#define R8A7740_CLK_CEU21 28
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] clk: renesas: r8a7740: Implement ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260422233744.149872-1-marek.vasut+renesas@mailbox.org>
Implement ZT trace bus and ZTR trace clock on the R-Mobile A1.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: No change
V3: No change
---
drivers/clk/renesas/clk-r8a7740.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/renesas/clk-r8a7740.c b/drivers/clk/renesas/clk-r8a7740.c
index 635d59ead499e..31a79674583e8 100644
--- a/drivers/clk/renesas/clk-r8a7740.c
+++ b/drivers/clk/renesas/clk-r8a7740.c
@@ -37,6 +37,8 @@ static struct div4_clk div4_clks[] = {
{ "zg", CPG_FRQCRA, 16 },
{ "b", CPG_FRQCRA, 8 },
{ "m1", CPG_FRQCRA, 4 },
+ { "ztr", CPG_FRQCRB, 20 },
+ { "zt", CPG_FRQCRB, 16 },
{ "hp", CPG_FRQCRB, 4 },
{ "hpp", CPG_FRQCRC, 20 },
{ "usbp", CPG_FRQCRC, 16 },
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/4] Describe coresight on R-Mobile A1
From: Marek Vasut @ 2026-04-22 23:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
Implement support for ZT trace bus and ZTR trace clock on R-Mobile A1.
Describe coresight topology on R-Mobile A1. Extend the current PTM node
with connection funnel, TPIU, ETB and replicator. The coresight on this
hardware is clocked from the ZT/ZTR trace clock.
Please note that this is written according to R-Mobile A1 User's Manual:
Hardware , Rev.2.00 Sep. 2013 . I currently do not have access to this
hardware.
Marek Vasut (4):
dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on
R-Mobile A1
clk: renesas: r8a7740: Implement ZT/ZTR trace clock on R-Mobile A1
ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
ARM: dts: renesas: r8a7740: Describe coresight on R-Mobile A1
.../bindings/clock/renesas,cpg-clocks.yaml | 6 +-
arch/arm/boot/dts/renesas/r8a7740.dtsi | 116 +++++++++++++++++-
drivers/clk/renesas/clk-r8a7740.c | 2 +
include/dt-bindings/clock/r8a7740-clock.h | 2 +
4 files changed, 120 insertions(+), 6 deletions(-)
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* Re: [PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping
From: Kevin Hilman @ 2026-04-22 22:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Sudeep Holla, Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Saravana Kannan,
Michael Turquette, Stephen Boyd, Philipp Zabel, Ulf Hansson,
Rafael J . Wysocki, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Geert Uytterhoeven <geert+renesas@glider.be> writes:
> Hi all,
>
> TL;DR:
>
> Describe hardware in DT, and perform the mapping to SCMI in Linux.
>
> The Renesas R-Car X5H-based Ironhide board is the first Renesas
> SoC/board combination that implements the ARM System Control and
> Management Interface (SCMI).
>
> This means Linux can no longer perform various system operations (e.g.
> clock, power domain, and reset control) by accessing the hardware
> directly. Instead, these operations are abstracted according to various
> SCMI sub-protocols, and Linux has to send messages to an SCMI-compliant
> firmware running on a System Control Processor (SCP).
> More specifically, the R-Car X5H SCP FW SCMI controls access to:
> 1. Core clocks and module clocks,
> 2. Module resets,
> 3. Power domains,
I'm very curious how power domain hierarchy is described on this SoC,
because one more issue to add to your list is that hierarchy cannot be
described for power domains in SCMI.
I know you're aware of it already, but just FYI for anyone else
exploring this space, I have a series[1] in-flight right now to address
this limitation of SCMI so that we can at least describe this hierarchy
in DT and the pmdomain framework.
Kevin
[1] https://lore.kernel.org/linux-pm/20260420-topic-lpm-pmdomain-child-ids-v3-0-c2c40bef238c@baylibre.com/
^ permalink raw reply
* [PATCH v13 4/4] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc
From: Shenwei Wang @ 2026-04-22 21:28 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx
In-Reply-To: <20260422212849.1240591-1-shenwei.wang@nxp.com>
Add the RPMSG bus node along with its GPIO subnodes to the device
tree.
Enable remote device communication and GPIO control via RPMSG on
the i.MX platform.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 1de3ad60c6aa..f1b984eb1203 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -190,6 +190,31 @@ scmi_sensor: protocol@15 {
cm33: remoteproc-cm33 {
compatible = "fsl,imx8ulp-cm33";
status = "disabled";
+
+ rpmsg {
+ rpmsg-io {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rpmsg_gpioa: gpio@0 {
+ compatible = "rpmsg-gpio";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ rpmsg_gpiob: gpio@1 {
+ compatible = "rpmsg-gpio";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+ };
+ };
};
soc: soc@0 {
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox