* [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Joey Lu @ 2026-05-11 7:51 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260511075142.54752-1-a0987203069@gmail.com>
The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltra Lite display
controller, which is a previous generation of the DC8000 series. While
the general register layout is similar to the DC8000, there are several
key differences that require per-variant handling in the driver.
Add a vs_dc_info platform data structure (in vs_hwdb.h) to describe
per-IP-variant capabilities, and use it throughout the driver to select
the correct code paths at runtime.
Key differences between DC8000 and DCUltra Lite handled:
1. No chip identity registers (0x0020-0x0030): DCUltra Lite uses static
platform data instead of reading model/revision/customer_id from HW.
2. No CONFIG_EX commit mechanism: DC8000 uses registers at 0x1CC0
(FB_CONFIG_EX), 0x24D8 (FB_TOP_LEFT), 0x24E0 (FB_BOTTOM_RIGHT),
0x2510 (FB_BLEND_CONFIG), 0x2518 (PANEL_CONFIG_EX). DCUltra Lite
omits all of these and instead uses enable/reset bits in FB_CONFIG
(bit 0 = enable, bit 4 = reset) for direct framebuffer updates.
3. No PANEL_START register (0x1CCC): DCUltra Lite panel output starts
when PANEL_CONFIG.RUNNING is set; no separate multi-display sync
start register is needed.
4. Different IRQ registers: DCUltra Lite uses 0x147C (IRQ_STA) /
0x1480 (IRQ_EN); DC8000 uses 0x0010 (IRQ_ACK) / 0x0014 (IRQ_EN).
5. Different clock/reset topology: DCUltra Lite requires only "core"
(bus gate) and "pix0" (pixel divider) clocks with no reset lines
managed by the driver. DC8000 needs core/axi/ahb clocks and three
resets.
6. Single output only: DCUltra Lite has one display output; per-output
index logic is still in place but display_count is fixed at 1.
7. Reduced register space: max_register is 0x2000 vs DC8000's 0x2544.
Add the "nuvoton,ma35d1-dcu" compatible string to the OF match table,
extend Kconfig to allow building on ARCH_MA35 platforms, and expose
vs_formats_no_yuv444 as the default format table for DCUltra Lite
(YUV444 blending is a DC8000-only feature).
All changes have been tested on Nuvoton MA35D1 hardware and are
functioning correctly.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 28 ++--
drivers/gpu/drm/verisilicon/vs_crtc.c | 13 +-
drivers/gpu/drm/verisilicon/vs_dc.c | 129 ++++++++++++------
drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
drivers/gpu/drm/verisilicon/vs_drm.c | 16 ++-
drivers/gpu/drm/verisilicon/vs_hwdb.c | 2 +-
drivers/gpu/drm/verisilicon/vs_hwdb.h | 25 ++++
.../gpu/drm/verisilicon/vs_primary_plane.c | 43 +++---
.../drm/verisilicon/vs_primary_plane_regs.h | 2 +
10 files changed, 187 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/verisilicon/Kconfig b/drivers/gpu/drm/verisilicon/Kconfig
index 7cce86ec8603..295d246eb4b4 100644
--- a/drivers/gpu/drm/verisilicon/Kconfig
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -2,7 +2,7 @@
config DRM_VERISILICON_DC
tristate "DRM Support for Verisilicon DC-series display controllers"
depends on DRM && COMMON_CLK
- depends on RISCV || COMPILE_TEST
+ depends on RISCV || ARCH_MA35 || COMPILE_TEST
select DRM_BRIDGE_CONNECTOR
select DRM_CLIENT_SELECTION
select DRM_DISPLAY_HELPER
diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c b/drivers/gpu/drm/verisilicon/vs_bridge.c
index 7a93049368db..225af322de32 100644
--- a/drivers/gpu/drm/verisilicon/vs_bridge.c
+++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
@@ -164,13 +164,16 @@ static void vs_bridge_enable_common(struct vs_crtc *crtc,
VSDC_DISP_PANEL_CONFIG_CLK_EN);
regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
VSDC_DISP_PANEL_CONFIG_RUNNING);
- regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_RUNNING(output));
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
- VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+ if (dc->info->has_config_ex) {
+ regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_RUNNING(output));
+
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+ }
}
static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
@@ -228,14 +231,17 @@ static void vs_bridge_atomic_disable(struct drm_bridge *bridge,
struct vs_dc *dc = crtc->dc;
unsigned int output = crtc->id;
- regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
- VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
- VSDC_DISP_PANEL_START_RUNNING(output));
regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
VSDC_DISP_PANEL_CONFIG_RUNNING);
- regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
- VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+ if (dc->info->has_config_ex) {
+ regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
+ VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
+ VSDC_DISP_PANEL_START_RUNNING(output));
+
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+ }
}
static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
index 9080344398ca..2f3e6d41c657 100644
--- a/drivers/gpu/drm/verisilicon/vs_crtc.c
+++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
@@ -18,6 +18,7 @@
#include "vs_dc.h"
#include "vs_dc_top_regs.h"
#include "vs_drm.h"
+#include "vs_hwdb.h"
#include "vs_plane.h"
static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -132,7 +133,11 @@ static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN, VSDC_TOP_IRQ_VSYNC(vcrtc->id));
+ if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
+ regmap_write(dc->regs, VSDC_DISP_IRQ_EN, BIT(0));
+ else
+ regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(vcrtc->id));
return 0;
}
@@ -142,7 +147,11 @@ static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
struct vs_dc *dc = vcrtc->dc;
- regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN, VSDC_TOP_IRQ_VSYNC(vcrtc->id));
+ if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
+ regmap_write(dc->regs, VSDC_DISP_IRQ_EN, 0);
+ else
+ regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(vcrtc->id));
}
static const struct drm_crtc_funcs vs_crtc_funcs = {
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
index dad9967bc10b..82a6a26f6d81 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -9,21 +9,45 @@
#include <linux/of_graph.h>
#include "vs_crtc.h"
+#include "vs_crtc_regs.h"
#include "vs_dc.h"
#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#include "vs_hwdb.h"
-static const struct regmap_config vs_dc_regmap_cfg = {
+static const struct regmap_config vs_dc8000_regmap_cfg = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = sizeof(u32),
- /* VSDC_OVL_CONFIG_EX(1) */
.max_register = 0x2544,
};
+static const struct regmap_config vs_dcultra_lite_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x2000,
+};
+
+static const struct vs_dc_info vs_dc8000_info = {
+ .family = VS_DC_FAMILY_DC8000,
+ .has_chip_id = true,
+ .has_config_ex = true,
+ .regmap_cfg = &vs_dc8000_regmap_cfg,
+};
+
+static const struct vs_dc_info vs_dcultra_lite_info = {
+ .family = VS_DC_FAMILY_DCULTRA_LITE,
+ .display_count = 1,
+ .has_chip_id = false,
+ .has_config_ex = false,
+ .regmap_cfg = &vs_dcultra_lite_regmap_cfg,
+ .formats = &vs_formats_no_yuv444,
+};
+
static const struct of_device_id vs_dc_driver_dt_match[] = {
- { .compatible = "verisilicon,dc" },
+ { .compatible = "verisilicon,dc", .data = &vs_dc8000_info },
+ { .compatible = "nuvoton,ma35d1-dcu", .data = &vs_dcultra_lite_info },
{},
};
MODULE_DEVICE_TABLE(of, vs_dc_driver_dt_match);
@@ -33,6 +57,13 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
struct vs_dc *dc = private;
u32 irqs;
+ if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
+ regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
+ if (irqs & BIT(0))
+ vs_drm_handle_irq(dc, VSDC_TOP_IRQ_VSYNC(0));
+ return IRQ_HANDLED;
+ }
+
regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
vs_drm_handle_irq(dc, irqs);
@@ -43,6 +74,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
static int vs_dc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ const struct vs_dc_info *info;
struct vs_dc *dc;
void __iomem *regs;
unsigned int port_count, i;
@@ -55,6 +87,10 @@ static int vs_dc_probe(struct platform_device *pdev)
return -ENODEV;
}
+ info = of_device_get_match_data(dev);
+ if (!info)
+ return -ENODEV;
+
port_count = of_graph_get_port_count(dev->of_node);
if (!port_count) {
dev_err(dev, "can't find DC downstream ports\n");
@@ -75,15 +111,31 @@ static int vs_dc_probe(struct platform_device *pdev)
if (!dc)
return -ENOMEM;
- dc->rsts[0].id = "core";
- dc->rsts[1].id = "axi";
- dc->rsts[2].id = "ahb";
+ dc->info = info;
- ret = devm_reset_control_bulk_get_optional_shared(dev, VSDC_RESET_COUNT,
- dc->rsts);
- if (ret) {
- dev_err(dev, "can't get reset lines\n");
- return ret;
+ if (info->family == VS_DC_FAMILY_DC8000) {
+ dc->rsts[0].id = "core";
+ dc->rsts[1].id = "axi";
+ dc->rsts[2].id = "ahb";
+
+ ret = devm_reset_control_bulk_get_optional_shared(dev,
+ VSDC_RESET_COUNT, dc->rsts);
+ if (ret) {
+ dev_err(dev, "can't get reset lines\n");
+ return ret;
+ }
+
+ dc->axi_clk = devm_clk_get_enabled(dev, "axi");
+ if (IS_ERR(dc->axi_clk)) {
+ dev_err(dev, "can't get axi clock\n");
+ return PTR_ERR(dc->axi_clk);
+ }
+
+ dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
+ if (IS_ERR(dc->ahb_clk)) {
+ dev_err(dev, "can't get ahb clock\n");
+ return PTR_ERR(dc->ahb_clk);
+ }
}
dc->core_clk = devm_clk_get_enabled(dev, "core");
@@ -92,28 +144,18 @@ static int vs_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->core_clk);
}
- dc->axi_clk = devm_clk_get_enabled(dev, "axi");
- if (IS_ERR(dc->axi_clk)) {
- dev_err(dev, "can't get axi clock\n");
- return PTR_ERR(dc->axi_clk);
- }
-
- dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
- if (IS_ERR(dc->ahb_clk)) {
- dev_err(dev, "can't get ahb clock\n");
- return PTR_ERR(dc->ahb_clk);
- }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "can't get irq\n");
return irq;
}
- ret = reset_control_bulk_deassert(VSDC_RESET_COUNT, dc->rsts);
- if (ret) {
- dev_err(dev, "can't deassert reset lines\n");
- return ret;
+ if (info->family == VS_DC_FAMILY_DC8000) {
+ ret = reset_control_bulk_deassert(VSDC_RESET_COUNT, dc->rsts);
+ if (ret) {
+ dev_err(dev, "can't deassert reset lines\n");
+ return ret;
+ }
}
regs = devm_platform_ioremap_resource(pdev, 0);
@@ -123,23 +165,30 @@ static int vs_dc_probe(struct platform_device *pdev)
goto err_rst_assert;
}
- dc->regs = devm_regmap_init_mmio(dev, regs, &vs_dc_regmap_cfg);
+ dc->regs = devm_regmap_init_mmio(dev, regs, info->regmap_cfg);
if (IS_ERR(dc->regs)) {
ret = PTR_ERR(dc->regs);
goto err_rst_assert;
}
- ret = vs_fill_chip_identity(dc->regs, &dc->identity);
- if (ret)
- goto err_rst_assert;
+ if (info->has_chip_id) {
+ ret = vs_fill_chip_identity(dc->regs, &dc->identity);
+ if (ret)
+ goto err_rst_assert;
- dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
- dc->identity.revision, dc->identity.customer_id);
+ dev_info(dev, "Found DC%x rev %x customer %x\n",
+ dc->identity.model, dc->identity.revision,
+ dc->identity.customer_id);
- if (port_count > dc->identity.display_count) {
- dev_err(dev, "too many downstream ports than HW capability\n");
- ret = -EINVAL;
- goto err_rst_assert;
+ if (port_count > dc->identity.display_count) {
+ dev_err(dev, "too many downstream ports than HW capability\n");
+ ret = -EINVAL;
+ goto err_rst_assert;
+ }
+ } else {
+ /* Fill identity from platform data */
+ dc->identity.display_count = info->display_count;
+ dc->identity.formats = info->formats;
}
for (i = 0; i < dc->identity.display_count; i++) {
@@ -168,7 +217,8 @@ static int vs_dc_probe(struct platform_device *pdev)
return 0;
err_rst_assert:
- reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
+ if (info->family == VS_DC_FAMILY_DC8000)
+ reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
return ret;
}
@@ -180,7 +230,8 @@ static void vs_dc_remove(struct platform_device *pdev)
dev_set_drvdata(&pdev->dev, NULL);
- reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
+ if (dc->info->family == VS_DC_FAMILY_DC8000)
+ reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
}
static void vs_dc_shutdown(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h b/drivers/gpu/drm/verisilicon/vs_dc.h
index ed1016f18758..f0613519af37 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.h
+++ b/drivers/gpu/drm/verisilicon/vs_dc.h
@@ -31,6 +31,7 @@ struct vs_dc {
struct clk *pix_clk[VSDC_MAX_OUTPUTS];
struct reset_control_bulk_data rsts[VSDC_RESET_COUNT];
+ const struct vs_dc_info *info;
struct vs_drm_dev *drm_dev;
struct vs_chip_identity identity;
};
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
index fd259d53f49f..ff0fc6673006 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.c
+++ b/drivers/gpu/drm/verisilicon/vs_drm.c
@@ -27,6 +27,7 @@
#include "vs_dc.h"
#include "vs_dc_top_regs.h"
#include "vs_drm.h"
+#include "vs_hwdb.h"
#define DRIVER_NAME "verisilicon"
#define DRIVER_DESC "Verisilicon DC-series display controller driver"
@@ -72,12 +73,19 @@ static struct drm_mode_config_helper_funcs vs_mode_config_helper_funcs = {
.atomic_commit_tail = drm_atomic_helper_commit_tail,
};
-static void vs_mode_config_init(struct drm_device *drm)
+static void vs_mode_config_init(struct drm_device *drm, struct vs_dc *dc)
{
drm->mode_config.min_width = 0;
drm->mode_config.min_height = 0;
- drm->mode_config.max_width = 8192;
- drm->mode_config.max_height = 8192;
+
+ if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
+ drm->mode_config.max_width = 1920;
+ drm->mode_config.max_height = 1080;
+ } else {
+ drm->mode_config.max_width = 8192;
+ drm->mode_config.max_height = 8192;
+ }
+
drm->mode_config.funcs = &vs_mode_config_funcs;
drm->mode_config.helper_private = &vs_mode_config_helper_funcs;
}
@@ -125,7 +133,7 @@ int vs_drm_initialize(struct vs_dc *dc, struct platform_device *pdev)
if (ret)
return ret;
- vs_mode_config_init(drm);
+ vs_mode_config_init(drm, dc);
/* Enable connectors polling */
drm_kms_helper_poll_init(drm);
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
index 09336af0900a..39402d75d841 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
@@ -78,7 +78,7 @@ static const u32 vs_formats_array_with_yuv444[] = {
/* TODO: non-RGB formats */
};
-static const struct vs_formats vs_formats_no_yuv444 = {
+const struct vs_formats vs_formats_no_yuv444 = {
.array = vs_formats_array_no_yuv444,
.num = ARRAY_SIZE(vs_formats_array_no_yuv444)
};
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h b/drivers/gpu/drm/verisilicon/vs_hwdb.h
index 92192e4fa086..655cf93ca3aa 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
@@ -14,6 +14,29 @@ struct vs_formats {
unsigned int num;
};
+enum vs_dc_family {
+ VS_DC_FAMILY_DC8000,
+ VS_DC_FAMILY_DCULTRA_LITE,
+};
+
+/**
+ * struct vs_dc_info - per-SoC DC platform data
+ * @family: DC IP family (DC8000, DCUltra Lite, etc.)
+ * @display_count: number of display outputs (0 = auto-detect from DT/HW)
+ * @has_chip_id: whether chip identity registers exist
+ * @has_config_ex: whether CONFIG_EX commit mechanism exists
+ * @regmap_cfg: regmap configuration for this variant
+ * @formats: supported pixel formats (NULL = auto-detect from chip ID)
+ */
+struct vs_dc_info {
+ enum vs_dc_family family;
+ u32 display_count;
+ bool has_chip_id;
+ bool has_config_ex;
+ const struct regmap_config *regmap_cfg;
+ const struct vs_formats *formats;
+};
+
struct vs_chip_identity {
u32 model;
u32 revision;
@@ -23,6 +46,8 @@ struct vs_chip_identity {
const struct vs_formats *formats;
};
+extern const struct vs_formats vs_formats_no_yuv444;
+
int vs_fill_chip_identity(struct regmap *regs,
struct vs_chip_identity *ident);
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
index 1f2be41ae496..197d5d683e22 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
@@ -55,8 +55,9 @@ static int vs_primary_plane_atomic_check(struct drm_plane *plane,
static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int output)
{
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_COMMIT);
+ if (dc->info->has_config_ex)
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_COMMIT);
}
static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
@@ -69,11 +70,13 @@ static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
unsigned int output = vcrtc->id;
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_FB_EN);
- regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
- VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
+ if (dc->info->has_config_ex) {
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_FB_EN);
+ regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
+ VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
+ }
vs_primary_plane_commit(dc, output);
}
@@ -88,8 +91,9 @@ static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
unsigned int output = vcrtc->id;
struct vs_dc *dc = vcrtc->dc;
- regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
- VSDC_FB_CONFIG_EX_FB_EN);
+ if (dc->info->has_config_ex)
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_FB_EN);
vs_primary_plane_commit(dc, output);
}
@@ -126,6 +130,11 @@ static void vs_primary_plane_atomic_update(struct drm_plane *plane,
VSDC_FB_CONFIG_UV_SWIZZLE_EN,
vs_state->format.uv_swizzle);
+ /* DCUltra Lite requires explicit enable/reset bits in FB_CONFIG */
+ if (!dc->info->has_config_ex)
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_ENABLE | VSDC_FB_CONFIG_RESET);
+
dma_addr = vs_fb_get_dma_addr(fb, &state->src);
regmap_write(dc->regs, VSDC_FB_ADDRESS(output),
@@ -133,16 +142,18 @@ static void vs_primary_plane_atomic_update(struct drm_plane *plane,
regmap_write(dc->regs, VSDC_FB_STRIDE(output),
fb->pitches[0]);
- regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
- VSDC_MAKE_PLANE_POS(state->crtc_x, state->crtc_y));
- regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
- VSDC_MAKE_PLANE_POS(state->crtc_x + state->crtc_w,
- state->crtc_y + state->crtc_h));
regmap_write(dc->regs, VSDC_FB_SIZE(output),
VSDC_MAKE_PLANE_SIZE(state->crtc_w, state->crtc_h));
- regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
- VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
+ if (dc->info->has_config_ex) {
+ regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
+ VSDC_MAKE_PLANE_POS(state->crtc_x, state->crtc_y));
+ regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
+ VSDC_MAKE_PLANE_POS(state->crtc_x + state->crtc_w,
+ state->crtc_y + state->crtc_h));
+ regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
+ VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
+ }
vs_primary_plane_commit(dc, output);
}
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
index cbb125c46b39..288064760b48 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
@@ -16,6 +16,8 @@
#define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
#define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
+#define VSDC_FB_CONFIG_ENABLE BIT(0)
+#define VSDC_FB_CONFIG_RESET BIT(4)
#define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
#define VSDC_FB_CONFIG_ROT_MASK GENMASK(13, 11)
#define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] power: sequencing: print power sequencing device parent in debugfs
From: Bartosz Golaszewski @ 2026-05-11 7:53 UTC (permalink / raw)
To: Bartosz Golaszewski, Chen-Yu Tsai
Cc: Bartosz Golaszewski, linux-pm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260507052943.3133349-1-wenst@chromium.org>
On Thu, 07 May 2026 13:29:41 +0800, Chen-Yu Tsai wrote:
> The debugfs summary currently shows the power sequencing device's name.
> This is not really helpful since the device name is always "pwrseq.N".
>
> Also print the parent device's name. This would likely be the device
> node name from the device tree, something like "nvme-connector". This
> would make it much easier for the developer to associate the summary
> with a certain device.
>
> [...]
Applied, thanks!
[1/1] power: sequencing: print power sequencing device parent in debugfs
https://git.kernel.org/brgl/c/513f49c33e91e58975ada7967b44512179f0e703
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH 1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
From: Marc Zyngier @ 2026-05-11 7:56 UTC (permalink / raw)
To: David Woodhouse
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Paolo Bonzini, Shuah Khan,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kernel, kvm,
linux-kselftest
In-Reply-To: <f17a2d66e47fd15fc738d9f4ad89123a31d86eb3.camel@infradead.org>
On Sun, 10 May 2026 22:28:50 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> On Fri, 2026-04-24 at 13:24 +0100, David Woodhouse wrote:
> > On Fri, 2026-04-24 at 12:07 +0100, Marc Zyngier wrote:
> > > On Tue, 07 Apr 2026 21:27:02 +0100, David Woodhouse wrote:
> > > > The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3
> > > > extract the revision field from 'reg' (the current IIDR value read back
> > > > from the emulated distributor) instead of 'val' (the value userspace is
> > > > trying to write). This means userspace can never actually change the
> > > > implementation revision — the extracted value is always the current one.
> > > >
> > > > Fix the FIELD_GET to use 'val' so that userspace can select a different
> > > > revision for migration compatibility.
> > > >
> > > > [...]
> > >
> > > Applied to fixes, thanks!
> > >
> > > [1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
> > > commit: a0e6ae45af17e8b27958830595799c702ffbab8d
> >
> > There was a v2 of this series which also cleaned up the weird
> > inconsistency of the IIDR value with the actual behaviour, and which
> > fixed the fact that it's currently not possible to maintain guest
> > compatibility when upgrading from a pre-d53c2c29ae0d kernel to a new
> > one — despite the fact that that kind of compatibility is *precisely*
> > what the revision field in the IIDR is designed for.
> >
> > https://lore.kernel.org/all/20260408113256.2095505-1-dwmw2@infradead.org/
>
> Is there a reason the rest of these fixes didn't make 7.1?
I already explained why these changes are neither necessary (a guest
that used to run still runs) nor desirable (reintroducing bugs we have
fixed is a bad idea).
I have therefore only taken the fix for the bug affecting userspace,
as that was definitely something worth fixing.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 08/10] spi: stm32-qspi: Use FIELD_MODIFY()
From: Patrice CHOTARD @ 2026-05-11 7:59 UTC (permalink / raw)
To: Hans Zhang, broonie, sunny.luo, xianwei.zhao, neil.armstrong,
khilman, han.xu, haibo.chen, mcoquelin.stm32, alexandre.torgue,
lhjeff911, hayashi.kunihiko, mhiramat, jbrunet,
martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32
In-Reply-To: <20260430155456.36998-9-18255117159@163.com>
On 4/30/26 17:54, Hans Zhang wrote:
> Use FIELD_MODIFY() to remove open-coded bit manipulation.
> No functional change intended.
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/spi/spi-stm32-qspi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
> index df1bbacec90a..ea69fe25686f 100644
> --- a/drivers/spi/spi-stm32-qspi.c
> +++ b/drivers/spi/spi-stm32-qspi.c
> @@ -374,9 +374,8 @@ static int stm32_qspi_send(struct spi_device *spi, const struct spi_mem_op *op)
> int timeout, err = 0, err_poll_status = 0;
>
> cr = readl_relaxed(qspi->io_base + QSPI_CR);
> - cr &= ~CR_PRESC_MASK & ~CR_FSEL;
> - cr |= FIELD_PREP(CR_PRESC_MASK, flash->presc);
> - cr |= FIELD_PREP(CR_FSEL, flash->cs);
> + FIELD_MODIFY(CR_PRESC_MASK, &cr, flash->presc);
> + FIELD_MODIFY(CR_FSEL, &cr, flash->cs);
> writel_relaxed(cr, qspi->io_base + QSPI_CR);
>
> if (op->data.nbytes)
Hi Hans
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Thanks
Patrice
^ permalink raw reply
* Re: [PATCH 07/10] spi: stm32-ospi: Use FIELD_MODIFY()
From: Patrice CHOTARD @ 2026-05-11 8:00 UTC (permalink / raw)
To: Hans Zhang, broonie, sunny.luo, xianwei.zhao, neil.armstrong,
khilman, han.xu, haibo.chen, mcoquelin.stm32, alexandre.torgue,
lhjeff911, hayashi.kunihiko, mhiramat, jbrunet,
martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32
In-Reply-To: <20260430155456.36998-8-18255117159@163.com>
On 4/30/26 17:54, Hans Zhang wrote:
> Use FIELD_MODIFY() to remove open-coded bit manipulation.
> No functional change intended.
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/spi/spi-stm32-ospi.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-stm32-ospi.c b/drivers/spi/spi-stm32-ospi.c
> index 4461c6e24b9e..3757f6ba8fc6 100644
> --- a/drivers/spi/spi-stm32-ospi.c
> +++ b/drivers/spi/spi-stm32-ospi.c
> @@ -470,10 +470,9 @@ static int stm32_ospi_send(struct spi_device *spi, const struct spi_mem_op *op)
> u8 cs = spi->chip_select[ffs(spi->cs_index_mask) - 1];
>
> cr = readl_relaxed(ospi->regs_base + OSPI_CR);
> - cr &= ~CR_CSSEL;
> - cr |= FIELD_PREP(CR_CSSEL, cs);
> - cr &= ~CR_FMODE_MASK;
> - cr |= FIELD_PREP(CR_FMODE_MASK, ospi->fmode);
> + FIELD_MODIFY(CR_CSSEL, &cr, cs);
> +
> + FIELD_MODIFY(CR_FMODE_MASK, &cr, ospi->fmode);
> writel_relaxed(cr, regs_base + OSPI_CR);
>
> if (op->data.nbytes)
Hi Hans
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Thanks
Patrice
^ permalink raw reply
* Re: [PATCH v14 0/5] Add support for Verisilicon IOMMU used by media codec blocks
From: Jörg Rödel @ 2026-05-11 8:01 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: will, robin.murphy, krzk+dt, conor+dt, heiko, iommu, devicetree,
linux-kernel, linux-arm-kernel, linux-rockchip, kernel
In-Reply-To: <20260415072349.44237-1-benjamin.gaignard@collabora.com>
On Wed, Apr 15, 2026 at 09:23:36AM +0200, Benjamin Gaignard wrote:
> Benjamin Gaignard (5):
> dt-bindings: vendor-prefixes: Add Verisilicon
> dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU
> iommu: Add verisilicon IOMMU driver
> arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588
> arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588
>
> .../bindings/iommu/verisilicon,iommu.yaml | 71 ++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 11 +
> arch/arm64/configs/defconfig | 1 +
> drivers/iommu/Kconfig | 11 +
> drivers/iommu/Makefile | 1 +
> drivers/iommu/vsi-iommu.c | 796 ++++++++++++++++++
> 8 files changed, 901 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/verisilicon,iommu.yaml
> create mode 100644 drivers/iommu/vsi-iommu.c
Applied to the new verisilicon branch.
^ permalink raw reply
* [PATCH] ARM: Do not select HAVE_RUST when KASAN is enabled
From: Nathan Chancellor @ 2026-05-11 8:02 UTC (permalink / raw)
To: Russell King, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Christian Schrrefl
Cc: linux-arm-kernel, linux-kernel, rust-for-linux, stable,
Nathan Chancellor
When KASAN is enabled, such as with allmodconfig, the build fails when
building the Rust code with:
error: kernel-address sanitizer is not supported for this target
error: aborting due to 1 previous error
make[4]: *** [rust/Makefile:654: rust/core.o] Error 1
The arm-unknown-linux-gnueabi target does not support KASAN, so avoid
saying Rust is supported when it is enabled.
Cc: stable@vger.kernel.org
Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7")
Link: https://github.com/Rust-for-Linux/linux/issues/1234
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 71fc5dd4123f..73e6647bea46 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -136,7 +136,7 @@ config ARM
select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RSEQ
- select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7
+ select HAVE_RUST if CPU_LITTLE_ENDIAN && CPU_32v7 && !KASAN
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260511-arm-avoid-rust-with-kasan-7670981ef8b5
Best regards,
--
Cheers,
Nathan
^ permalink raw reply related
* Re: [PATCH v14 0/5] Add support for Verisilicon IOMMU used by media codec blocks
From: Benjamin Gaignard @ 2026-05-11 8:03 UTC (permalink / raw)
To: Jörg Rödel
Cc: will, robin.murphy, krzk+dt, conor+dt, heiko, iommu, devicetree,
linux-kernel, linux-arm-kernel, linux-rockchip, kernel
In-Reply-To: <33nsz23rcstwznq6dnsuibndbwtoc767evshltj35kgysdg63r@fxhwobu53cww>
Le 11/05/2026 à 10:01, Jörg Rödel a écrit :
> On Wed, Apr 15, 2026 at 09:23:36AM +0200, Benjamin Gaignard wrote:
>> Benjamin Gaignard (5):
>> dt-bindings: vendor-prefixes: Add Verisilicon
>> dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU
>> iommu: Add verisilicon IOMMU driver
>> arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588
>> arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588
>>
>> .../bindings/iommu/verisilicon,iommu.yaml | 71 ++
>> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
>> MAINTAINERS | 8 +
>> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 11 +
>> arch/arm64/configs/defconfig | 1 +
>> drivers/iommu/Kconfig | 11 +
>> drivers/iommu/Makefile | 1 +
>> drivers/iommu/vsi-iommu.c | 796 ++++++++++++++++++
>> 8 files changed, 901 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iommu/verisilicon,iommu.yaml
>> create mode 100644 drivers/iommu/vsi-iommu.c
> Applied to the new verisilicon branch.
Thanks a lot.
Regards,
Benjamin
^ permalink raw reply
* Re: [PATCH v4 00/15] SCMI Clock rates discovery rework
From: Sudeep Holla @ 2026-05-11 8:09 UTC (permalink / raw)
To: Cristian Marussi
Cc: Geert Uytterhoeven, linux-kernel, linux-arm-kernel, arm-scmi,
Sudeep Holla, linux-clk, linux-renesas-soc, philip.radford,
james.quinlan, f.fainelli, vincent.guittot, etienne.carriere,
peng.fan, michal.simek, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas
In-Reply-To: <CAMuHMdXyJcmL1k+odRC3ej1fx2oH_Li3RjniXuqXyJUMpBo7CA@mail.gmail.com>
On Fri, May 08, 2026 at 07:25:49PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
>
> On Fri, 8 May 2026 at 17:33, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > it was a known limitation, in the SCMI Clock protocol support, the lack of
> > dynamic allocation around per-clock rates discovery: fixed size statically
> > per-clock rates arrays did not scale and was increasingly a waste of memory
> > (see [1]).
>
> [...]
>
> > v3 -->v4
> > - Rebased on v7.1-rc2
> > - Removed unused info.rate_discrete [Geert]
> > - Made dev_dbg() more meaningful by printing tot_rates [Geert]
> > - Fixed build bisectability by renaming properly to iter_response_bound_cleanup()
>
> Thanks for the update!
>
> I believe you still have a possible runtime bisectability issue
> between "[PATCH v4 04/15] firmware: arm_scmi: Simplify clock
> rates exposed interface" and "[PATCH v4 05/15] clk: scmi: Use new
> simplified per-clock rate properties": 04/15 removes the last setter
> of scmi_clock_info.rate_discrete, before 05/15 removes the last getter.
>
I have fixed this up by adding some initialisation in 04/15 and removing it
in 06/15. Cristian, if possible can you check if the functionality will
remain intact after 05/15 ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: (subset) [PATCH 1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
From: David Woodhouse @ 2026-05-11 8:13 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Paolo Bonzini, Shuah Khan,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kernel, kvm,
linux-kselftest
In-Reply-To: <86ik8uxtue.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
On Mon, 2026-05-11 at 08:56 +0100, Marc Zyngier wrote:
> On Sun, 10 May 2026 22:28:50 +0100,
> David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > [1 <text/plain; UTF-8 (quoted-printable)>]
> > On Fri, 2026-04-24 at 13:24 +0100, David Woodhouse wrote:
> > > On Fri, 2026-04-24 at 12:07 +0100, Marc Zyngier wrote:
> > > > On Tue, 07 Apr 2026 21:27:02 +0100, David Woodhouse wrote:
> > > > > The uaccess write handlers for GICD_IIDR in both GICv2 and GICv3
> > > > > extract the revision field from 'reg' (the current IIDR value read back
> > > > > from the emulated distributor) instead of 'val' (the value userspace is
> > > > > trying to write). This means userspace can never actually change the
> > > > > implementation revision — the extracted value is always the current one.
> > > > >
> > > > > Fix the FIELD_GET to use 'val' so that userspace can select a different
> > > > > revision for migration compatibility.
> > > > >
> > > > > [...]
> > > >
> > > > Applied to fixes, thanks!
> > > >
> > > > [1/3] KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
> > > > commit: a0e6ae45af17e8b27958830595799c702ffbab8d
> > >
> > > There was a v2 of this series which also cleaned up the weird
> > > inconsistency of the IIDR value with the actual behaviour, and which
> > > fixed the fact that it's currently not possible to maintain guest
> > > compatibility when upgrading from a pre-d53c2c29ae0d kernel to a new
> > > one — despite the fact that that kind of compatibility is *precisely*
> > > what the revision field in the IIDR is designed for.
> > >
> > > https://lore.kernel.org/all/20260408113256.2095505-1-dwmw2@infradead.org/
> >
> > Is there a reason the rest of these fixes didn't make 7.1?
>
> I already explained why these changes are neither necessary (a guest
> that used to run still runs) nor desirable (reintroducing bugs we have
> fixed is a bad idea).
>
> I have therefore only taken the fix for the bug affecting userspace,
> as that was definitely something worth fixing.
You claimed that KVM/arm64 does not support migrating guests to older
(or even newer!!) kernels while maintaining compatibility.
That just *isn't* a cogent argument. I responded to it, in
https://lore.kernel.org/all/8cca18f332ea4bfb0c9f9d6775b2c1284816dd5f.camel@infradead.org/
KVM absolutely does need to support upgrading the kernel without
changing the environment that guests see. And sometimes it is sadly
also necessary to roll back an upgrade — which means that guests
launched on the new kernel should not see anything new until the fleet
is past the point where a rollback might happen.
Guest-visible changes need to be optional, in the case of the vGIC that
is exactly what the IIDR is *for*. There's not much point in my patch
that allows it to be *set*, if we don't allow it to be set *to* the
previous versions that are needed.
This isn't exactly rocket science, and I don't know why you claim not
to understand it.
What's going on, Marc? This behaviour isn't OK.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: arria10: Increase JFFS2 rootfs partition size
From: muhammad.nazim.amirul.nazle.asmade @ 2026-05-11 8:15 UTC (permalink / raw)
To: dinguyen, robh, krzk+dt, conor+dt
Cc: devicetree, linux-arm-kernel, linux-kernel
From: Niravkumar L Rabara <niravkumar.l.rabara@altera.com>
Increase the JFFS2 partition size to support larger root filesystem.
Also fix the partition label to match the actual start address.
Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@altera.com>
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
.../arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
index a662df319a84..5f9b98b0b393 100644
--- a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
+++ b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10_socdk_nand.dts
@@ -18,9 +18,9 @@ partition@0 {
label = "Boot and fpga data";
reg = <0x0 0x02500000>;
};
- partition@1c00000 {
+ partition@2500000 {
label = "Root Filesystem - JFFS2";
- reg = <0x02500000 0x05500000>;
+ reg = <0x02500000 0x3db00000>;
};
};
};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v2] coresight: fix missing error code when trace ID is invalid
From: James Clark @ 2026-05-11 8:16 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Suzuki K Poulose,
Mike Leach, Leo Yan, Alexander Shishkin, Tingwei Zhang
In-Reply-To: <20260509-fix-trace-id-error-v2-1-c900bcbab3e9@oss.qualcomm.com>
On 09/05/2026 1:58 am, Jie Gan wrote:
> When coresight_path_assign_trace_id() cannot assign a valid trace ID,
> coresight_enable_sysfs() takes the err_path goto with ret still 0,
> returning success to the caller despite no trace session being started.
>
> Fix this by changing coresight_path_assign_trace_id() to return int.
> Move the IS_VALID_CS_TRACE_ID() check inside the function so it returns
> -EINVAL on failure and 0 on success. Update coresight_enable_sysfs() to
> check the return value directly instead of inspecting path->trace_id
> after the call.
>
> The other caller in coresight-etm-perf.c discards the return value and
> continues to check path->trace_id via IS_VALID_CS_TRACE_ID() directly.
> This is unaffected: on failure path->trace_id is no longer written, so
> it remains 0, which IS_VALID_CS_TRACE_ID() rejects the same as before.
>
> Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Changes in v2:
> - Refactor the coresight_path_assign_trace_id function.
> - Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-v1-1-5f11a5456fdf@oss.qualcomm.com
> ---
> drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++----
> drivers/hwtracing/coresight/coresight-priv.h | 2 +-
> drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
> 3 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 46f247f73cf6..cabdc0c72f38 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -739,12 +739,12 @@ static int coresight_get_trace_id(struct coresight_device *csdev,
> * Call this after creating the path and before enabling it. This leaves
> * the trace ID set on the path, or it remains 0 if it couldn't be assigned.
> */
> -void coresight_path_assign_trace_id(struct coresight_path *path,
> +int coresight_path_assign_trace_id(struct coresight_path *path,
> enum cs_mode mode)
> {
> struct coresight_device *sink = coresight_get_sink(path);
> struct coresight_node *nd;
> - int trace_id;
> + int trace_id, ret = -EINVAL;
>
> list_for_each_entry(nd, &path->path_list, link) {
> /* Assign a trace ID to the path for the first device that wants to do it */
> @@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
> * Non 0 is either success or fail.
> */
> if (trace_id != 0) {
> - path->trace_id = trace_id;
> - return;
> + if (IS_VALID_CS_TRACE_ID(trace_id)) {
> + path->trace_id = trace_id;
> + ret = 0;
Reviewed-by: James Clark <james.clark@linaro.org>
Minor nit, but just "return 0" here is a bit simpler.
> + }
> +
> + return ret;
And then "return -EINVAL" for these ones.
> }
> }
> +
> + return ret; > }
>
> /**
> diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
> index 1ea882dffd70..34c7e792adbd 100644
> --- a/drivers/hwtracing/coresight/coresight-priv.h
> +++ b/drivers/hwtracing/coresight/coresight-priv.h
> @@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device *orig,
> void coresight_remove_links(struct coresight_device *orig,
> struct coresight_connection *conn);
> u32 coresight_get_sink_id(struct coresight_device *csdev);
> -void coresight_path_assign_trace_id(struct coresight_path *path,
> +int coresight_path_assign_trace_id(struct coresight_path *path,
> enum cs_mode mode);
>
> #if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
> diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
> index d2a6ed8bcc74..b6a870399e83 100644
> --- a/drivers/hwtracing/coresight/coresight-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-sysfs.c
> @@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
> goto out;
> }
>
> - coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
> - if (!IS_VALID_CS_TRACE_ID(path->trace_id))
> + ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
> + if (ret)
> goto err_path;
>
> ret = coresight_enable_path(path, CS_MODE_SYSFS);
>
> ---
> base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
> change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v2] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-11 8:19 UTC (permalink / raw)
To: James Clark
Cc: coresight, linux-arm-kernel, linux-kernel, Suzuki K Poulose,
Mike Leach, Leo Yan, Alexander Shishkin, Tingwei Zhang
In-Reply-To: <90d86e62-1116-4daa-b557-fc86c40a0e69@linaro.org>
On 5/11/2026 4:16 PM, James Clark wrote:
>
>
> On 09/05/2026 1:58 am, Jie Gan wrote:
>> When coresight_path_assign_trace_id() cannot assign a valid trace ID,
>> coresight_enable_sysfs() takes the err_path goto with ret still 0,
>> returning success to the caller despite no trace session being started.
>>
>> Fix this by changing coresight_path_assign_trace_id() to return int.
>> Move the IS_VALID_CS_TRACE_ID() check inside the function so it returns
>> -EINVAL on failure and 0 on success. Update coresight_enable_sysfs() to
>> check the return value directly instead of inspecting path->trace_id
>> after the call.
>>
>> The other caller in coresight-etm-perf.c discards the return value and
>> continues to check path->trace_id via IS_VALID_CS_TRACE_ID() directly.
>> This is unaffected: on failure path->trace_id is no longer written, so
>> it remains 0, which IS_VALID_CS_TRACE_ID() rejects the same as before.
>>
>> Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the
>> path")
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Refactor the coresight_path_assign_trace_id function.
>> - Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-
>> v1-1-5f11a5456fdf@oss.qualcomm.com
>> ---
>> drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++----
>> drivers/hwtracing/coresight/coresight-priv.h | 2 +-
>> drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
>> 3 files changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/
>> hwtracing/coresight/coresight-core.c
>> index 46f247f73cf6..cabdc0c72f38 100644
>> --- a/drivers/hwtracing/coresight/coresight-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>> @@ -739,12 +739,12 @@ static int coresight_get_trace_id(struct
>> coresight_device *csdev,
>> * Call this after creating the path and before enabling it. This
>> leaves
>> * the trace ID set on the path, or it remains 0 if it couldn't be
>> assigned.
>> */
>> -void coresight_path_assign_trace_id(struct coresight_path *path,
>> +int coresight_path_assign_trace_id(struct coresight_path *path,
>> enum cs_mode mode)
>> {
>> struct coresight_device *sink = coresight_get_sink(path);
>> struct coresight_node *nd;
>> - int trace_id;
>> + int trace_id, ret = -EINVAL;
>> list_for_each_entry(nd, &path->path_list, link) {
>> /* Assign a trace ID to the path for the first device that
>> wants to do it */
>> @@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct
>> coresight_path *path,
>> * Non 0 is either success or fail.
>> */
>> if (trace_id != 0) {
>> - path->trace_id = trace_id;
>> - return;
>> + if (IS_VALID_CS_TRACE_ID(trace_id)) {
>> + path->trace_id = trace_id;
>> + ret = 0;
>
> Reviewed-by: James Clark <james.clark@linaro.org>
>
> Minor nit, but just "return 0" here is a bit simpler.
>
Will remove the ret, and directly return the value for clearly expression.
Thanks,
Jie
>> + }
>> +
>> + return ret;
>
> And then "return -EINVAL" for these ones.
>
>> }
>> }
>> +
>> + return ret; > }
>> /**
>> diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/
>> hwtracing/coresight/coresight-priv.h
>> index 1ea882dffd70..34c7e792adbd 100644
>> --- a/drivers/hwtracing/coresight/coresight-priv.h
>> +++ b/drivers/hwtracing/coresight/coresight-priv.h
>> @@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device
>> *orig,
>> void coresight_remove_links(struct coresight_device *orig,
>> struct coresight_connection *conn);
>> u32 coresight_get_sink_id(struct coresight_device *csdev);
>> -void coresight_path_assign_trace_id(struct coresight_path *path,
>> +int coresight_path_assign_trace_id(struct coresight_path *path,
>> enum cs_mode mode);
>> #if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
>> diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/
>> hwtracing/coresight/coresight-sysfs.c
>> index d2a6ed8bcc74..b6a870399e83 100644
>> --- a/drivers/hwtracing/coresight/coresight-sysfs.c
>> +++ b/drivers/hwtracing/coresight/coresight-sysfs.c
>> @@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device
>> *csdev)
>> goto out;
>> }
>> - coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
>> - if (!IS_VALID_CS_TRACE_ID(path->trace_id))
>> + ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
>> + if (ret)
>> goto err_path;
>> ret = coresight_enable_path(path, CS_MODE_SYSFS);
>>
>> ---
>> base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
>> change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
>>
>> Best regards,
>
^ permalink raw reply
* RE: [PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board support
From: Bough Chen @ 2026-05-11 8:20 UTC (permalink / raw)
To: Chancel Liu, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com, mturquette@baylibre.com, sboyd@kernel.org
Cc: kernel@pengutronix.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
In-Reply-To: <20260509024846.2094049-5-chancel.liu@nxp.com>
> -----Original Message-----
> From: Chancel Liu <chancel.liu@nxp.com>
> Sent: 2026年5月9日 10:49
> To: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; Frank Li
> <frank.li@nxp.com>; s.hauer@pengutronix.de; festevam@gmail.com;
> mturquette@baylibre.com; sboyd@kernel.org
> Cc: kernel@pengutronix.de; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-clk@vger.kernel.org
> Subject: [PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board
> support
>
> IMX-AUD-IO is a daughter board which can be connected to i.MX952 EVK
> through a physical connector. This connector is described as a fsl,io-connector
> connector to expose a constrained subset of GPIO and clock resources to
> daughter board using fixed electrical wiring.
>
> Also add required regulator, sound CPU DAI and I2C bus configuration to support
> IMX-AUD-IO on this base board.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx952-evk.dts | 68 +++++++++++++++++++-
> 1 file changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> index 62d1c1c7c501..bb1d8d5f5fcf 100644
> --- a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> @@ -43,6 +43,17 @@ aliases {
> spi6 = &lpspi7;
> };
>
> + aud_io_conn: aud-io-connector {
> + compatible = "fsl,io-connector";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-map = <0 0 &pcal6416 8 1>;
> + gpio-map-mask = <0xff 0x0>;
> + gpio-map-pass-thru = <0x0 0x1>;
According to the include/dt-bindings/gpio/gpio.h, there 6 bits definition for GPIO flags, here you just pass through bit 0, should it better to use the following value:
gpio-map-pass-thru = <0x0 0x3f>;
Regards
Haibo Chen
> + #clock-cells = <1>;
> + clock-map = <0 &scmi_clk IMX952_CLK_SAI2>;
> + };
> +
> bt_sco_codec: audio-codec-bt-sco {
> #sound-dai-cells = <1>;
> compatible = "linux,bt-sco";
> @@ -114,13 +125,29 @@ reg_1p8v: regulator-1p8v {
> regulator-name = "+V1.8_SW";
> };
>
> - reg_vref_1v8: regulator-adc-vref {
> + aud_io_reg_1v8: reg_vref_1v8: regulator-adc-vref {
> compatible = "regulator-fixed";
> regulator-name = "vref_1v8";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <1800000>;
> };
>
> + aud_io_reg_3v3: regulator-aud-io-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "aud-io-3v3";
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + gpio = <&pcal6416 11 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + aud_io_reg_5v: regulator-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "aud-io-5v";
> + regulator-max-microvolt = <5000000>;
> + regulator-min-microvolt = <5000000>;
> + };
> +
> reg_audio_pwr: regulator-audio-pwr {
> compatible = "regulator-fixed";
> regulator-name = "audio-pwr";
> @@ -323,7 +350,7 @@ i2c4_pcal6408: gpio@21 {
> };
> };
>
> -&lpi2c6 {
> +aud_io_i2c: &lpi2c6 {
> clock-frequency = <100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_lpi2c6>;
> @@ -468,6 +495,27 @@ &sai1 {
> status = "okay";
> };
>
> +aud_io_cpu: &sai2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai2>;
> + clocks = <&scmi_clk IMX952_CLK_BUSNETCMIX>, <&clk_dummy>,
> + <&scmi_clk IMX952_CLK_SAI2>, <&clk_dummy>,
> + <&clk_dummy>, <&scmi_clk IMX952_CLK_AUDIOPLL1>,
> + <&scmi_clk IMX952_CLK_AUDIOPLL2>;
> + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
> + assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
> + <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
> + <&scmi_clk IMX952_CLK_AUDIOPLL1>,
> + <&scmi_clk IMX952_CLK_AUDIOPLL2>,
> + <&scmi_clk IMX952_CLK_SAI2>;
> + assigned-clock-parents = <0>, <0>, <0>, <0>,
> + <&scmi_clk IMX952_CLK_AUDIOPLL1>;
> + assigned-clock-rates = <3932160000>, <3612672000>,
> + <393216000>, <361267200>, <12288000>;
> + fsl,sai-mclk-direction-output;
> + fsl,sai-asynchronous;
> +};
> +
> &sai3 {
> assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
> <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
> @@ -688,6 +736,22 @@
> IMX952_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_13 0x51e
> >;
> };
>
> + pinctrl_sai2: sai2grp {
> + fsl,pins = <
> + IMX952_PAD_ENET2_MDIO__NETCMIX_TOP_SAI2_RX_BCLK
> 0x31e
> + IMX952_PAD_ENET2_MDC__NETCMIX_TOP_SAI2_RX_SYNC
> 0x31e
> + IMX952_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_0
> 0x31e
> + IMX952_PAD_ENET2_TD2__NETCMIX_TOP_SAI2_RX_DATA_1
> 0x31e
> + IMX952_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK
> 0x31e
> + IMX952_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC
> 0x31e
> +
> IMX952_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_0
> 0x31e
> + IMX952_PAD_ENET2_RXC__NETCMIX_TOP_SAI2_TX_DATA_1
> 0x31e
> + IMX952_PAD_ENET2_RD0__NETCMIX_TOP_SAI2_TX_DATA_2
> 0x31e
> + IMX952_PAD_ENET2_RD1__NETCMIX_TOP_SAI2_TX_DATA_3
> 0x31e
> + IMX952_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK
> 0x31e
> + >;
> + };
> +
> pinctrl_sai3: sai3grp {
> fsl,pins = <
> IMX952_PAD_GPIO_IO17__WAKEUPMIX_TOP_SAI3_MCLK
> 0x31e
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH] ARM: Do not select HAVE_RUST when KASAN is enabled
From: Alice Ryhl @ 2026-05-11 8:21 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Russell King, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Christian Schrrefl,
linux-arm-kernel, linux-kernel, rust-for-linux, stable
In-Reply-To: <20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org>
On Mon, May 11, 2026 at 05:02:44PM +0900, Nathan Chancellor wrote:
> When KASAN is enabled, such as with allmodconfig, the build fails when
> building the Rust code with:
>
> error: kernel-address sanitizer is not supported for this target
>
> error: aborting due to 1 previous error
>
> make[4]: *** [rust/Makefile:654: rust/core.o] Error 1
>
> The arm-unknown-linux-gnueabi target does not support KASAN, so avoid
> saying Rust is supported when it is enabled.
>
> Cc: stable@vger.kernel.org
> Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7")
> Link: https://github.com/Rust-for-Linux/linux/issues/1234
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
I would probably suggest moving the conditions out to a separate
RUSTC_SUPPORTS_ARM config option similar to what I did in commit
d077242d68a3 ("rust: support for shadow call stack sanitizer").
This way it will be simpler to adjust this logic when the target obtains
support for this sanitizer.
Also, we may need the same change for CONFIG_CFI too.
Alice
^ permalink raw reply
* [PATCH v3] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-11 8:36 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan
When coresight_path_assign_trace_id() cannot assign a valid trace ID,
coresight_enable_sysfs() takes the err_path goto with ret still 0,
returning success to the caller despite no trace session being started.
Fix this by changing coresight_path_assign_trace_id() to return int.
Move the IS_VALID_CS_TRACE_ID() check inside the function so it returns
-EINVAL on failure and 0 on success. Update coresight_enable_sysfs() to
check the return value directly instead of inspecting path->trace_id
after the call.
The other caller in coresight-etm-perf.c discards the return value and
continues to check path->trace_id via IS_VALID_CS_TRACE_ID() directly.
This is unaffected: on failure path->trace_id is no longer written, so
it remains 0, which IS_VALID_CS_TRACE_ID() rejects the same as before.
Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path")
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v3:
- directly return the value for clear expression.
- Link to v2: https://lore.kernel.org/r/20260509-fix-trace-id-error-v2-1-c900bcbab3e9@oss.qualcomm.com
Changes in v2:
- Refactor the coresight_path_assign_trace_id function.
- Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-v1-1-5f11a5456fdf@oss.qualcomm.com
---
drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++----
drivers/hwtracing/coresight/coresight-priv.h | 2 +-
drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 46f247f73cf6..254db91a8ac9 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -739,8 +739,8 @@ static int coresight_get_trace_id(struct coresight_device *csdev,
* Call this after creating the path and before enabling it. This leaves
* the trace ID set on the path, or it remains 0 if it couldn't be assigned.
*/
-void coresight_path_assign_trace_id(struct coresight_path *path,
- enum cs_mode mode)
+int coresight_path_assign_trace_id(struct coresight_path *path,
+ enum cs_mode mode)
{
struct coresight_device *sink = coresight_get_sink(path);
struct coresight_node *nd;
@@ -755,10 +755,16 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
* Non 0 is either success or fail.
*/
if (trace_id != 0) {
- path->trace_id = trace_id;
- return;
+ if (IS_VALID_CS_TRACE_ID(trace_id)) {
+ path->trace_id = trace_id;
+ return 0;
+ }
+
+ return -EINVAL;
}
}
+
+ return -EINVAL;
}
/**
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 1ea882dffd70..34c7e792adbd 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device *orig,
void coresight_remove_links(struct coresight_device *orig,
struct coresight_connection *conn);
u32 coresight_get_sink_id(struct coresight_device *csdev);
-void coresight_path_assign_trace_id(struct coresight_path *path,
+int coresight_path_assign_trace_id(struct coresight_path *path,
enum cs_mode mode);
#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index d2a6ed8bcc74..b6a870399e83 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
goto out;
}
- coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
- if (!IS_VALID_CS_TRACE_ID(path->trace_id))
+ ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
+ if (ret)
goto err_path;
ret = coresight_enable_path(path, CS_MODE_SYSFS);
---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Linus Walleij @ 2026-05-11 8:36 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <fd2ee102-db52-4a37-b96e-c16211e3d8e3@axiado.com>
On Fri, May 8, 2026 at 9:57 AM Petar Stepanovic <pstepanovic@axiado.com> wrote:
> For example, when SGPIO is configured for 128 lines, the hardware provides
> 128 input bits (DIN) and 128 output bits (DOUT). If modeled directly, this
> corresponds to 256 GPIOs in Linux, since the input and output signals are
> independent and are not bidirectional.
I don't get it.
Linux internals are modeled after physical GPIO lines, actual rails
you can control. ngpios for example means the number of controllable
physical lines.
What kind of bits exist in some registers does not concern this
concept.
Please check this presentation page 24 for example:
https://www.df.lth.se/~triad/papers/pincontrol.pdf
The fact that there exist many weird things inside the SoC
doesn't alter the fact that "a GPIO" is an abstraction for a single
physical I/O entity such as a line/pad/pin.
> Similar to the gpio-aspeed-sgpio.c driver, the input and output paths are
> fixed by hardware and cannot be configured dynamically per line. These are
> not interchangeable directions of the same GPIO line;
Are they connected to the same physical output line/pin or
not? That is the only thing that matters. If they in the end control
the same physical entitiy, it *is* the same GPIO line from Linux'
point of view.
> Because the direction is fixed by hardware, the standard
> lines-initial-states property, which encodes both direction and initial state,
> does not map cleanly to this design.
GPIOs with fixed direction is nothing new for Linux, we've had
that for ages.
I would just have the driver reject configurations that does
not apply and bail out.
If you absolutely want to enforce the lines-initial-states to match what the
hardware can do, then use YAML schema restriuctions on what
values can be encoded into that array.
> For the output lines (DOUT), should their initial values be described in the
> device tree, or should they be configured by userspace, with the driver only
> providing default initialization?
I don't see why userspace should deal with that. The Linux userspace
ABI is for hacking and odd usecases (like industrial). The nominal
use is kernel-internal consumers and those must be able to
request their GPIOs as well without any userspace shenanigans.
But avoiding to deal with initial line states at all is a solution
of course.
What I don't understand is what purpose this dout-init actually
does and why it cannot be set dynamically by the driver at runtime.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] arm64: dts: freescale: imx95-toradex-smarc: replace deprecated gpio property
From: Francesco Dolcini @ 2026-05-11 8:46 UTC (permalink / raw)
To: Antoine Gouby
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel, Francesco Dolcini,
Antoine Gouby
In-Reply-To: <20260508-replace-gpio-property-v1-1-ec67cc64e576@toradex.com>
On Fri, May 08, 2026 at 01:26:36PM +0200, Antoine Gouby wrote:
> From: Antoine Gouby <antoine.gouby@toradex.com>
>
> Replace deprecated "gpio" property with "gpios" in
> regulator-vmmc-usdhc2 fixed regulator node.
>
> Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
^ permalink raw reply
* Re: [PATCH v9 6/7] pinctrl: s32cc: implement GPIO functionality
From: Linus Walleij @ 2026-05-11 8:48 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot
In-Reply-To: <704e9e7b-0f45-4ed3-a686-9e20056eab2a@oss.nxp.com>
On Fri, May 8, 2026 at 11:07 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>I don't think the current driver is a good fit for
> a full gpio-regmap conversion. Direction and GPIO mux are
> handled through MSCR/pinctrl state (IBE/OBE/SSS), and the GPIO
> logic spans multiple register regions across two SIUL2 instances.
I don't see the problem with that?
> A conversion would require stronger separation between
> GPIO and pinctrl, leaving mux restoration entirely
> to the pinctrl subsystem.
Why is that so? Sorry I don't get the problem here.
The pinmux operations have these callbacks:
static const struct pinmux_ops s32_pmx_ops = {
(...)
.gpio_request_enable = s32_pmx_gpio_request_enable,
.gpio_disable_free = s32_pmx_gpio_disable_free,
.gpio_set_direction = s32_pmx_gpio_set_direction,
};
So to me it looks like the pinctrl subsystem is *already*
handling all the muxing of GPIO lines in these
callbacks?
> Would it be reasonable to keep the current approach for now
> and revisit gpio-regmap later if needed?
I'd prefer that you look into it now while you already
have all the information at hand and fresh in your mind.
You can forward my comments to your project lead
/ JIRA instance and say it's Linus' fault you have to spend
more time on this right now.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: watchdog: apple,wdt: Add t8122 compatible
From: Janne Grunau @ 2026-05-11 8:50 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, devicetree,
linux-kernel, asahi, linux-arm-kernel, linux-watchdog, linux-pwm,
Joshua Peisach
In-Reply-To: <85ea46a7-1136-4ea0-9eec-7dfa465df20b@roeck-us.net>
On Sun, May 10, 2026 at 08:29:39AM -0700, Guenter Roeck wrote:
> On Thu, May 07, 2026 at 09:33:08AM +0200, Janne Grunau wrote:
> > The watchdog on the Apple silicon t8122 (M3) SoC is compatible with the
> > existing driver. Add "apple,t8122-wdt" as SoC specific compatible under
> > "apple,t8103-wdt" used by the driver.
>
> '"apple,t8103-wdt" used by the driver' is not true. The watchdog driver
> only supports "apple,wdt".
It slipped my mind that
https://lore.kernel.org/linux-watchdog/20251231-watchdog-apple-t8103-base-compat-v1-1-1702a02e0c45@jannau.net/
wasn't picked up yet.
>
> >
> > Acked-by: Rob Herring (Arm) <robh@kernel.org>
> > Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
> > Reviewed-by: Neal Gompa <neal@gompa.dev>
> > Signed-off-by: Janne Grunau <j@jannau.net>
> > ---
> > Documentation/devicetree/bindings/watchdog/apple,wdt.yaml | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> > index 05602678c070..845b5e8b5abc 100644
> > --- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> > +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> > @@ -16,7 +16,9 @@ properties:
> > compatible:
> > oneOf:
> > - items:
> > - - const: apple,t6020-wdt
> > + - enum:
> > + - apple,t6020-wdt
> > + - apple,t8122-wdt
> > - const: apple,t8103-wdt
> > - items:
> > - enum:
>
> I second Sashiko's findings that the driver will fail to bind because it
> only supports "apple,wdt". I would not mind and apply the patch anyway,
> but the statement in the description is just plain wrong and thus
> misleading. Please fix.
I would prefer if the addition of the "apple,t8103-wdt" to the driver is
picked.
Thanks,
Janne
^ permalink raw reply
* [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-11 8:57 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]
From: David Woodhouse <dwmw@amazon.co.uk>
Document the expectation that KVM maintains guest-visible compatibility
across host kernel upgrades and rollbacks. Specifically:
- State saved/restored via KVM ioctls must be sufficient for live
migration (and live update) between kernel versions.
- Where a new kernel introduces a guest-visible change, it provides a
mechanism for userspace to select the previous behaviour.
- This allows both forward migration (upgrade) and backward migration
(rollback) of guests.
These expectations have been implicitly required on x86 but were not
explicitly documented. Harmonise the expectations across all of KVM.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
Documentation/virt/kvm/api.rst | 14 ++++++++++++++
Documentation/virt/kvm/review-checklist.rst | 20 ++++++++++++++------
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 269970221797..864f3daa7acb 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -97,6 +97,20 @@ Instead, kvm defines extension identifiers and a facility to query
whether a particular extension identifier is available. If it is, a
set of ioctls is available for application use.
+KVM will ensure that the state that can be saved and restored via the
+KVM ioctls is sufficient to allow migration of a running guest between
+host kernels while maintaining full compatibility of the guest-visible
+device model. This includes migration to newer kernels (upgrade) and
+to older kernels (rollback), provided that the older kernel supports
+the set of features exposed to the guest. Where a new kernel version
+introduces a guest-visible change, it will provide a mechanism (such
+as a capability or a device attribute) that allows userspace to select
+the previous behaviour. This serves two purposes: guests migrated
+from an older kernel can continue to run with their original
+observable environment, and new guests launched on the newer kernel
+can be configured to match the feature set of the older kernel, so
+that they remain migratable to the older kernel in case of rollback.
+
4. API description
==================
diff --git a/Documentation/virt/kvm/review-checklist.rst b/Documentation/virt/kvm/review-checklist.rst
index 053f00c50d66..f0fbe1577a90 100644
--- a/Documentation/virt/kvm/review-checklist.rst
+++ b/Documentation/virt/kvm/review-checklist.rst
@@ -18,22 +18,30 @@ Review checklist for kvm patches
5. New features must default to off (userspace should explicitly request them).
Performance improvements can and should default to on.
-6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2,
+6. Guest-visible changes must not break migration compatibility. A guest
+ migrated from an older kernel must be able to run with its original
+ observable environment, and a guest launched on a newer kernel must be
+ configurable to match the older kernel's feature set for rollback.
+ Where a change alters guest-visible behaviour, provide a mechanism
+ (capability, device attribute, etc.) for userspace to select the
+ previous behaviour.
+
+7. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2,
or its equivalent for non-x86 architectures
-7. The feature should be testable (see below).
+8. The feature should be testable (see below).
-8. Changes should be vendor neutral when possible. Changes to common code
+9. Changes should be vendor neutral when possible. Changes to common code
are better than duplicating changes to vendor code.
-9. Similarly, prefer changes to arch independent code than to arch dependent
+10. Similarly, prefer changes to arch independent code than to arch dependent
code.
-10. User/kernel interfaces and guest/host interfaces must be 64-bit clean
+11. User/kernel interfaces and guest/host interfaces must be 64-bit clean
(all variables and sizes naturally aligned on 64-bit; use specific types
only - u64 rather than ulong).
-11. New guest visible features must either be documented in a hardware manual
+12. New guest visible features must either be documented in a hardware manual
or be accompanied by documentation.
Testing of KVM code
--
2.43.0
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply related
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Ard Biesheuvel @ 2026-05-11 8:59 UTC (permalink / raw)
To: Jann Horn, Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, Will Deacon, Catalin Marinas,
Mark Rutland, Ryan Roberts, Anshuman Khandual, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <CAG48ez1DJ88a0pBCE-Q0VXyDuJgng8zdunb38g4b4JPU88exww@mail.gmail.com>
On Fri, 8 May 2026, at 19:02, Jann Horn wrote:
> On Mon, Apr 27, 2026 at 5:44 PM Ard Biesheuvel <ardb+git@google.com> wrote:
>> The empty zero page is used to back any kernel or user space mapping
>> that is supposed to remain cleared, and so the page itself is never
>> supposed to be modified.
>>
>> So make it __ro_after_init rather than __page_aligned_bss: on most
>> architectures, this ensures that both the kernel's mapping of it and any
>> aliases that are accessible via the kernel direct (linear) map are
>> mapped read-only, and cannot be used (inadvertently or maliciously) to
>> corrupt the contents of the zero page.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
> Reviewed-by: Jann Horn <jannh@google.com>
>
Thanks
> Sorry, I should have looked at this properly earlier instead of ending
> up duplicating this patch with
> <https://lore.kernel.org/all/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/>.
>
No worries. I might borrow some of that rationale btw
>> ---
>> mm/mm_init.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>> index f9f8e1af921c..6ca01ed2a5a4 100644
>> --- a/mm/mm_init.c
>> +++ b/mm/mm_init.c
>> @@ -57,7 +57,7 @@ unsigned long zero_page_pfn __ro_after_init;
>> EXPORT_SYMBOL(zero_page_pfn);
>>
>> #ifndef __HAVE_COLOR_ZERO_PAGE
>> -uint8_t empty_zero_page[PAGE_SIZE] __page_aligned_bss;
>> +uint8_t empty_zero_page[PAGE_SIZE] __ro_after_init __aligned(PAGE_SIZE);
>
> I think this is fine as-is; but FWIW:
> "__ro_after_init __aligned(PAGE_SIZE)" means that this will land
> in the middle of the .data..ro_after_init section, with padding in
> front of it to create 4K alignment. So this probably wastes some
> RAM on padding.
>
> Looking at "nm ../linux-out/vmlinux | sort" with this patch applied
> (from a build without any LTO or such), I see this:
> ```
> [...]
> ffffffff8473d378 d shmem_inode_cachep
> ffffffff8473d380 d user_buckets
> ffffffff8473e000 D zero_page_pfn
> ffffffff8473f000 D empty_zero_page
> ffffffff84740000 D __zero_page
> ffffffff84740008 D pcpu_reserved_chunk
> [...]
> ```
> So I think there are almost 4K of padding between zero_page_pfn and
> empty_zero_page for alignment; and I think when the linker linked
> mm-init.o with the rest of the kernel, it also had to align the
> compilation unit's entire .data..ro_after_init section to 4K, which is
> why I also got ~3K of padding before zero_page_pfn, resulting in a
> total of ~7K of padding.
>
> If you want to change this:
> I searched through the arch-specific linker scripts, and I think they
> all rely on the generic RO_DATA() macro for emitting the rodata
> section; so creating an analogous page-aligned rodata section should
> be as simple as adding "*(.rodata..page_aligned)" directly after
> "__start_rodata = .;", as I did in my duplicate patch.
I think we should simply do something along the lines of the below,
considering that the size of a data object tends to correlate with
its minimum alignment.
I do find it rather puzzling that the compiler emits empty_zero_page
*after* zero_page_pfn - ideally, we'd combine the below with
-fdata-sections so that the linker sees all individual objects, but
I suspect that would create some problems elsewhere.
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -452,7 +452,7 @@
#define RO_AFTER_INIT_DATA \
. = ALIGN(8); \
__start_ro_after_init = .; \
- *(.data..ro_after_init) \
+ *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
JUMP_TABLE_DATA \
STATIC_CALL_DATA \
__end_ro_after_init = .;
^ permalink raw reply
* Re: [PATCH v7 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Linus Walleij @ 2026-05-11 9:00 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, linux-serial
In-Reply-To: <23095518.EfDdHjke4D@silicon.doe.home>
On Fri, May 8, 2026 at 12:09 AM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> So I read https://docs.kernel.org/process/maintainer-soc.html a few times. If
> I understand it correctly at this point "pull request" still means emails sent
> with p4, correct?
No it's the contents of an
git request-pull v7.1-rc1 git://..... tags/my-soc
put into a regular email and sent to soc@kernel.org.
I'm sorry if the terminology isn't always clear on what a pull request
actually is in the kernel world (as opposed to e.g. github). It's just
an email with request-pull contents and some cover letter.
> Or does someone create a git repository on git.kernel.org
> for me that I can use to send actual pull requests?
We can pull from wherever as long as you can sign your tag
with a GPG key that we can (in best cases) trust. We can also
just inspect the result of a pull request from a branch (no tag)
if we wanna, it just involves more inspection and trust.
> As I understand it, my 6 patches then go to the 4 corners of the kernel:
>
> Patch 1 (dt binding) to devicetree@vger.kernel.org
Nah as long as the DT maintianers ACK it (i.e. Reviewed-by) we
can merge that to the SoC tree.
> Patches 2 (platform), 5 (DTS) and 6 (defconfig) to soc@kernel.org, but not in
> one series but 3 independent ones
In an ideal world.
> Patches 3 and 4 (UART) to linux-serial@vger.kernel.org. I think this can and
> should be a series of both patches belonging together
Yups. Greg merges those.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] coresight: fix source not disabled on idr_alloc_u32 failure
From: Jie Gan @ 2026-05-11 9:04 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan, Jie Gan
In coresight_enable_sysfs(), for non-CPU sources (SOFTWARE, TPDM,
OTHERS), the source device is enabled via coresight_enable_source_sysfs()
before idr_alloc_u32() maps the path. If idr_alloc_u32() fails, the
original code jumped directly to err_source, which only calls
coresight_disable_path() and coresight_release_path(). The source device
was left enabled with an incremented refcnt but no path tracked for it,
leaving the device in an inconsistent state.
Disable the source before jumping to err_source so the enable and path
operations are fully unwound.
Fixes: 1f5149c7751c ("coresight: Move all sysfs code to sysfs file")
Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
---
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index d2a6ed8bcc74..a5c08fab97a1 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -244,8 +244,10 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
*/
hash = hashlen_hash(hashlen_string(NULL, dev_name(&csdev->dev)));
ret = idr_alloc_u32(&path_idr, path, &hash, hash, GFP_KERNEL);
- if (ret)
+ if (ret) {
+ coresight_disable_source_sysfs(csdev, NULL);
goto err_source;
+ }
break;
default:
/* We can't be here */
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260511-fix-coresight-sysfs-enable-issue-91533f26f9bb
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] clk: mstar: msc313-mpll: fix one-element shadow array overrun
From: Daniel Palmer @ 2026-05-11 9:06 UTC (permalink / raw)
To: Stepan Ionichev
Cc: romain.perier, mturquette, sboyd, linux-arm-kernel, linux-clk,
linux-kernel
In-Reply-To: <20260509104255.15479-1-sozdayvek@gmail.com>
Hi Stepan,
On Sun, 10 May 2026 at 02:58, Stepan Ionichev <sozdayvek@gmail.com> wrote:
> mpll->clk_data = devm_kzalloc(dev, struct_size(mpll->clk_data, hws,
> - ARRAY_SIZE(output_dividers)), GFP_KERNEL);
> + NUMOUTPUTS), GFP_KERNEL);
> if (!mpll->clk_data)
> return -ENOMEM;
It's been a long time since I wrote that stuff but what you have found
looks correct. I think initially the driver only exposed the "output
dividers" outputs and then was adjusted to expose the undivided pll
output and that allocation didn't get updated.
Since the report and the change look correct:
Acked-by: Daniel Palmer <daniel@thingy.jp>
Cheers,
Daniel
^ 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