* [PATCH 0/4] firmware: samsung: acpm: Various fixes for sashiko bug reports
From: Tudor Ambarus @ 2026-04-23 14:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
Fixes for bugs that were identified by sashiko when proposing the
GS101 ACPM TMU addition:
https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Tudor Ambarus (4):
firmware: samsung: acpm: Fix cross-thread RX length corruption
firmware: samsung: acpm: Fix sequence number leak and infinite loop
firmware: samsung: acpm: Fix mailbox channel leak on probe error
firmware: samsung: acpm: Fix dummy stubs to return ERR_PTR
drivers/firmware/samsung/exynos-acpm-dvfs.c | 3 ++
drivers/firmware/samsung/exynos-acpm.c | 32 +++++++++++++++-------
.../linux/firmware/samsung/exynos-acpm-protocol.h | 3 +-
3 files changed, 27 insertions(+), 11 deletions(-)
---
base-commit: 2e68039281932e6dc37718a1ea7cbb8e2cda42e6
change-id: 20260423-acpm-fixes-sashiko-reports-ae28b6ed5581
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply
* [PATCH 4/4] firmware: samsung: acpm: Fix dummy stubs to return ERR_PTR
From: Tudor Ambarus @ 2026-04-23 14:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e@linaro.org>
Sashiko identified a potential NULL pointer dereference [1].
The dummy stub implementation for devm_acpm_get_by_node() returns NULL
when CONFIG_EXYNOS_ACPM_PROTOCOL is disabled.
However, the active implementation of this function returns an ERR_PTR
on failure, and the consumer driver checks the return value using
IS_ERR(). Because IS_ERR(NULL) evaluates to false, returning NULL from
the stub tricks consumer drivers into treating the NULL return as a
valid handle. Subsequent attempts to access handle->ops result in a
fatal NULL pointer dereference.
Fix this by returning ERR_PTR(-ENODEV) in the disabled configuration
to correctly propagate the disabled state and match the API contract.
Cc: stable@vger.kernel.org
Fixes: 6837c006d4e7 ("firmware: exynos-acpm: add empty method to allow compile test")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
include/linux/firmware/samsung/exynos-acpm-protocol.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index 13f17dc4443b..d4db2796a6fb 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -8,6 +8,7 @@
#ifndef __EXYNOS_ACPM_PROTOCOL_H
#define __EXYNOS_ACPM_PROTOCOL_H
+#include <linux/err.h>
#include <linux/types.h>
struct acpm_handle;
@@ -57,7 +58,7 @@ struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
static inline struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
struct device_node *np)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
#endif
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 2/4] firmware: samsung: acpm: Fix sequence number leak and infinite loop
From: Tudor Ambarus @ 2026-04-23 14:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e@linaro.org>
Sashiko identified a sequence number leak and a possible infinite loop
[1].
ACPM IPC sequence numbers are tracked via a 64-bit bitmap
(`bitmap_seqnum`) to manage concurrent transactions. A bit is set when
a sequence number is allocated in `acpm_prepare_xfer()`.
Previously, if a transfer timed out during RX polling, or if the
underlying hardware mailbox failed to send the message via
`mbox_send_message()`, the allocated sequence number bit was never
cleared.
As these transient errors accumulate, all 63 available sequence numbers
could eventually be leaked. Once the bitmap is full, the next call to
`acpm_prepare_xfer()` would enter an infinite `while` loop attempting
to find a free sequence number, permanently deadlocking the CPU.
Fix this by ensuring the sequence number bit is explicitly cleared on
all error paths:
1. In `acpm_do_xfer()`, clear the bit if the mailbox transmission
fails.
2. In `acpm_dequeue_by_polling()`, clear the bit if the queue read fails
or if the response times out.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index e95edc350efa..a9baed5762d5 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -311,8 +311,10 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
timeout = ktime_add_us(ktime_get(), ACPM_POLL_TIMEOUT_US);
do {
ret = acpm_get_rx(achan, xfer);
- if (ret)
+ if (ret) {
+ clear_bit(seqnum - 1, achan->bitmap_seqnum);
return ret;
+ }
if (!test_bit(seqnum - 1, achan->bitmap_seqnum))
return 0;
@@ -324,6 +326,8 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n",
achan->id, seqnum, achan->bitmap_seqnum[0]);
+ clear_bit(seqnum - 1, achan->bitmap_seqnum);
+
return -ETIME;
}
@@ -455,8 +459,10 @@ int acpm_do_xfer(struct acpm_handle *handle, const struct acpm_xfer *xfer)
writel(idx, achan->tx.front);
ret = mbox_send_message(achan->chan, (void *)&msg);
- if (ret < 0)
+ if (ret < 0) {
+ clear_bit(achan->seqnum - 1, achan->bitmap_seqnum);
return ret;
+ }
mbox_client_txdone(achan->chan, 0);
}
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 3/4] firmware: samsung: acpm: Fix mailbox channel leak on probe error
From: Tudor Ambarus @ 2026-04-23 14:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, Tudor Ambarus, stable
In-Reply-To: <20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e@linaro.org>
Sashiko identified the leak at [1].
The ACPM driver allocates hardware mailbox channels using
`mbox_request_channel()` during `acpm_channels_init()`. However, the
driver lacked a `.remove` callback and did not free these channels on
subsequent error paths inside `acpm_probe()`.
Consequently, if a later step in the probe function failed (e.g.,
`platform_device_register_data()` returning an error), the mailbox
channels were permanently leaked. This prevented the driver from ever
successfully re-probing on a transient `-EPROBE_DEFER`.
Fix this by modifying `acpm_free_mbox_chans()` to match the `devres`
action signature and wrapping it with `devm_add_action_or_reset()`.
This hooks the channel cleanup directly into the device's managed
resource lifecycle, ensuring the channels are properly freed on probe
failures or driver unbind.
Cc: stable@vger.kernel.org
Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver")
Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index a9baed5762d5..896fbdc2700e 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -535,8 +535,9 @@ static int acpm_achan_alloc_cmds(struct acpm_chan *achan)
* acpm_free_mbox_chans() - free mailbox channels.
* @acpm: pointer to driver data.
*/
-static void acpm_free_mbox_chans(struct acpm_info *acpm)
+static void acpm_free_mbox_chans(void *data)
{
+ struct acpm_info *acpm = data;
int i;
for (i = 0; i < acpm->num_chans; i++)
@@ -658,6 +659,10 @@ static int acpm_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = devm_add_action_or_reset(dev, acpm_free_mbox_chans, acpm);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add mbox free action.\n");
+
acpm_setup_ops(acpm);
platform_set_drvdata(pdev, acpm);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH v10 01/11] drm/fourcc: Add warning for bad bpp
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
drm_format_info_bpp() cannot be used for formats which do not have an
integer bits-per-pixel in a pixel block.
E.g. DRM_FORMAT_P030's plane 0 has three 10-bit pixels (Y components),
and two padding bits, in a 4 byte block. That is 10.666... bits per
pixel when considering the whole 4 byte block, which is what
drm_format_info_bpp() does. Thus a driver that supports such formats
cannot use drm_format_info_bpp(),
It is a driver bug if this happens, but so handle wrong calls by
printing a warning and returning 0.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index e0d533611040..e662aea9d105 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -491,12 +491,20 @@ EXPORT_SYMBOL(drm_format_info_block_height);
*/
unsigned int drm_format_info_bpp(const struct drm_format_info *info, int plane)
{
+ unsigned int block_size;
+
if (!info || plane < 0 || plane >= info->num_planes)
return 0;
- return info->char_per_block[plane] * 8 /
- (drm_format_info_block_width(info, plane) *
- drm_format_info_block_height(info, plane));
+ block_size = drm_format_info_block_width(info, plane) *
+ drm_format_info_block_height(info, plane);
+
+ if (info->char_per_block[plane] * 8 % block_size) {
+ pr_warn("unable to return an integer bpp\n");
+ return 0;
+ }
+
+ return info->char_per_block[plane] * 8 / block_size;
}
EXPORT_SYMBOL(drm_format_info_bpp);
--
2.43.0
^ permalink raw reply related
* [PATCH v10 02/11] drm/fourcc: Add DRM_FORMAT_P230
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen,
Dmitry Baryshkov
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add a new pixel format, DRM_FORMAT_P230 ("P230")
P230 is 2 plane 10 bit per component YCbCr 2x1 subsampled format. P230
is similar to the already existing P030 format, which is 2x2 subsampled.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8 ++++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index e662aea9d105..5b6d8f4686c4 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -354,6 +354,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P030, .depth = 0, .num_planes = 2,
.char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 },
.hsub = 2, .vsub = 2, .is_yuv = true},
+ { .format = DRM_FORMAT_P230, .depth = 0, .num_planes = 2,
+ .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 },
+ .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_S010, .depth = 0, .num_planes = 3,
.char_per_block = { 2, 2, 2 }, .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 },
.hsub = 2, .vsub = 2, .is_yuv = true},
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index c89aede3cb12..0f2f79542121 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -379,6 +379,14 @@ extern "C" {
*/
#define DRM_FORMAT_P030 fourcc_code('P', '0', '3', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel packed */
+/*
+ * 2 plane YCbCr422.
+ * 3 10 bit components and 2 padding bits packed into 4 bytes.
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
+ * index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0 [2:10:10:10:2:10:10:10] little endian
+ */
+#define DRM_FORMAT_P230 fourcc_code('P', '2', '3', '0') /* 2x1 subsampled Cr:Cb plane 10 bits per channel packed */
+
/* 3 plane non-subsampled (444) YCbCr
* 16 bits per component, but only 10 bits are used and 6 bits are padded
* index 0: Y plane, [15:0] Y:x [10:6] little endian
--
2.43.0
^ permalink raw reply related
* [PATCH v10 04/11] drm/fourcc: Add DRM_FORMAT_XYYY2101010
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen, Pekka Paalanen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add XYYY2101010 ("YPA4"), a 10 bit greyscale format, with 3 pixels
packed into 32-bit container, and two bits of padding.
The fourcc for the format is 'YPA4', which comes from Y - Y only, P -
packed, A - 10 (as in 0xA), 4 - 4 bytes.
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index c30266b8d051..01761c553e7e 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -385,6 +385,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_S416, .depth = 0, .num_planes = 3,
.char_per_block = { 2, 2, 2 }, .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 },
.hsub = 1, .vsub = 1, .is_yuv = true},
+ { .format = DRM_FORMAT_XYYY2101010, .depth = 0, .num_planes = 1,
+ .char_per_block = { 4, 0, 0 }, .block_w = { 3, 0, 0 }, .block_h = { 1, 0, 0 },
+ .hsub = 1, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index c5b64ed3b00a..472f95632640 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -468,6 +468,7 @@ extern "C" {
*/
#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8-bit Y-only */
+#define DRM_FORMAT_XYYY2101010 fourcc_code('Y', 'P', 'A', '4') /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
/*
* Format Modifiers:
--
2.43.0
^ permalink raw reply related
* [PATCH v10 03/11] drm/fourcc: Add DRM_FORMAT_Y8
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen, Pekka Paalanen,
Dmitry Baryshkov
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add greyscale Y8 format.
The 8-bit greyscale format has been discussed before, and the earlier
guidance was to use DRM_FORMAT_R8, as a single-channel 8-bit pixel.
However, adding DRM_FORMAT_Y8 makes sense, we can mark it as 'is_yuv' in
the drm_format_info, and this can help the drivers handle e.g.
full/limited range. This will distinguish two single-channel formats:
R8, which is a RGB format with the same value for all components, and
Y8, which is a Y-only YCbCr format, with Cb and Cr being neutral.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5b6d8f4686c4..c30266b8d051 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -275,6 +275,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_YVU422, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_YUV444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_YVU444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y8, .depth = 8, .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_NV12, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_NV21, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_NV16, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0f2f79542121..c5b64ed3b00a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -459,6 +459,15 @@ extern "C" {
#define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
+/*
+ * Y-only (greyscale) formats
+ *
+ * The Y-only formats are handled similarly to the YCbCr formats in the display
+ * pipeline, with the Cb and Cr implicitly neutral (0.0 in nominal values). This
+ * also means that COLOR_RANGE property applies to the Y-only formats.
+ */
+
+#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8-bit Y-only */
/*
* Format Modifiers:
--
2.43.0
^ permalink raw reply related
* [PATCH v10 00/11] drm: Add new pixel formats for Xilinx Zynqmp
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen, Pekka Paalanen,
Dmitry Baryshkov
Add new DRM pixel formats and add support for those in the Xilinx zynqmp
display driver.
All other formats except XVUY2101010 are already supported in upstream
gstreamer, but gstreamer's kmssink does not have the support yet, as it
obviously cannot support the formats without kernel having the formats.
Xilinx has support for these formats in their BSP kernel, and Xilinx has
a branch here, adding the support to gstreamer kmssink:
https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5
New formats added:
DRM_FORMAT_Y8
- 8-bit Y-only
- fourcc: "GREY"
- gstreamer: GRAY8
DRM_FORMAT_XYYY2101010
- 10-bit Y-only, three pixels packed into 32-bits
- fourcc: "YPA4"
- gstreamer: GRAY10_LE32
DRM_FORMAT_P230
- Like NV16, but with 10-bit components
- fourcc: "P230"
- gstreamer: NV16_10LE32
DRM_FORMAT_T430
- 10-bit planar 4:4:4, with three samples packed into 32-bits
- fourcc: "T430"
- gstreamer: Y444_10LE32
XVUY2101010
- 10-bit 4:4:4, one pixel in 32 bits
- fourcc: "XY30"
Some notes:
I know the 8-bit greyscale format has been discussed before, and the
guidance was to use DRM_FORMAT_R8. While I'm not totally against that, I
would argue that adding DRM_FORMAT_Y8 makes sense, as:
1) We can mark it as 'is_yuv' in the drm_format_info, and this can help
the drivers handle e.g. full/limited range. Probably some hardware
handles grayscale as a value used for all RGB components, in which case
R8 makes sense, but when the hardware handles the Y-only pixels as YCbCr,
where Cb and Cr are "neutral", it makes more sense to consider the
format as an YUV format rather than RGB.
2) We can have the same fourcc as in v4l2. While not strictly necessary,
it's a constant source of confusion when the fourccs differ.
3) It (possibly) makes more sense for the user to use Y8/GREY format
instead of R8, as, in my experience, the documentation usually refers
to gray(scale) format or Y-only format.
I have made some adjustments to the formats compared to the Xilinx's
branch. E.g. The DRM_FORMAT_XYYY2101010 format in Xilinx's kmssink uses
fourcc "Y10 ", and DRM_FORMAT_Y10. I didn't like those, as the format is
a packed format, three 10-bit pixels in a 32-bit container, and I think
Y10 means a 10-bit pixel in a 16-bit container. Xilinx also has
XV15/XV20 formats, of which XV15 already exists in the kernel as P030,
and XV20 is added here as P230.
Generally speaking, if someone has good ideas for the format define
names or fourccs, speak up, as it's not easy to invent good names =).
That said, keeping them the same as in the Xilinx trees will, of course,
be slightly easier for the users of Xilinx platforms.
Note: Earlier versions of the series had DRM_FORMAT_Y10_P32, which is
now DRM_FORMAT_XYYY2101010, DRM_FORMAT_XV15, which is now removed as
P030 already exists. DRM_FORMAT_P230 used to be DRM_FORMAT_XV20, and
DRM_FORMAT_T430 used to be DRM_FORMAT_X403.
[1] https://lore.kernel.org/all/20250109150310.219442-26-tzimmermann%40suse.de/
[2] git@github.com:tomba/kmsxx.git xilinx
[3] git@github.com:tomba/pykms.git xilinx
[4] git@github.com:tomba/pixutils.git xilinx
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Changes in v10:
- Rename DRM_FORMAT_XV20 to DRM_FORMAT_P230 to be aligned with DRM_FORMAT_P030
- Rename DRM_FORMAT_X403 to DRM_FORMAT_T430
- Link to v9: https://lore.kernel.org/r/20260325-xilinx-formats-v9-0-d03b7e3752e4@ideasonboard.com
Changes in v9:
- Drop DRM_FORMAT_XV15 as DRM_FORMAT_P030 already exists
- Rename DRM_FORMAT_Y10_P32 to DRM_FORMAT_XYYY2101010
- I kept the Reviewed-bys related to the above, although one could say
renaming the format names is a substantial change. Ping me if you want
me to drop the Rb and re-send.
- Link to v8: https://lore.kernel.org/r/20260128-xilinx-formats-v8-0-9ea8adb70269@ideasonboard.com
Changes in v8:
- Expand the "drm/fourcc: Add DRM_FORMAT_Y8" commit description to
explain the rationale
- Add comment to "drm: xlnx: zynqmp: Add support for Y8 and Y10_P32"
explainig the Y-only matrix
- Remove extra blank line
- Link to v7: https://lore.kernel.org/r/20251201-xilinx-formats-v7-0-1e1558adfefc@ideasonboard.com
Changes in v7:
- Added Reviewed-bys
- Rebased on v6.18
- Link to v6: https://lore.kernel.org/r/20251001-xilinx-formats-v6-0-014b076b542a@ideasonboard.com
Changes in v6:
- Added tags for reviews
- Rebased on v6.17
- Link to v5: https://lore.kernel.org/r/20250425-xilinx-formats-v5-0-c74263231630@ideasonboard.com
Changes in v5:
- Add comment about Y-only formats, clarifying how the display pipeline
handles them (they're handled as YCbCr, with Cb and Cr as "neutral")
- Clarify X403 format in the patch description
- Set unused Y-only CSC offsets to 0 (instead of 0x1800).
- Add R-bs
- Link to v4: https://lore.kernel.org/r/20250326-xilinx-formats-v4-0-322a300c6d72@ideasonboard.com
Changes in v4:
- Reformat the drm_format_info entries a bit
- Calculate block size only once in drm_format_info_bpp()
- Declare local variables in separate lines
- Add review tags
- Fix commit message referring to Y10_LE32 (should be Y10_P32)
- Link to v3: https://lore.kernel.org/r/20250212-xilinx-formats-v3-0-90d0fe106995@ideasonboard.com
Changes in v3:
- Drop "drm: xlnx: zynqmp: Fix max dma segment size". It is already
pushed.
- Add XVUY2101010 format.
- Rename DRM_FORMAT_Y10_LE32 to DRM_FORMAT_Y10_P32.
- Link to v2: https://lore.kernel.org/r/20250115-xilinx-formats-v2-0-160327ca652a@ideasonboard.com
Changes in v2:
- I noticed V4L2 already has fourcc Y10P, referring to MIPI-style packed
Y10 format. So I changed Y10_LE32 fourcc to YPA4. If logic has any
relevance here, P means packed, A means 10, 4 means "in 4 bytes".
- Added tags to "Fix max dma segment size" patch
- Updated description for "Add warning for bad bpp"
- Link to v1: https://lore.kernel.org/r/20241204-xilinx-formats-v1-0-0bf2c5147db1@ideasonboard.com
---
Tomi Valkeinen (11):
drm/fourcc: Add warning for bad bpp
drm/fourcc: Add DRM_FORMAT_P230
drm/fourcc: Add DRM_FORMAT_Y8
drm/fourcc: Add DRM_FORMAT_XYYY2101010
drm/fourcc: Add DRM_FORMAT_T430
drm/fourcc: Add DRM_FORMAT_XVUY2101010
drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes
drm: xlnx: zynqmp: Add support for P030 & P230
drm: xlnx: zynqmp: Add support for Y8 and XYYY2101010
drm: xlnx: zynqmp: Add support for T430
drm: xlnx: zynqmp: Add support for XVUY2101010
drivers/gpu/drm/drm_fourcc.c | 25 +++++++++++++++--
drivers/gpu/drm/xlnx/zynqmp_disp.c | 56 +++++++++++++++++++++++++++++++++++---
include/uapi/drm/drm_fourcc.h | 28 +++++++++++++++++++
3 files changed, 102 insertions(+), 7 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20241120-xilinx-formats-f71901621833
Best regards,
--
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
^ permalink raw reply
* [PATCH v10 05/11] drm/fourcc: Add DRM_FORMAT_T430
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add T430, a 3 plane 10 bits per component non-subsampled YCbCr format.
A new initial letter was chosen for this one, as the format doesn't
match the existing P, Q or S formats. T is the next one in the alphabet.
It was definitely not chosen because of the initial letter in the
author's name.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 9 +++++++++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 01761c553e7e..20b84efc135e 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -388,6 +388,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_XYYY2101010, .depth = 0, .num_planes = 1,
.char_per_block = { 4, 0, 0 }, .block_w = { 3, 0, 0 }, .block_h = { 1, 0, 0 },
.hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_T430, .depth = 0, .num_planes = 3,
+ .char_per_block = { 4, 4, 4 }, .block_w = { 3, 3, 3 }, .block_h = { 1, 1, 1 },
+ .hsub = 1, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 472f95632640..07bfbc8a0300 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -403,6 +403,15 @@ extern "C" {
*/
#define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1')
+/*
+ * 3 plane non-subsampled (444) YCbCr LSB aligned
+ * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
+ * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
+ * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
+ * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
+ */
+#define DRM_FORMAT_T430 fourcc_code('T', '4', '3', '0')
+
/*
* 3 plane YCbCr LSB aligned
* In order to use these formats in a similar fashion to MSB aligned ones
--
2.43.0
^ permalink raw reply related
* [PATCH v10 07/11] drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Use drm helpers, drm_format_info_plane_width(),
drm_format_info_plane_height() and drm_format_info_min_pitch() to
calculate sizes for the DMA.
This cleans up the code, but also makes it possible to support more
complex formats (like P030, P230).
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 9a8f38230cb4..12a8d643915f 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1116,16 +1116,19 @@ int zynqmp_disp_layer_update(struct zynqmp_disp_layer *layer,
return 0;
for (i = 0; i < info->num_planes; i++) {
- unsigned int width = state->crtc_w / (i ? info->hsub : 1);
- unsigned int height = state->crtc_h / (i ? info->vsub : 1);
struct zynqmp_disp_layer_dma *dma = &layer->dmas[i];
struct dma_async_tx_descriptor *desc;
dma_addr_t dma_addr;
+ unsigned int width;
+ unsigned int height;
+
+ width = drm_format_info_plane_width(info, state->crtc_w, i);
+ height = drm_format_info_plane_height(info, state->crtc_h, i);
dma_addr = drm_fb_dma_get_gem_addr(state->fb, state, i);
dma->xt.numf = height;
- dma->sgl.size = width * info->cpp[i];
+ dma->sgl.size = drm_format_info_min_pitch(info, i, width);
dma->sgl.icg = state->fb->pitches[i] - dma->sgl.size;
dma->xt.src_start = dma_addr;
dma->xt.frame_size = 1;
--
2.43.0
^ permalink raw reply related
* [PATCH v10 08/11] drm: xlnx: zynqmp: Add support for P030 & P230
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add support for P030 & P230 formats.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 12a8d643915f..46ea70fd37ec 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -297,6 +297,16 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
.buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420,
.swap = true,
.sf = scaling_factors_888,
+ }, {
+ .drm_fmt = DRM_FORMAT_P030,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420_10,
+ .swap = false,
+ .sf = scaling_factors_101010,
+ }, {
+ .drm_fmt = DRM_FORMAT_P230,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
+ .swap = false,
+ .sf = scaling_factors_101010,
},
};
--
2.43.0
^ permalink raw reply related
* [PATCH v10 06/11] drm/fourcc: Add DRM_FORMAT_XVUY2101010
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add XVUY2101010, a 10 bits per component YCbCr format in a 32 bit
container.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 20b84efc135e..60cd02b7ea64 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -288,6 +288,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV8888, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VUY888, .depth = 0, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_XVUY2101010, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, .is_yuv = true },
{ .format = DRM_FORMAT_Y210, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y212, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 07bfbc8a0300..d95638105520 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -264,6 +264,7 @@ extern "C" {
#define DRM_FORMAT_XVUY8888 fourcc_code('X', 'V', 'U', 'Y') /* [31:0] X:Cr:Cb:Y 8:8:8:8 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0] Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed by U then V, 10:10:10. Non-linear modifier only */
+#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'Y', '3', '0') /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
/*
* packed Y2xx indicate for each component, xx valid data occupy msb
--
2.43.0
^ permalink raw reply related
* [PATCH v10 09/11] drm: xlnx: zynqmp: Add support for Y8 and XYYY2101010
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add support for Y8 and XYYY2101010 formats. We also need to add new csc
matrices for these y-only formats.
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 46ea70fd37ec..175ae1589018 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -307,6 +307,16 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
.buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
.swap = false,
.sf = scaling_factors_101010,
+ }, {
+ .drm_fmt = DRM_FORMAT_Y8,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MONO,
+ .swap = false,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt = DRM_FORMAT_XYYY2101010,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YONLY_10,
+ .swap = false,
+ .sf = scaling_factors_101010,
},
};
@@ -697,6 +707,17 @@ static const u32 csc_sdtv_to_rgb_offsets[] = {
0x0, 0x1800, 0x1800
};
+/* In Y-only mode the single Y channel is on the third column */
+static const u16 csc_sdtv_to_rgb_yonly_matrix[] = {
+ 0x0, 0x0, 0x1000,
+ 0x0, 0x0, 0x1000,
+ 0x0, 0x0, 0x1000,
+};
+
+static const u32 csc_sdtv_to_rgb_yonly_offsets[] = {
+ 0x0, 0x0, 0x0
+};
+
/**
* zynqmp_disp_blend_set_output_format - Set the output format of the blender
* @disp: Display controller
@@ -846,7 +867,11 @@ static void zynqmp_disp_blend_layer_enable(struct zynqmp_disp *disp,
ZYNQMP_DISP_V_BLEND_LAYER_CONTROL(layer->id),
val);
- if (layer->drm_fmt->is_yuv) {
+ if (layer->drm_fmt->format == DRM_FORMAT_Y8 ||
+ layer->drm_fmt->format == DRM_FORMAT_XYYY2101010) {
+ coeffs = csc_sdtv_to_rgb_yonly_matrix;
+ offsets = csc_sdtv_to_rgb_yonly_offsets;
+ } else if (layer->drm_fmt->is_yuv) {
coeffs = csc_sdtv_to_rgb_matrix;
offsets = csc_sdtv_to_rgb_offsets;
} else {
--
2.43.0
^ permalink raw reply related
* [PATCH v10 11/11] drm: xlnx: zynqmp: Add support for XVUY2101010
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add support for XVUY2101010 format.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 2e07e97c1540..52a0712e39c4 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -322,6 +322,11 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
.buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV24_10,
.swap = false,
.sf = scaling_factors_101010,
+ }, {
+ .drm_fmt = DRM_FORMAT_XVUY2101010,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YUV444_10,
+ .swap = false,
+ .sf = scaling_factors_101010,
},
};
--
2.43.0
^ permalink raw reply related
* [PATCH v10 10/11] drm: xlnx: zynqmp: Add support for T430
From: Tomi Valkeinen @ 2026-04-23 14:21 UTC (permalink / raw)
To: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, Simon Ser
Cc: dri-devel, linux-kernel, linux-arm-kernel, Geert Uytterhoeven,
Dmitry Baryshkov, Pekka Paalanen, Tomi Valkeinen
In-Reply-To: <20260423-xilinx-formats-v10-0-c690c2b8ea89@ideasonboard.com>
Add support for T430 format.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Vishal Sagar <vishal.sagar@amd.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 175ae1589018..2e07e97c1540 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -317,6 +317,11 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
.buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YONLY_10,
.swap = false,
.sf = scaling_factors_101010,
+ }, {
+ .drm_fmt = DRM_FORMAT_T430,
+ .buf_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV24_10,
+ .swap = false,
+ .sf = scaling_factors_101010,
},
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Jason Gunthorpe @ 2026-04-23 14:23 UTC (permalink / raw)
To: Will Deacon
Cc: Evangelos Petrongonas, Robin Murphy, Joerg Roedel, Nicolin Chen,
Pranjal Shrivastava, Lu Baolu, linux-arm-kernel, iommu,
linux-kernel, nh-open-source, Zeev Zilberman
In-Reply-To: <aenqxasLJ8yKYqbT@willie-the-truck>
On Thu, Apr 23, 2026 at 10:47:49AM +0100, Will Deacon wrote:
> On Thu, Apr 23, 2026 at 10:44:08AM +0100, Will Deacon wrote:
> > On Wed, Apr 22, 2026 at 01:23:51PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 22, 2026 at 06:44:31AM +0000, Evangelos Petrongonas wrote:
> > > > The motivation is live update of the hypervisor: we want to kexec into a
> > > > new kernel while keeping DMA from passthrough devices flowing, which
> > > > means the SMMU's translation state has to survive the handover. The Live
> > > > Update Orchestrator work [1] and the in-progress "iommu: Add live
> > > > update state preservation" series [2] are building exactly this plumbing
> > > > on top of KHO; [2]'s cover letter calls out Arm SMMUv3 support as future
> > > > work, and an earlier RFC from Amazon [3] sketched the same idea for
> > > > iommufd.
> > >
> > > It would be appropriate to keep this patch with the rest of that out
> > > of tree pile, for example in the series that enables s2 only support
> > > in smmuv3.
> > >
> > > > For this use case, Stage 2 is materially easier to persist than Stage 1,
> > > > for structural rather than performance reasons:
> > >
> > > I don't think so. The driver needs to know each and every STE that
> > > will survive KHO. The ones that don't survive need to be reset to
> > > abort STEs. From that point it is trivial enough to include the CD
> > > memory in the preservation.
> > >
> > > It would help to send a preparation series to switch the ARM STE and
> > > CD logic away from dma_alloc_coherent and use iommu-pages instead,
> > > since we only expect iommu-pages to support preservation..
> >
> > Does iommu-pages provide a mechanism to map the memory as non-cacheable
> > if the SMMU isn't coherent?
No, it has to use CMOs today.
It looks like all the stuff dma_alloc_coherent does to make a
non-cached mapping are pretty arch specific. I don't know if there is
a way we could make more general code get a struct page into an
uncached KVA and meet all the arch rules?
I also think dma_alloc_coherent is far to complex, with pools and
more, to support KHO.
> > I really don't want to entertain CMOs for > the queues.
>
> Sorry, I said "queues" here but I was really referring to any of the
> current dma_alloc_coherent() allocations and it's the CDs that matter
> in this thread.
queues shouldn't change they are too performance sensitive
> The rationale being that:
>
> 1. A cacheable mapping is going to pollute the cache unnecessarily.
> 2. Reasoning about atomicity and ordering is a lot more subtle with CMOs.
The page table suffers from all of these draw backs, and the STE/CD is
touched alot less frequently. It is kind of odd to focus on these
issues with STE/CD when page table is a much bigger problem.
STE/CD is pretty simple now, there is only one place to put the CMO
and the ordering is all handled with that shared code. We no longer
care about ordering beyond all the writes must be visible to HW before
issuing the CMDQ invalidation command - which is the same environment
as the pagetable.
> 3. It seems like a pretty invasive driver change to support live update,
> which isn't relevant for a lot of systems.
That's sort of the whole story of live update.. Trying to keep it
small means using the abstractions that support it like iommu-pages.
IMHO live update is OK to require coherent only, so at worst it could
use iommu-pages on coherent systems and keep using the
dma_alloc_coherent() for others.
I also don't like this "lot of systems thing". I don't want these
powerful capabilities locked up in some giant CSP's proprietary
kernel. I want all the companies in the cloud market to have access
to the same feature set. That's what open source is supposed to be
driving toward. I have several interesting use cases for this
functionality already.
It will run probably $50-100B of AI cloud servers at least, I think
that is enough justification.
Jason
^ permalink raw reply
* 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 14:33 UTC (permalink / raw)
To: Jonathan McDowell
Cc: Mimi Zohar, 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: <aeomlp3I0eVE5mce@earth.li>
Hi Jonathan,
> * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links or attachments. *
> On Thu, Apr 23, 2026 at 02:55:14PM +0100, Yeoreum Yun wrote:
> > > On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> > > > On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > > > > 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()).
> > > > > > >
> > > > > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > > > > backported. No other changes should be included in this patch.
> > > > > >
> > > > > > Okay.
> > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > > > > is a TPM or goes into TPM-bypass mode.
> > > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > > > > and hide it here behind the late_initcall_sync change.
> > > > > >
> > > > > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > > > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > > > > get failed with "TPM-bypass mode".
> > > > > >
> > > > > > I see then, I'll make a patch simpler then.
> > > > >
> > > > > But I think in case of below situation:
> > > > > - late_initcall's first ima_init() is deferred.
> > > > > - late_initcall_sync try again but failed and try again with
> > > > > CONFIG_IMA_DEFAULT_HASH.
> > > > >
> > > > > I would like to sustain init_ima_core to reduce the same code repeat
> > > > > in late_initcall_sync.
> > > >
> > > > I think what Mimi's proposing is:
> > > >
> > > > If we're in late_initcall, and the TPM isn't available, return
> > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > >
> > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > return and nothing, or run through the entire flow, even if the TPM
> > > > isn't unavailable.
> > > >
> > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > and b) for the sync mode, if we've already done the init at
> > > > non-sync.
> > >
> > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
> > > should not be included in this patch. Since Yeoreum is not hearing me, feel
> > > free to post a patch.
> >
> > I see. so what you need to is this only
> > If it looks good to you. I'll send it at v3.
>
> FWIW, I pulled the tpm_default_chip check out a level to account for the
> extra init you mentioned, and have the following (completely untested or
> compiled, but gives the approach):
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index d48bf0ad26f4..88fe105b7f00 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -166,6 +166,7 @@ enum lsm_order {
> * @initcall_fs: LSM callback for fs_initcall setup, optional
> * @initcall_device: LSM callback for device_initcall() setup, optional
> * @initcall_late: LSM callback for late_initcall() setup, optional
> + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> */
> struct lsm_info {
> const struct lsm_id *id;
> @@ -181,6 +182,7 @@ struct lsm_info {
> int (*initcall_fs)(void);
> int (*initcall_device)(void);
> int (*initcall_late)(void);
> + int (*initcall_late_sync)(void);
> };
> #define DEFINE_LSM(lsm) \
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index a2f34f2d8ad7..a60dfb8316d8 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -119,10 +119,6 @@ int __init ima_init(void)
> {
> int rc;
> - ima_tpm_chip = tpm_default_chip();
> - if (!ima_tpm_chip)
> - pr_info("No TPM chip found, activating TPM-bypass!\n");
> -
> rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> if (rc)
> return rc;
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 1d6229b156fb..b60a85fa803a 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
> #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> -static int __init init_ima(void)
> +static int __init init_ima(bool sync)
> {
> int error;
> @@ -1247,6 +1247,19 @@ static int __init init_ima(void)
> return 0;
> }
> + /* If we found the TPM during our first attempt, nothing further to do */
> + if (sync && ima_tpm_chip)
> + return 0;
> +
> + ima_tpm_chip = tpm_default_chip();
> + if (!ima_tpm_chip && !sync) {
> + pr_debug("TPM not available, will try later\n");
> + return -EPROBE_DEFER;
> + }
> +
> + if (!ima_tpm_chip)
> + pr_info("No TPM chip found, activating TPM-bypass!\n");
> +
> ima_appraise_parse_cmdline();
> ima_init_template_list();
> hash_setup(CONFIG_IMA_DEFAULT_HASH);
> @@ -1274,6 +1287,16 @@ static int __init init_ima(void)
> return error;
> }
> +static int __init init_ima_late(void)
> +{
> + return init_ima(false);
> +}
> +
> +static int __init init_ima_late_sync(void)
> +{
> + return init_ima(true);
> +}
> +
> static struct security_hook_list ima_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> @@ -1319,6 +1342,7 @@ DEFINE_LSM(ima) = {
> .init = init_ima_lsm,
> .order = LSM_ORDER_LAST,
> .blobs = &ima_blob_sizes,
> - /* Start IMA after the TPM is available */
> - .initcall_late = init_ima,
> + /* Ensure we start IMA after the TPM is available */
> + .initcall_late = init_ima_late,
> + .initcall_late_sync = init_ima_late_sync,
> };
> diff --git a/security/lsm_init.c b/security/lsm_init.c
> index 573e2a7250c4..4e5c59beb82a 100644
> --- a/security/lsm_init.c
> +++ b/security/lsm_init.c
> @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> * security_initcall_late - Run the LSM late initcalls
> */
> static int __init security_initcall_late(void)
> +{
> + return lsm_initcall(late);
> +}
> +late_initcall(security_initcall_late);
> +
> +/**
> + * security_initcall_late_sync - Run the LSM late initcalls sync
> + */
> +static int __init security_initcall_late_sync(void)
> {
> int rc;
> - rc = lsm_initcall(late);
> + rc = lsm_initcall(late_sync);
> lsm_pr_dbg("all enabled LSMs fully activated\n");
> call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
> return rc;
> }
> -late_initcall(security_initcall_late);
> +late_initcall_sync(security_initcall_late_sync);
I'm fine this. but are we talking about "ima_init()" not "init_ima()"?
Because of this, I've fixuated and make a long stupid speaking myself.
If this seems good to Mimi, I don't care who send it.
But If you're going to send this, could you includes 2 and 3 too?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 14:48 UTC (permalink / raw)
To: Jonathan McDowell, Yeoreum Yun
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: <aeomlp3I0eVE5mce@earth.li>
On Thu, 2026-04-23 at 15:03 +0100, Jonathan McDowell wrote:
> On Thu, Apr 23, 2026 at 02:55:14PM +0100, Yeoreum Yun wrote:
> > > On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> > > > On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > > > > 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()).
> > > > > > >
> > > > > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > > > > backported. No other changes should be included in this patch.
> > > > > >
> > > > > > Okay.
> > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > > > > is a TPM or goes into TPM-bypass mode.
> > > > > > >
> > > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > > > > and hide it here behind the late_initcall_sync change.
> > > > > >
> > > > > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > > > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > > > > get failed with "TPM-bypass mode".
> > > > > >
> > > > > > I see then, I'll make a patch simpler then.
> > > > >
> > > > > But I think in case of below situation:
> > > > > - late_initcall's first ima_init() is deferred.
> > > > > - late_initcall_sync try again but failed and try again with
> > > > > CONFIG_IMA_DEFAULT_HASH.
> > > > >
> > > > > I would like to sustain init_ima_core to reduce the same code repeat
> > > > > in late_initcall_sync.
> > > >
> > > > I think what Mimi's proposing is:
> > > >
> > > > If we're in late_initcall, and the TPM isn't available, return
> > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > >
> > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > return and nothing, or run through the entire flow, even if the TPM
> > > > isn't unavailable.
> > > >
> > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > and b) for the sync mode, if we've already done the init at
> > > > non-sync.
> > >
> > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
> > > should not be included in this patch. Since Yeoreum is not hearing me, feel
> > > free to post a patch.
> >
> > I see. so what you need to is this only
> > If it looks good to you. I'll send it at v3.
>
> FWIW, I pulled the tpm_default_chip check out a level to account for the
> extra init you mentioned, and have the following (completely untested or
> compiled, but gives the approach):
Thanks, Jonathan! It looks good. Similarly untested/compiled.
Emitting a message on failure to initialize IMA at late_initcall is good, but
the attestation service won't know. Could you somehow differentiate between the
late_initcall and late_initcall_sync boot_aggregate records?
Mimi
^ permalink raw reply
* Re: [PATCH v3 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau @ 2026-04-23 15:09 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <7aaa7873-9274-48d8-a6fe-cff4239b03b4@oss.qualcomm.com>
Hi Daniel,
Thanks for your feedback.
On 4/23/26 12:25 PM, Daniel Lezcano wrote:
>
> Hi Ronald,
>
> On 4/21/26 09:19, Ronald Claveau wrote:
>> Some SoCs (e.g. T7) expose thermal calibration data through the secure
>> monitor rather than a directly accessible eFuse register. Add a use_sm
>> flag to amlogic_thermal_data to select this path, and retrieve the
>> firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
>> phandle with one fixed argument.
>>
>> Also introduce the amlogic,t7-thermal compatible using this new path.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> drivers/thermal/amlogic_thermal.c | 58 +++++++++++++++++++++++++++++
>> ++++++----
>> 1 file changed, 53 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/
>> amlogic_thermal.c
>> index 5448d772db12a..11e3948cc0669 100644
>> --- a/drivers/thermal/amlogic_thermal.c
>> +++ b/drivers/thermal/amlogic_thermal.c
>> @@ -25,6 +25,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/regmap.h>
>> #include <linux/thermal.h>
>> +#include <linux/firmware/meson/meson_sm.h>
>> #include "thermal_hwmon.h"
>> @@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
>> * @u_efuse_off: register offset to read fused calibration value
>> * @calibration_parameters: calibration parameters structure pointer
>> * @regmap_config: regmap config for the device
>> + * @use_sm: read data from secure monitor instead of efuse
>> * This structure is required for configuration of amlogic thermal
>> driver.
>> */
>> struct amlogic_thermal_data {
>> int u_efuse_off;
>> const struct amlogic_thermal_soc_calib_data
>> *calibration_parameters;
>> const struct regmap_config *regmap_config;
>> + bool use_sm;
>> };
>> struct amlogic_thermal {
>> @@ -100,6 +103,8 @@ struct amlogic_thermal {
>> struct clk *clk;
>> struct thermal_zone_device *tzd;
>> u32 trim_info;
>> + struct meson_sm_firmware *sm_fw;
>> + u32 tsensor_id;
>> };
>> /*
>> @@ -138,6 +143,12 @@ static int amlogic_thermal_initialize(struct
>> amlogic_thermal *pdata)
>> int ret = 0;
>> int ver;
>> + if (pdata->data->use_sm) {
>> + return meson_sm_get_thermal_calib(pdata->sm_fw,
>> + &pdata->trim_info,
>> + pdata->tsensor_id);
>> + }
>> +
>> regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
>> &pdata->trim_info);
>> @@ -226,6 +237,12 @@ static const struct amlogic_thermal_data
>> amlogic_thermal_a1_cpu_param = {
>> .regmap_config = &amlogic_thermal_regmap_config_g12a,
>> };
>> +static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
>> + .use_sm = true,
>> + .calibration_parameters = &amlogic_thermal_g12a,
>> + .regmap_config = &amlogic_thermal_regmap_config_g12a,
>> +};
>> +
>> static const struct of_device_id of_amlogic_thermal_match[] = {
>> {
>> .compatible = "amlogic,g12a-ddr-thermal",
>> @@ -239,6 +256,10 @@ static const struct of_device_id
>> of_amlogic_thermal_match[] = {
>> .compatible = "amlogic,a1-cpu-thermal",
>> .data = &amlogic_thermal_a1_cpu_param,
>> },
>> + {
>> + .compatible = "amlogic,t7-thermal",
>> + .data = &amlogic_thermal_t7_param,
>> + },
>> { /* sentinel */ }
>> };
>> MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
>> @@ -271,11 +292,38 @@ static int amlogic_thermal_probe(struct
>> platform_device *pdev)
>> if (IS_ERR(pdata->clk))
>> return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to
>> get clock\n");
>> - pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
>> - (pdev->dev.of_node, "amlogic,ao-secure");
>> - if (IS_ERR(pdata->sec_ao_map)) {
>> - dev_err(dev, "syscon regmap lookup failed.\n");
>> - return PTR_ERR(pdata->sec_ao_map);
>> + if (pdata->data->use_sm) {
>> + struct device_node *sm_np;
>> + struct of_phandle_args ph_args;
>> +
>> + ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
>> + "amlogic,secure-monitor",
>> + 1, 0, &ph_args);
>> + if (ret)
>> + return ret;
>> +
>> + sm_np = ph_args.np;
>> + if (!sm_np) {
>> + dev_err(dev,
>> + "Failed to parse secure monitor phandle\n");
>> + return -ENODEV;
>> + }
>> +
>> + pdata->sm_fw = meson_sm_get(sm_np);
>> + of_node_put(sm_np);
>> + if (!pdata->sm_fw) {
>> + dev_err(dev, "Failed to get secure monitor firmware\n");
>> + return -EPROBE_DEFER;
>> + }
>> +
>> + pdata->tsensor_id = ph_args.args[0];
>> + } else {
>> + pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
>> + (pdev->dev.of_node, "amlogic,ao-secure");
>> + if (IS_ERR(pdata->sec_ao_map)) {
>> + dev_err(dev, "syscon regmap lookup failed.\n");
>> + return PTR_ERR(pdata->sec_ao_map);
>> + }
>> }
>
> I suggest to separate these two routines into functions. That will help
> the readability.
>
Sure, I will do that.
>> pdata->tzd = devm_thermal_of_zone_register(&pdev->dev
>
> The thermal zone is registered before calling
> amlogic_thermal_initialize(), thus pdata->trim_info is not initialized.
> When a thermal zone is registered the thermal framework reads the
> temperature, so it reads an invalid value because:
>
> devm_thermal_of_zone_register()
> -> thermal_of_zone_register()
> -> thermal_zone_device_register_with_trips()
> -> thermal_zone_device_enable()
> -> __thermal_zone_device_update()
> -> __thermal_zone_get_temp()
> -> amlogic_thermal_get_temp()
> -> amlogic_thermal_code_to_millicelsius()
> [ Use of uninitialized pdata->trim_info ]
>
> Right ?
>
Yes, I will move the initialize before the register.
> IIUC, amlogic_thermal_initialize() can be also split and moved the
> corresponding blocks to the functions to be created in the comment above.
>
The SM and syscon setup will be extracted into two functions.
amlogic_thermal_initialize() itself is kept as-is but moved before
devm_thermal_of_zone_register().
Let me know if you'd prefer a different approach.
>
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Shah, Tanmay @ 2026-04-23 15:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, Tanmay Shah
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260423-stimulating-markhor-of-masquerade-aac0a7@quoll>
Hello,
Thanks for reviews. Please see my comments below.
On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>> Add auto-boot property to notify that remote processor is setup and
>> ready to boot. Linux can attempt to boot or attach to already running
>> remote processor. "firmware-name" property is used to mention default
>> firmware to boot when linux starts the remote processor.
>>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> index ee63c03949c9..0d27260e3baa 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>> @@ -135,6 +135,14 @@ patternProperties:
>> - description: vring1
>> additionalItems: true
>>
>> + auto-boot:
>
> Last months, I have been asking AMD to follow writing-bindings doc or
> other DT guidelines way too many times.
>
> Or you just sent us downstream... Do you see anywhere such property?
> What properties do you see? How are they named?
>
I should have put note about this. Current auto-boot properties are
named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
there. Can we have a common auto-boot property? Similar to
firmware-name? If we agree to it then what's the correct location? New
file remoteproc.yaml is okay?
>> + type: boolean
>> + description: remote core is either already running or ready to boot
>
> And why is this property of a board?
>
Not sure what indicates it is? The property is under remoteproc child
device that is SOC level property. Remote core is on same SOC wher linux
core is running.
>> +
>> + firmware-name:
>> + maxItems: 1
>> + description: default firmware to load
>
> Can you load non-default firmware later? IOW, why adding description
> here, what is special?
>
The rootfs contains other firmware demos, and it is possible to stop the
default firmware, load other fw elf and re-run the remote core.
I don't have strong preference on the description part, I will remove it
if redundant.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Daniel Lezcano @ 2026-04-23 15:17 UTC (permalink / raw)
To: Ronald Claveau
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <19d70883-21db-4963-841d-7c00505e0d9e@aliel.fr>
On 4/23/26 17:09, Ronald Claveau wrote:
> Hi Daniel,
>
> Thanks for your feedback.
>
> On 4/23/26 12:25 PM, Daniel Lezcano wrote:
>>
>> Hi Ronald,
>>
function1() {
>>> + if (pdata->data->use_sm) {
>>> + struct device_node *sm_np;
>>> + struct of_phandle_args ph_args;
>>> +
>>> + ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
>>> + "amlogic,secure-monitor",
>>> + 1, 0, &ph_args);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + sm_np = ph_args.np;
>>> + if (!sm_np) {
>>> + dev_err(dev,
>>> + "Failed to parse secure monitor phandle\n");
>>> + return -ENODEV;
>>> + }
>>> +
>>> + pdata->sm_fw = meson_sm_get(sm_np);
>>> + of_node_put(sm_np);
>>> + if (!pdata->sm_fw) {
>>> + dev_err(dev, "Failed to get secure monitor firmware\n");
>>> + return -EPROBE_DEFER;
>>> + }
>>> +
>>> + pdata->tsensor_id = ph_args.args[0];
>>> + }
}
function2() {
else {
>>> + pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
>>> + (pdev->dev.of_node, "amlogic,ao-secure");
>>> + if (IS_ERR(pdata->sec_ao_map)) {
>>> + dev_err(dev, "syscon regmap lookup failed.\n");
>>> + return PTR_ERR(pdata->sec_ao_map);
>>> + }
>>> }
}
> Sure, I will do that.
>
>>> pdata->tzd = devm_thermal_of_zone_register(&pdev->dev
>>
>> The thermal zone is registered before calling
>> amlogic_thermal_initialize(), thus pdata->trim_info is not initialized.
>> When a thermal zone is registered the thermal framework reads the
>> temperature, so it reads an invalid value because:
>>
>> devm_thermal_of_zone_register()
>> -> thermal_of_zone_register()
>> -> thermal_zone_device_register_with_trips()
>> -> thermal_zone_device_enable()
>> -> __thermal_zone_device_update()
>> -> __thermal_zone_get_temp()
>> -> amlogic_thermal_get_temp()
>> -> amlogic_thermal_code_to_millicelsius()
>> [ Use of uninitialized pdata->trim_info ]
>>
>> Right ?
>>
>
> Yes, I will move the initialize before the register.
>
>> IIUC, amlogic_thermal_initialize() can be also split and moved the
>> corresponding blocks to the functions to be created in the comment above.
>>
>
> The SM and syscon setup will be extracted into two functions.
> amlogic_thermal_initialize() itself is kept as-is but moved before
> devm_thermal_of_zone_register().
> Let me know if you'd prefer a different approach.
In the initialize function the following chunk is added:
+ if (pdata->data->use_sm) {
+ return meson_sm_get_thermal_calib(pdata->sm_fw,
+ &pdata->trim_info,
+ pdata->tsensor_id);
+ }
I was suggesting to move it to function1() and the rest of code from
initialize in function2()
That results in amlogic_thermal_initialize() to be dissolved in
function1() and function2()
^ permalink raw reply
* Re: [PATCH net-next v12 2/4] arm64: dts: s32: set Ethernet channel irqs
From: Jared Kangas @ 2026-04-23 15:20 UTC (permalink / raw)
To: jan.petrous
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Chester Lin,
Matthias Brugger, Ghennadi Procopciuc, NXP S32 Linux Team,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li, netdev,
linux-stm32, linux-arm-kernel, linux-kernel, imx, devicetree,
rmk+kernel, vladimir.oltean, boon.khai.ng
In-Reply-To: <20260313-dwmac_multi_irq-v12-2-b5c9d0aa13d6@oss.nxp.com>
On Fri, Mar 13, 2026 at 08:13:33AM +0100, Jan Petrous via B4 Relay wrote:
> From: "Jan Petrous (OSS)" <jan.petrous@oss.nxp.com>
>
> The GMAC Ethernet controller found on S32G2/S32G3 and S32R45
> contains up to 5 RX and 5 TX channels.
> It can operate in two interrupt modes:
>
> 1) Sharing IRQ mode: only MAC IRQ line is used
> for all channels.
>
> 2) Multiple IRQ mode: every channel uses two IRQ lines,
> one for RX and second for TX.
>
> Specify all IRQ twins for all channels.
>
> Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> Signed-off-by: Jan Petrous (OSS) <jan.petrous@oss.nxp.com>
> ---
I missed that there was a net-next rebase and ended up sending a T-b to
v11 instead of here ([1], [2]), sorry about that.
To give more details on my testing around this specific patch since the
driver patch was merged: I configured RX queues 1-4 with
'snps,route-multi-broad' across several different boots and verified
that interrupts showed for all TX/RX channels in /proc/interrupts.
Tested-by: Jared Kangas <jkangas@redhat.com>
[1]: https://lore.kernel.org/all/aefX7Ajltzt5EqIR@rh-jkangas-kernel/
[2]: https://lore.kernel.org/all/aefY8WGCuNr4BQG4@rh-jkangas-kernel/
^ permalink raw reply
* [PATCH v2] crypto: testmgr - disallow RSA PKCS#1 SHA-1 sig algs in FIPS mode
From: Jeff Barnes @ 2026-04-23 15:21 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Maxime Coquelin, Alexandre Torgue
Cc: linux-crypto, linux-stm32, linux-arm-kernel, linux-kernel,
Jeff Barnes
When booted with fips=1, RSA signature generation using SHA-1 must not be
available. However, pkcs1pad(rsa,sha1) can currently be instantiated
because it is not present in alg_test_descs; alg_test() falls through the
no_test path and succeeds, after which the algorithm appears in
/proc/crypto as fips-capable.
Add explicit alg_test_descs entries for pkcs1pad(rsa,sha1) and
pkcs1(rsa,sha1) without marking them fips_allowed, so they are treated as
not FIPS-allowed when fips=1 is enabled.
Include both names to cover kernels where RSA sign/verify is provided via
the pkcs1(...) signature template, while pkcs1pad(...) remains for the
traditional wrapper naming and/or RSAES operations.
Signed-off-by: Jeff Barnes <jeffbarnes@linux.microsoft.com>
---
This series fixes an issue where SHA-1 RSA signature generation remains
available when booted with fips=1.
On a FIPS-enabled system, pkcs1pad(rsa,sha1) can be instantiated even
though SHA-1 must not be available for signature generation. The reason
is that the algorithm is not listed in crypto/testmgr.c's alg_test_descs,
so alg_test() falls through the no_test path and succeeds. Once
instantiated, /proc/crypto reports the algorithm as "fips: yes".
This patch adds explicit alg_test_descs entries for:
- pkcs1pad(rsa,sha1)
- pkcs1(rsa,sha1)
without setting fips=1, so they are treated as not FIPS-allowed in
FIPS mode.
Both names are covered to handle kernels where RSA signature operations
are provided via the pkcs1(...) signature template, while pkcs1pad(...)
remains for the historical wrapper naming and/or RSAES operations.
Reproducer / evidence (current behavior):
1) Boot with fips=1 (confirm /proc/sys/crypto/fips_enabled == 1)
2) Allocate the transform:
crypto_alloc_akcipher("pkcs1pad(rsa,sha1)", 0, 0)
3) Observe that /proc/crypto now contains:
name : pkcs1pad(rsa,sha1)
fips : yes
selftest: passed
4) A simple in-kernel demo module can instantiate the transform and reach
the signing path in FIPS mode.
With this change, attempts to instantiate these SHA-1 RSA signing
templates in FIPS mode are rejected, preventing SHA-1 signature
generation in approved mode.
Thanks for taking a look.
---
Changes in v2:
- Rewrap commit message body to conform to 75-column limit
- Fix From/Signed-off-by address mismatch
Link to v1: https://lore.kernel.org/r/20260422-disallow_rsa_sha1_signing_in_fips_mode-v1-1-1359bc7d41be@microsoft.com
---
crypto/testmgr.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 30671e7bc349..e54d298a26c1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5306,6 +5306,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.sig = __VECS(pkcs1_rsa_none_tv_template)
}
+ }, {
+ .alg = "pkcs1(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "pkcs1(rsa,sha224)",
.test = alg_test_null,
@@ -5341,6 +5344,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = "pkcs1pad(rsa)",
.test = alg_test_null,
.fips_allowed = 1,
+ }, {
+ .alg = "pkcs1pad(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "rfc3686(ctr(aes))",
.generic_driver = "rfc3686(ctr(aes-lib))",
---
base-commit: 8879a3c110cb8ca5a69c937643f226697aa551d9
change-id: 20260422-disallow_rsa_sha1_signing_in_fips_mode-8fbb6229ad54
Best regards,
--
Jeff Barnes <jeffbarnes@linux.microsoft.com>
^ permalink raw reply related
* [PATCH v4 00/11] thermal: samsung: Add support for Google GS101 TMU
From: Tudor Ambarus @ 2026-04-23 15:22 UTC (permalink / raw)
To: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Daniel Lezcano, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, Lee Jones
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening,
linux-clk, Tudor Ambarus, Krzysztof Kozlowski
Add support for the Thermal Management Unit (TMU) on the Google GS101
SoC.
The GS101 TMU implementation utilizes a hybrid architecture where
management is shared between the kernel and the Alive Clock and
Power Manager (ACPM) firmware. This hybrid ACPM TMU architecture is
also present on other Samsung Exynos SoCs (e.g., AutoV920, Exynos850).
Dependencies
============
- context dependency on the ACPM fixes sent at:
Link: https://lore.kernel.org/linux-samsung-soc/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e@linaro.org/T/#t
- cleanup and prep firmware patches 2, 3, 4, 5, 6, 7: required by the
thermal driver (patch 8).
- bindings (patch 1): required for DTS validation.
- thermal driver patch 8: required by defconfig (patch 11) - logical
dependency.
Given the thermal driver is a new addition, I suggest everything to go
through the Samsung SoC tree, with ACKs from the Thermal maintainers.
The MFD and clk maintainers are included because of the cleanup patches
(4 and 5). ACPM updated some structures that the mfd and clk client
drivers are using, so these patches shall naturally go via the Samsung
SoC tree.
If the Thermal maintainers prefer to take the bindings and the thermal
driver patches via their tree we'll need:
- an immutable branch containing the firmware patches from the Samsung
SoC tree to serve as a base for the thermal driver.
- an immutable branch containing the bindings and the thermal driver
from the thermal tree to serve as a base for the dts and defconfig.
Architecture Overview
=====================
The hardware supports two parallel control paths. For this
implementation, responsibilities are split as follows:
1. Kernel Responsibility:
- maintain direct memory-mapped access to the interrupt pending
(INTPEND) registers to identify thermal events.
- map physical hardware interrupts to logical thermal zones.
- coordinate functional operations through the ACPM IPC protocol.
2. Firmware Responsibility (ACPM):
- handle sensor initialization.
- manage thermal thresholds configuration.
- perform temperature acquisition and expose data via IPC.
Sensor Mapping (One-to-Many)
============================
The SoC contains multiple physical temperature sensors, but the ACPM
firmware abstracts these into logical groups (Clusters) for reporting:
- ACPM Sensor 0 (Big Cluster): Aggregates physical sensors 0, 6, 7, 8, 9.
- ACPM Sensor 1 (Mid Cluster): Aggregates physical sensors 4, 5.
- ACPM Sensor 2 (Little Cluster): Aggregates physical sensors 1, 2.
The driver maps physical interrupt bits back to these logical parents.
When an interrupt fires, the driver checks the bitmask in the INTPEND
registers and updates the corresponding logical thermal zone.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Changes in v4: address sashiko review:
- thermal driver: avoid mixing mutex cleanup helpers with goto statements
- firmware, tmu:
- remove __packed from union acpm_tmu_msg.
- return ERR_PTR(-ENODEV) for devm_acpm_get_by_phandle when
CONFIG_EXYNOS_ACPM_PROTOCOL is disabled.
- Link to v3: https://lore.kernel.org/r/20260420-acpm-tmu-v3-0-3dc8e93f0b26@linaro.org
Changes in v3:
- thermal driver: use .set_trips() instead of .set_trip_point()
- new cleaning/prerequisite patches for firmware/acpm:
- firmware: samsung: acpm: Make acpm_ops const and access via pointer
- firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
- firmware: samsung: acpm: Consolidate transfer initialization helper
- firmware: acpm: TMU helpers - check return value from the firmware
- overall change: emphasize that the ACPM TMU hibrid approach applies to
other Samsung SoCs as well (Exynos850, AutoV920).
- dts: drop active trip points, update trip point values
- collect R-b tags
- Link to v2: https://lore.kernel.org/r/20260119-acpm-tmu-v2-0-e02a834f04c6@linaro.org
Changes in v2:
- architecture: switch from a syscon/MFD approach to a thermal-sensor
node with a phandle to the ACPM interface
- bindings: address Krzysztof's feedback, drop redundencies,
interrupts description.
- firmware: introduce devm_acpm_get_by_phandle() to standardize IPC
handle acquisition.
- thermal driver: drop compatible's data and use the static data from
the driver directly.
- defconfig, make EXYNOS_ACPM_THERMAL a module
- Link to v1: https://lore.kernel.org/r/20260114-acpm-tmu-v1-0-cfe56d93e90f@linaro.org
---
Tudor Ambarus (11):
dt-bindings: thermal: Add Google GS101 TMU
firmware: samsung: acpm: Consolidate transfer initialization helper
firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
firmware: samsung: acpm: Make acpm_ops const and access via pointer
firmware: samsung: acpm: Add TMU protocol support
firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
thermal: samsung: Add Exynos ACPM TMU driver GS101
MAINTAINERS: Add entry for Samsung Exynos ACPM thermal driver
arm64: dts: exynos: gs101: Add thermal management unit
arm64: defconfig: enable Exynos ACPM thermal support
.../bindings/thermal/google,gs101-tmu-top.yaml | 68 +++
MAINTAINERS | 8 +
arch/arm64/boot/dts/exynos/google/gs101-tmu.dtsi | 136 +++++
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 18 +
arch/arm64/configs/defconfig | 1 +
drivers/clk/samsung/clk-acpm.c | 8 +-
drivers/firmware/samsung/Makefile | 1 +
drivers/firmware/samsung/exynos-acpm-dvfs.c | 20 +-
drivers/firmware/samsung/exynos-acpm-pmic.c | 20 +-
drivers/firmware/samsung/exynos-acpm-tmu.c | 240 +++++++++
drivers/firmware/samsung/exynos-acpm-tmu.h | 28 ++
drivers/firmware/samsung/exynos-acpm.c | 113 +++--
drivers/firmware/samsung/exynos-acpm.h | 2 +
drivers/mfd/sec-acpm.c | 6 +-
drivers/thermal/samsung/Kconfig | 17 +
drivers/thermal/samsung/Makefile | 2 +
drivers/thermal/samsung/acpm-tmu.c | 547 +++++++++++++++++++++
.../linux/firmware/samsung/exynos-acpm-protocol.h | 32 +-
18 files changed, 1195 insertions(+), 72 deletions(-)
---
base-commit: 2e68039281932e6dc37718a1ea7cbb8e2cda42e6
change-id: 20260113-acpm-tmu-27e21f0e2c3b
prerequisite-change-id: 20260423-acpm-fixes-sashiko-reports-ae28b6ed5581:v1
prerequisite-patch-id: 18d89d0e2bc0efe2cb366746ac4db36f4682f061
prerequisite-patch-id: eb4f90add371877a1930c442c5464c4da7242889
prerequisite-patch-id: 021cd1ee6d2b93f554dd5098cd1158977294dc41
prerequisite-patch-id: b5da16b5c6d6731ea519ed68302fd52ce57c7ffa
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ 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