* Re: [PATCH v8 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: sashiko-bot @ 2026-06-25 9:42 UTC (permalink / raw)
To: Neil Armstrong; +Cc: wsa+renesas, conor+dt, dri-devel, robh, devicetree
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-2-8570e692143e@linaro.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Asymmetric panel callbacks for DCS commands (display on/off) causes state mismatch and permanent blanking.
- [High] The panel initialization sequence sends the `set_display_on` command before the `exit_sleep_mode` command.
- [High] Missing device link between the panel and the secondary DSI host leads to Use-After-Free and Double-Free.
--
commit bd7c7e227b10119b2ca8cfde561c22808d05f4f2
Author: KancyJoe <kancy2333@outlook.com>
drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
This commit implements support for the Renesas 63419 based dual-DSI video
mode Display Panels used in the Ayaneo handheld gaming devices.
> diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c
[ ... ]
> +static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + /*
> + * Panel registers are loaded from DDIC Non Volatile Memory
> + *
> + * The DDIC expects this sequence to get out of sleep and enable display
> + */
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_on_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
[Severity: High]
Are these MIPI DCS commands sent in the correct order?
According to the standard, a display must exit sleep mode and wait for
internal initialization before processing the set_display_on command.
Sending set_display_on first might cause the sleeping DDIC to ignore it.
> + mipi_dsi_msleep(&dsi_ctx, 150);
> +
> + return dsi_ctx.accum_err;
> +}
[ ... ]
> +static int renesas_r63419_disable(struct drm_panel *panel)
> +{
> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_off_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_enter_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> +
> + return 0;
> +}
[ ... ]
> +static const struct drm_panel_funcs renesas_r63419_panel_funcs = {
> + .disable = renesas_r63419_disable,
> + .prepare = renesas_r63419_prepare,
> + .unprepare = renesas_r63419_unprepare,
[Severity: High]
Should there be an enable callback to match the disable callback?
If the display pipeline is disabled and re-enabled during DPMS transitions,
the bridge framework cycles disable and enable. Since the panel receives
set_display_off and enter_sleep_mode during disable, but the enable
callback is missing, won't the panel remain permanently asleep when waking
up?
> + .get_modes = renesas_r63419_get_modes,
> + .get_orientation = renesas_r63419_get_orientation,
> +};
[ ... ]
> +static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
> +{
[ ... ]
> + /* Register the second DSI device */
> + ctx->dsi[1] = devm_mipi_dsi_device_register_full(dev, dsi1_host, &info);
> + if (IS_ERR(ctx->dsi[1]))
> + return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
> + "Failed to register second DSI device\n");
[Severity: High]
Does the secondary DSI device registration require a device link to protect
its lifetime?
If the secondary host is unbound via sysfs, the DSI core unregisters all
child devices, freeing this pointer. Without a device link to force the
panel to unbind first, could devm teardown or subsequent panel accesses
lead to a use-after-free or double-free?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org?part=2
^ permalink raw reply
* [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support
From: Joey Lu @ 2026-06-25 9:44 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
This series adds support for the Verisilicon DCUltraLite display
controller as integrated in the Nuvoton MA35D1 SoC.
The Verisilicon DC driver and its DT binding were originally written by
Icenowy Zheng <zhengxingda@iscas.ac.cn> for the T-Head TH1520 SoC, which
carries a DC8200 IP block. The present series builds on that foundation
with gratitude to Icenowy for the original work.
The DCUltraLite is a different variant in the DC IP family. While the two
IPs share a broadly similar register layout, a number of differences
prevent the existing driver from working on the MA35D1 without
modification:
- No CONFIG_EX commit path: the DC8200 staging registers
(FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
PANEL_CONFIG_EX) are absent. The DCUltraLite uses enable (bit 0) and
reset (bit 4) bits in FB_CONFIG for direct framebuffer updates, and
requires a per-frame VALID bit toggle (FB_CONFIG bit 3) to latch
configuration changes.
- No PANEL_START register: panel output begins when
PANEL_CONFIG.RUNNING is set; the DC8200 multi-display sync start
register at 0x1CCC does not exist.
- Different IRQ registers: DISP_IRQ_STA at 0x147C / DISP_IRQ_EN at
0x1480, versus the DC8200's TOP_IRQ_ACK at 0x0010 / TOP_IRQ_EN at
0x0014.
- Simpler clock topology: two clocks ("core" bus gate and "pix0" pixel
divider); no axi or ahb clocks required.
- Single display output: no per-output indexing beyond index 0 is
needed.
- Hardware-discoverable identity: the DCUltraLite exposes chip identity
registers whose model field reads 0x0 (revision 0x5560,
customer_id 0x305), allowing the existing vs_fill_chip_identity()
path to identify the variant purely through register reads.
Patch 1 generalises the verisilicon,dc DT binding to accommodate the
Nuvoton MA35D1 SoC-specific compatible and the variant's two-clock,
one-reset, single-port topology.
Patch 2 adds the register-level macros needed by the DC8000 ops.
Patches 3-5 introduce the driver changes in three logical steps: the
vs_dc_funcs hardware ops vtable with DC8200 ops extracted into
vs_dc8200.c; making axi/ahb clocks optional as a separate atomic change;
and the DC8000 ops in vs_dc8000.c. Patch 6 adds the DCUltraLite HWDB
entry that gates hardware recognition once all support is in place.
Patch 7 adds the Kconfig dependency on ARCH_MA35, placed last because it
is only meaningful after the HWDB entry is added.
All patches have been tested on Nuvoton MA35D1 hardware.
Changes from v4:
- [dt-bindings] Kept clock and reset item descriptions in the global
clocks:/resets: properties; per-compatible sections only constrain
minItems/maxItems and override clock-names items for nuvoton,ma35d1-dcu.
- [dt-bindings] Dropped redundant global minItems/maxItems on clocks:
and clock-names:.
- [dt-bindings] Dropped the extra-space typo fix in port@0 description
to keep the patch atomic; left for a separate patch later.
- [ops] Renamed crtc_enable/crtc_disable hooks to crtc_enable_ex/
crtc_disable_ex.
- [ops] Added unified IRQ bit definitions; each irq_ack() implementation
now translates hardware-specific bits before returning.
- [clocks] Split the axi/ahb optional-clock change into its own patch
for atomicity.
- [hwdb] Simplified the commit message for patch 6.
- [kconfig] Simplified the commit message for patch 7.
Joey Lu (7):
dt-bindings: display: verisilicon,dc: generalize for single-output
variants
drm/verisilicon: add register-level macros for DC8000
drm/verisilicon: introduce per-variant hardware ops table
drm/verisilicon: make axi and ahb clocks optional
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
drm/verisilicon: add DCUltraLite chip identity to HWDB
drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
drivers/gpu/drm/verisilicon/vs_dc.c | 13 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 33 +++++
drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++
drivers/gpu/drm/verisilicon/vs_dc8200.c | 115 ++++++++++++++++++
drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
drivers/gpu/drm/verisilicon/vs_hwdb.c | 14 +++
drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
.../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
.../drm/verisilicon/vs_primary_plane_regs.h | 3 +
16 files changed, 378 insertions(+), 57 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
The verisilicon,dc binding was originally written for the T-Head TH1520
SoC carrying a DC8200, and hard-codes five clocks, three resets and two
output ports.
Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the binding.
The DCUltraLite uses only two clocks (core, pix0) and one reset (core),
with a single output port.
Use allOf/if blocks to express per-variant constraints rather than
hard-coding the DC8200 topology at the top level. Each compatible's
block constrains the clock and reset item counts; the nuvoton block
additionally overrides clock-names to the two names it actually uses.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 9dc35ab973f2..1e751f3c7ce8 100644
--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -17,6 +17,7 @@ properties:
items:
- enum:
- thead,th1520-dc8200
+ - nuvoton,ma35d1-dcu
- const: verisilicon,dc # DC IPs have discoverable ID/revision registers
reg:
@@ -77,6 +78,62 @@ required:
- clock-names
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: thead,th1520-dc8200
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
+ resets:
+ minItems: 3
+ maxItems: 3
+
+ reset-names:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nuvoton,ma35d1-dcu
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: pix0
+
+ resets:
+ minItems: 1
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: core
+
+ required:
+ - resets
+ - reset-names
+
additionalProperties: false
examples:
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] drm/verisilicon: add register-level macros for DC8000
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
Add register-level constants needed by the forthcoming DC8000 (DCUltraLite)
hardware ops:
VSDC_DISP_IRQ_VSYNC(n) in vs_crtc_regs.h: bit mask for per-output
VSYNC interrupt bits in DISP_IRQ_STA (0x147C) / DISP_IRQ_EN (0x1480),
which are the IRQ registers used by DCUltraLite in place of the DC8200
TOP_IRQ_ACK / TOP_IRQ_EN registers.
VSDC_FB_CONFIG_ENABLE (bit 0), VSDC_FB_CONFIG_VALID (bit 3) and
VSDC_FB_CONFIG_RESET (bit 4) in vs_primary_plane_regs.h: control bits
in the FB_CONFIG register used by DCUltraLite for framebuffer enable
and per-frame commit handshake.
No behaviour change for existing DC8200 platforms.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
index c7930e817635..d4da22b08cd5 100644
--- a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
+++ b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
@@ -54,6 +54,7 @@
#define VSDC_DISP_GAMMA_DATA(n) (0x1460 + 0x4 * (n))
#define VSDC_DISP_IRQ_STA 0x147C
+#define VSDC_DISP_IRQ_VSYNC(n) BIT(n)
#define VSDC_DISP_IRQ_EN 0x1480
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
index cbb125c46b39..67d4b00f294e 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
@@ -16,6 +16,9 @@
#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_VALID BIT(3)
+#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
* [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
The DC8200 and DCUltraLite share a broadly similar register layout but
differ in how the bridge, CRTC, primary plane and IRQ paths are driven.
Introduce a vs_dc_funcs vtable so each variant can supply its own
implementation without scattering conditionals across multiple files.
Add a generation field to struct vs_chip_identity to distinguish variants.
Extract the DC8200-specific hardware ops into vs_dc8200.c and add unified
IRQ bit definitions so implementations can translate hardware-specific
bits to a common set. Update the shared code to dispatch through
dc->funcs.
No behaviour change for existing DC8200 platforms.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
drivers/gpu/drm/verisilicon/vs_dc.c | 6 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 32 +++++
drivers/gpu/drm/verisilicon/vs_dc8200.c | 115 ++++++++++++++++++
drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
.../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
11 files changed, 214 insertions(+), 54 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
index 426f4bcaa834..9d4cd16452fa 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
-verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o vs_hwdb.o \
+verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_drm.o vs_hwdb.o \
vs_plane.o vs_primary_plane.o vs_cursor_plane.o
obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c b/drivers/gpu/drm/verisilicon/vs_bridge.c
index dc7c85b07fe3..3fbc8d57f8a1 100644
--- a/drivers/gpu/drm/verisilicon/vs_bridge.c
+++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
@@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct vs_crtc *crtc,
VSDC_DISP_PANEL_CONFIG_DE_EN |
VSDC_DISP_PANEL_CONFIG_DAT_EN |
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);
+
+ dc->funcs->panel_enable_ex(dc, output);
}
static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
@@ -228,14 +221,7 @@ 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);
+ dc->funcs->panel_disable_ex(dc, output);
}
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 0b8a35d09cd2..1c4aac708669 100644
--- a/drivers/gpu/drm/verisilicon/vs_crtc.c
+++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
@@ -16,10 +16,33 @@
#include "vs_crtc_regs.h"
#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#include "vs_plane.h"
+static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
+ struct drm_atomic_commit *state)
+{
+ struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
+ struct vs_dc *dc = vcrtc->dc;
+ unsigned int output = vcrtc->id;
+
+ if (dc->funcs->crtc_begin)
+ dc->funcs->crtc_begin(dc, output);
+}
+
+static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
+ struct drm_atomic_commit *state)
+{
+ struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
+ struct vs_dc *dc = vcrtc->dc;
+ unsigned int output = vcrtc->id;
+
+ if (dc->funcs->crtc_flush)
+ dc->funcs->crtc_flush(dc, output);
+
+ drm_crtc_vblank_atomic_flush(crtc, state);
+}
+
static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_commit *state)
{
@@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
drm_crtc_vblank_off(crtc);
clk_disable_unprepare(dc->pix_clk[output]);
+
+ if (dc->funcs->crtc_disable_ex)
+ dc->funcs->crtc_disable_ex(dc, output);
}
static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
@@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
drm_WARN_ON(&dc->drm_dev->base,
clk_prepare_enable(dc->pix_clk[output]));
+ if (dc->funcs->crtc_enable_ex)
+ dc->funcs->crtc_enable_ex(dc, output);
+
drm_crtc_vblank_on(crtc);
}
@@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
- .atomic_flush = drm_crtc_vblank_atomic_flush,
+ .atomic_begin = vs_crtc_atomic_begin,
+ .atomic_flush = vs_crtc_atomic_flush,
.atomic_enable = vs_crtc_atomic_enable,
.atomic_disable = vs_crtc_atomic_disable,
.mode_set_nofb = vs_crtc_mode_set_nofb,
@@ -132,7 +162,7 @@ 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));
+ dc->funcs->enable_vblank(dc, vcrtc->id);
return 0;
}
@@ -142,7 +172,7 @@ 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));
+ dc->funcs->disable_vblank(dc, 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..9729b693d360 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -8,9 +8,7 @@
#include <linux/of.h>
#include <linux/of_graph.h>
-#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#include "vs_hwdb.h"
@@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
struct vs_dc *dc = private;
u32 irqs;
- regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
+ irqs = dc->funcs->irq_ack(dc);
vs_drm_handle_irq(dc, irqs);
@@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device *pdev)
dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
dc->identity.revision, dc->identity.customer_id);
+ dc->funcs = &vs_dc8200_funcs;
+
if (port_count > dc->identity.display_count) {
dev_err(dev, "too many downstream ports than HW capability\n");
ret = -EINVAL;
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h b/drivers/gpu/drm/verisilicon/vs_dc.h
index ed1016f18758..825f5dd6bf17 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.h
+++ b/drivers/gpu/drm/verisilicon/vs_dc.h
@@ -14,6 +14,7 @@
#include <linux/reset.h>
#include <drm/drm_device.h>
+#include <drm/drm_plane.h>
#include "vs_hwdb.h"
@@ -22,6 +23,34 @@
struct vs_drm_dev;
struct vs_crtc;
+struct vs_dc;
+
+struct vs_dc_funcs {
+ /* Bridge: atomic_enable, atomic_disable */
+ void (*panel_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*panel_disable_ex)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: atomic_begin, atomic_flush */
+ void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
+ void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: atomic_enable, atomic_disable */
+ void (*crtc_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*crtc_disable_ex)(struct vs_dc *dc, unsigned int output);
+
+ /* CRTC: enable_vblank, disable_vblank */
+ void (*enable_vblank)(struct vs_dc *dc, unsigned int output);
+ void (*disable_vblank)(struct vs_dc *dc, unsigned int output);
+
+ /* Primary plane: atomic_enable, atomic_disable, atomic_update */
+ void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned int output);
+ void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned int output,
+ struct drm_plane_state *state);
+
+ /* IRQ acknowledge */
+ u32 (*irq_ack)(struct vs_dc *dc);
+};
struct vs_dc {
struct regmap *regs;
@@ -33,6 +62,9 @@ struct vs_dc {
struct vs_drm_dev *drm_dev;
struct vs_chip_identity identity;
+ const struct vs_dc_funcs *funcs;
};
+extern const struct vs_dc_funcs vs_dc8200_funcs;
+
#endif /* _VS_DC_H_ */
diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c b/drivers/gpu/drm/verisilicon/vs_dc8200.c
new file mode 100644
index 000000000000..17378f4ef96d
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
+ */
+
+#include <linux/regmap.h>
+
+#include "vs_bridge_regs.h"
+#include "vs_dc.h"
+#include "vs_dc_top_regs.h"
+#include "vs_drm.h"
+#include "vs_plane.h"
+#include "vs_primary_plane_regs.h"
+
+static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ 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(output),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_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 |
+ VSDC_DISP_PANEL_START_RUNNING(output));
+
+ regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
+ VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(output));
+}
+
+static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
+ VSDC_TOP_IRQ_VSYNC(output));
+}
+
+static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_COMMIT);
+}
+
+static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ 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_dc8200_plane_commit(dc, output);
+}
+
+static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
+ VSDC_FB_CONFIG_EX_FB_EN);
+
+ vs_dc8200_plane_commit(dc, output);
+}
+
+static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc, unsigned int output,
+ struct drm_plane_state *state)
+{
+ 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_dc8200_plane_commit(dc, output);
+}
+
+static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
+{
+ u32 hw_irqs, unified = 0;
+ unsigned int i;
+
+ regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
+
+ for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
+ if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
+ unified |= VSDC_IRQ_VSYNC(i);
+ }
+
+ return unified;
+}
+
+const struct vs_dc_funcs vs_dc8200_funcs = {
+ .panel_enable_ex = vs_dc8200_panel_enable_ex,
+ .panel_disable_ex = vs_dc8200_panel_disable_ex,
+ .enable_vblank = vs_dc8200_enable_vblank,
+ .disable_vblank = vs_dc8200_disable_vblank,
+ .primary_plane_enable_ex = vs_dc8200_primary_plane_enable_ex,
+ .primary_plane_disable_ex = vs_dc8200_primary_plane_disable_ex,
+ .primary_plane_update_ex = vs_dc8200_primary_plane_update_ex,
+ .irq_ack = vs_dc8200_irq_ack,
+};
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
index fd259d53f49f..24e9d0b008f3 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.c
+++ b/drivers/gpu/drm/verisilicon/vs_drm.c
@@ -25,7 +25,6 @@
#include "vs_bridge.h"
#include "vs_crtc.h"
#include "vs_dc.h"
-#include "vs_dc_top_regs.h"
#include "vs_drm.h"
#define DRIVER_NAME "verisilicon"
@@ -168,8 +167,8 @@ void vs_drm_handle_irq(struct vs_dc *dc, u32 irqs)
unsigned int i;
for (i = 0; i < dc->identity.display_count; i++) {
- if (irqs & VSDC_TOP_IRQ_VSYNC(i)) {
- irqs &= ~VSDC_TOP_IRQ_VSYNC(i);
+ if (irqs & VSDC_IRQ_VSYNC(i)) {
+ irqs &= ~VSDC_IRQ_VSYNC(i);
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
}
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.h b/drivers/gpu/drm/verisilicon/vs_drm.h
index 606338206a42..6a89c20879df 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.h
+++ b/drivers/gpu/drm/verisilicon/vs_drm.h
@@ -6,6 +6,7 @@
#ifndef _VS_DRM_H_
#define _VS_DRM_H_
+#include <linux/bits.h>
#include <linux/platform_device.h>
#include <linux/types.h>
@@ -13,6 +14,13 @@
struct vs_dc;
+/*
+ * DC variants use different interrupt registers with diverging bit
+ * assignments; each irq_ack() implementation must translate its
+ * hardware-specific bits into these definitions.
+ */
+#define VSDC_IRQ_VSYNC(n) BIT(n)
+
struct vs_drm_dev {
struct drm_device base;
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
index 2a0f7c59afa3..91524d16f778 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
@@ -94,6 +94,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = ~0U,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
@@ -103,6 +104,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5721,
.customer_id = 0x30B,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
@@ -112,6 +114,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = 0x310,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_with_yuv444,
@@ -121,6 +124,7 @@ static struct vs_chip_identity vs_chip_identities[] = {
.revision = 0x5720,
.customer_id = 0x311,
+ .generation = VSDC_GEN_DC8200,
.display_count = 2,
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h b/drivers/gpu/drm/verisilicon/vs_hwdb.h
index 2065ecb73043..a15c8b565604 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
@@ -9,6 +9,11 @@
#include <linux/regmap.h>
#include <linux/types.h>
+enum vs_dc_generation {
+ VSDC_GEN_DC8000,
+ VSDC_GEN_DC8200,
+};
+
struct vs_formats {
const u32 *array;
unsigned int num;
@@ -19,6 +24,7 @@ struct vs_chip_identity {
u32 revision;
u32 customer_id;
+ enum vs_dc_generation generation;
u32 display_count;
/*
* The hardware only supports square cursor planes, so this field
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
index 1f2be41ae496..f992cb277f61 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
@@ -53,12 +53,6 @@ static int vs_primary_plane_atomic_check(struct drm_plane *plane,
return 0;
}
-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);
-}
-
static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
struct drm_atomic_commit *atomic_state)
{
@@ -69,13 +63,8 @@ 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));
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_enable_ex)
+ dc->funcs->primary_plane_enable_ex(dc, output);
}
static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
@@ -88,10 +77,8 @@ 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);
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_disable_ex)
+ dc->funcs->primary_plane_disable_ex(dc, output);
}
static void vs_primary_plane_atomic_update(struct drm_plane *plane,
@@ -133,18 +120,11 @@ 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);
-
- vs_primary_plane_commit(dc, output);
+ if (dc->funcs->primary_plane_update_ex)
+ dc->funcs->primary_plane_update_ex(dc, output, state);
}
static const struct drm_plane_helper_funcs vs_primary_plane_helper_funcs = {
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller whose
AXI and AHB bus clocks share a single gate enable bit with the display
core clock, so the clock driver does not expose them separately. This
patch makes the axi and ahb clocks optional in the probe.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/vs_dc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
index 9729b693d360..fd1f5fe67a68 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->core_clk);
}
- dc->axi_clk = devm_clk_get_enabled(dev, "axi");
+ dc->axi_clk = devm_clk_get_optional_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");
+ dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
if (IS_ERR(dc->ahb_clk)) {
dev_err(dev, "can't get ahb clock\n");
return PTR_ERR(dc->ahb_clk);
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
controller (DC8000 generation) whose register layout differs from
the DC8200 in several important ways:
1. No CONFIG_EX commit path: framebuffer updates use the enable (bit 0)
and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
FB_BLEND_CONFIG, PANEL_CONFIG_EX).
2. No PANEL_START register: panel output starts when
PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
register.
3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
TOP_IRQ_EN (0x0014).
4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
divider) clocks; no axi or ahb clocks required.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_dc.c | 5 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++++++++++++++
4 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
index 9d4cd16452fa..d2fd8e4dff24 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
-verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_drm.o vs_hwdb.o \
+verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_dc8000.o vs_drm.o vs_hwdb.o \
vs_plane.o vs_primary_plane.o vs_cursor_plane.o
obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
index fd1f5fe67a68..9499fffbca58 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.c
+++ b/drivers/gpu/drm/verisilicon/vs_dc.c
@@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device *pdev)
dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
dc->identity.revision, dc->identity.customer_id);
- dc->funcs = &vs_dc8200_funcs;
+ if (dc->identity.generation == VSDC_GEN_DC8200)
+ dc->funcs = &vs_dc8200_funcs;
+ else
+ dc->funcs = &vs_dc8000_funcs;
if (port_count > dc->identity.display_count) {
dev_err(dev, "too many downstream ports than HW capability\n");
diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h b/drivers/gpu/drm/verisilicon/vs_dc.h
index 825f5dd6bf17..ac96ad701199 100644
--- a/drivers/gpu/drm/verisilicon/vs_dc.h
+++ b/drivers/gpu/drm/verisilicon/vs_dc.h
@@ -66,5 +66,6 @@ struct vs_dc {
};
extern const struct vs_dc_funcs vs_dc8200_funcs;
+extern const struct vs_dc_funcs vs_dc8000_funcs;
#endif /* _VS_DC_H_ */
diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c b/drivers/gpu/drm/verisilicon/vs_dc8000.c
new file mode 100644
index 000000000000..fbe0fa516cac
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
+ */
+
+#include <linux/regmap.h>
+
+#include "vs_crtc_regs.h"
+#include "vs_dc.h"
+#include "vs_drm.h"
+#include "vs_primary_plane_regs.h"
+
+static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_RESET);
+}
+
+static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_RESET);
+}
+
+static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_VALID);
+}
+
+static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_VALID);
+}
+
+static void vs_dc8000_crtc_enable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_ENABLE);
+}
+
+static void vs_dc8000_crtc_disable_ex(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
+ VSDC_FB_CONFIG_ENABLE);
+}
+
+static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
+ VSDC_DISP_IRQ_VSYNC(output));
+}
+
+static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int output)
+{
+ regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
+ VSDC_DISP_IRQ_VSYNC(output));
+}
+
+static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
+{
+ u32 hw_irqs, unified = 0;
+ unsigned int i;
+
+ regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
+
+ for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
+ if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
+ unified |= VSDC_IRQ_VSYNC(i);
+ }
+
+ return unified;
+}
+
+const struct vs_dc_funcs vs_dc8000_funcs = {
+ .panel_enable_ex = vs_dc8000_panel_enable_ex,
+ .panel_disable_ex = vs_dc8000_panel_disable_ex,
+ .crtc_begin = vs_dc8000_crtc_begin,
+ .crtc_flush = vs_dc8000_crtc_flush,
+ .crtc_enable_ex = vs_dc8000_crtc_enable_ex,
+ .crtc_disable_ex = vs_dc8000_crtc_disable_ex,
+ .enable_vblank = vs_dc8000_enable_vblank,
+ .disable_vblank = vs_dc8000_disable_vblank,
+ .irq_ack = vs_dc8000_irq_ack,
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
drivers/gpu/drm/verisilicon/vs_hwdb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
index 91524d16f778..7d630a667a3f 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
@@ -129,6 +129,16 @@ static struct vs_chip_identity vs_chip_identities[] = {
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
},
+ {
+ .model = 0x0, /* DCUltraLite */
+ .revision = 0x5560,
+ .customer_id = 0x305,
+
+ .generation = VSDC_GEN_DC8000,
+ .display_count = 1,
+ .max_cursor_size = 32,
+ .formats = &vs_formats_no_yuv444,
+ },
};
int vs_fill_chip_identity(struct regmap *regs,
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/7] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
From: Joey Lu @ 2026-06-25 9:44 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: <20260625094449.708386-1-a0987203069@gmail.com>
Add ARCH_MA35 to the platform dependencies to allow the driver to be
built for Nuvoton MA35D1.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: sashiko-bot @ 2026-06-25 9:54 UTC (permalink / raw)
To: Joey Lu; +Cc: devicetree, robh, dri-devel, conor+dt
In-Reply-To: <20260625094449.708386-2-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The Nuvoton MA35D1 conditional schema block logically conflicts with top-level constraints, causing validation of valid Nuvoton device trees to unconditionally fail.
- [Medium] The Nuvoton MA35D1 conditional block fails to restrict the `ports` property to a single output port, contradicting the hardware description.
--
commit 6779aa6e54db7988d8c51ba66d2a7972829a44e6
Author: Joey Lu <a0987203069@gmail.com>
dt-bindings: display: verisilicon,dc: generalize for single-output variants
This commit adds the Nuvoton MA35D1 DCUltraLite to the verisilicon,dc
binding. It introduces conditional blocks to express per-variant
constraints for clocks and resets rather than hard-coding the DC8200
topology at the top level.
> diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> index 9dc35ab973f20..1e751f3c7ce83 100644
> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
[ ... ]
> +allOf:
[ ... ]
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nuvoton,ma35d1-dcu
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: core
> + - const: pix0
[Severity: High]
Does this conditional schema conflict with the top-level constraints?
Any device tree node containing the compatible string for the Nuvoton
variant is evaluated against both the top-level schema and this conditional
block concurrently.
The top-level definitions strictly enforce a 5-item array and specific
constant values for clock-names (such as the second item being axi). This
block attempts to override those with a maximum of 2 items and restricts the
second item to pix0.
Since a length cannot be both exactly 5 and a maximum of 2, and an element
cannot be both axi and pix0, this creates an unsatisfiable constraint.
Will this cause validation of valid Nuvoton device trees to unconditionally
fail?
> +
> + resets:
> + minItems: 1
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: core
> +
> + required:
> + - resets
> + - reset-names
[Severity: Medium]
Does this block need to explicitly restrict the ports property to a single
output port?
The commit message states that the Nuvoton MA35D1 DCUltraLite has a single
output port. However, because this conditional block does not explicitly
disallow the second port, it inherits the top-level allowances.
Will malformed device trees incorrectly specifying two output ports for the
Nuvoton variant silently pass schema validation, bypassing the hardware
topology checks?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: sashiko-bot @ 2026-06-25 10:00 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, devicetree, dri-devel, robh
In-Reply-To: <20260625094449.708386-4-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
New issues:
- [High] CRTC disable hardware operation is called after disabling the pixel clock.
- [High] The register clearing sequence in `vs_dc8200_panel_disable_ex` is inverted compared to the original code, clearing the configuration bit before stopping the panel.
- [Medium] Unknown hardware interrupts are silently filtered out by the irq_ack abstraction, rendering the unknown interrupt diagnostic warning unreachable.
Pre-existing issues:
- [High] Primary plane disable function incorrectly sets the enable bit rather than clearing it.
- [High] The driver requests its IRQ line before it fully initializes its internal state, creating a race condition that can lead to a NULL pointer dereference.
- [High] `vs_dc_irq_handler` unconditionally returns `IRQ_HANDLED` regardless of whether any interrupt bits were set.
--
commit d0e2c6765378754f6b5239526ba6f62ca9de0dd3
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: introduce per-variant hardware ops table
The DC8200 and DCUltraLite share a broadly similar register layout but differ
in how the bridge, CRTC, primary plane and IRQ paths are driven. This commit
introduces a vs_dc_funcs vtable so each variant can supply its own
implementation without scattering conditionals across multiple files.
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
> index 0b8a35d09cd2e..1c4aac7086694 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
[ ... ]
> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
> drm_crtc_vblank_off(crtc);
>
> clk_disable_unprepare(dc->pix_clk[output]);
> +
> + if (dc->funcs->crtc_disable_ex)
> + dc->funcs->crtc_disable_ex(dc, output);
> }
[Severity: High]
Is it safe to access hardware registers via crtc_disable_ex() after the pixel
clock has been gated? The teardown order should typically reverse the
initialization order, meaning the hook must be invoked before gating the clock.
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index dad9967bc10b8..9729b693d360e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
> struct vs_dc *dc = private;
> u32 irqs;
>
> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
> + irqs = dc->funcs->irq_ack(dc);
>
> vs_drm_handle_irq(dc, irqs);
>
> return IRQ_HANDLED;
[Severity: High]
This isn't a bug introduced by this patch, but does unconditionally returning
IRQ_HANDLED prevent the kernel from detecting and disabling a stuck shared
interrupt line? If the handler processes no interrupts, shouldn't it return
IRQ_NONE?
[Severity: High]
This is another pre-existing issue, but in vs_dc_probe(), the IRQ is
requested before vs_drm_initialize() is called. Can the IRQ handler fire
before dc->drm_dev is allocated, resulting in a NULL pointer dereference
when vs_drm_handle_irq() executes?
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c b/drivers/gpu/drm/verisilicon/vs_dc8200.c
> new file mode 100644
> index 0000000000000..17378f4ef96d1
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
[ ... ]
> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned int output)
> +{
> + regmap_clear_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 |
> + VSDC_DISP_PANEL_START_RUNNING(output));
[Severity: High]
Does reversing the clear order of the configuration and start registers risk
hardware underflows or state desynchronization? In the original
vs_bridge_atomic_disable() implementation, the panel was shut down by first
clearing VSDC_DISP_PANEL_START_RUNNING and then clearing
VSDC_DISP_PANEL_CONFIG_RUNNING.
[ ... ]
> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc, unsigned int output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
> +
> + vs_dc8200_plane_commit(dc, output);
> +}
[Severity: High]
This is a pre-existing issue carried over from the original code, but does
the primary plane disable sequence leave the plane enabled by using
regmap_set_bits() instead of clearing the VSDC_FB_CONFIG_EX_FB_EN bit?
[ ... ]
> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
> +
> + return unified;
> +}
[Severity: Medium]
Does this filter out unknown hardware interrupts, making the diagnostic
warning in vs_drm_handle_irq() unreachable? By only passing through known
VSDC_IRQ_VSYNC bits, any unmapped hardware interrupt bits are silently
discarded.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: sashiko-bot @ 2026-06-25 10:01 UTC (permalink / raw)
To: Joey Lu; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260625094449.708386-5-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Possible NULL pointer dereference in the IRQ handler if an interrupt triggers before DRM initialization completes.
--
commit 2cd6077ab2fb5ed065ee2cef55004b713c80f827
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: make axi and ahb clocks optional
The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller whose
AXI and AHB bus clocks share a single gate enable bit with the display
core clock, so the clock driver does not expose them separately. This
patch makes the axi and ahb clocks optional in the probe.
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index 9729b693d360e..fd1f5fe67a68b 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
[ ... ]
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
[Severity: High]
This is a pre-existing issue, but is it possible for an interrupt to trigger
a NULL pointer dereference during probe if the bootloader left the display
active?
Looking further down in vs_dc_probe(), the IRQ handler is registered before
vs_drm_initialize() is called:
ret = devm_request_irq(dev, irq, vs_dc_irq_handler, 0,
dev_name(dev), dc);
if (ret) {
dev_err(dev, "can't request irq\n");
goto err_rst_assert;
}
dev_set_drvdata(dev, dc);
ret = vs_drm_initialize(dc, pdev);
If a pending interrupt (such as VSYNC) fires immediately after
devm_request_irq() is called, vs_dc_irq_handler() will be triggered and will
eventually call vs_drm_handle_irq().
Looking at vs_drm_handle_irq() in vs_drm.c, it unconditionally dereferences
the drm_dev pointer:
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
Since vs_drm_initialize() hasn't allocated or assigned dc->drm_dev yet,
could this cause a kernel panic during boot on platforms where the bootloader
leaves interrupts enabled?
Would it be safer to request the IRQ after the DRM device is fully
initialized, or to mask interrupts in the hardware before registering the
handler?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=4
^ permalink raw reply
* RE: [PATCH v9 02/12] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:02 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <eb03894ae2765a426457238157e474087ea0aaa6.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 mask, val;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> > + val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
>
> You can use regmap_set_bits() here.
>
Ack.
> > +}
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 val;
>
> unsigned int val;
>
Ack.
> > + int ret;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->descs, data->rcdev.nr_resets and
> > + * data->rcdev.owner before calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + data->regmap = dev_get_platdata(dev);
> > + data->rcdev.ops = &rtk_reset_ops;
> > + data->rcdev.dev = dev;
> > + data->rcdev.of_node = dev->parent->of_node;
>
> This split rcdev initialization is more hassle than it is worth.
> Please just export rtk_reset_ops and duplicate the regmap/ops/dev/of_node
> assignment in the probe functions.
>
> Alternatively, consolidate the probe function and export it from here.
>
Thanks for your suggestion. I will go with your first approach in v10.
Best Regards,
Yu-Chun
> regards
> Philipp
^ permalink raw reply
* RE: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:05 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <9db83aa615f43ff6eac090626b43915fcd593a25.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add support for the ISO (Isolation) domain reset controller on the
> > Realtek
> > RTD1625 SoC.
> >
> > The reset controller shares the same register space with the ISO clock
> > controller. To handle this shared register space, the reset driver is
> > implemented as an auxiliary driver. It will be instantiated and probed
> > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v9:
> > - Extract reset-related code from the previous clock driver patch
> > (formerly patch 9 in v8).
> > ---
> > drivers/reset/realtek/Makefile | 2 +-
> > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > +++++++++++++++++++++++
> > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > drivers/reset/realtek/reset-rtd1625-iso.c
> >
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > 100644
> > --- a/drivers/reset/realtek/Makefile
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -1,3 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +reset-rtd1625-iso.o
>
> Is there any benefit to these two being separate modules?
> I suggest you merge them into one: reset-rtd1625.o
>
If I merge them into a single 'reset-rtd1625' module,
both the 'crt' and 'iso' clock drivers would trigger the probe
process for the same reset driver name, which would lead to a
duplicate driver registration error.
Therefore, I would prefer to keep them separate.
> > diff --git a/drivers/reset/realtek/reset-rtd1625-iso.c
> > b/drivers/reset/realtek/reset-rtd1625-iso.c
> > new file mode 100644
> > index 000000000000..78eaabb408f0
> > --- /dev/null
> > +++ b/drivers/reset/realtek/reset-rtd1625-iso.c
> > @@ -0,0 +1,99 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026 Realtek Semiconductor Corporation */
> > +
> > +#include <dt-bindings/reset/realtek,rtd1625.h>
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/of.h>
> > +#include <linux/slab.h>
> > +#include "reset-rtk-common.h"
> > +
> > +#define RTD1625_ISO_RSTN_MAX 29
> > +#define RTD1625_ISO_S_RSTN_MAX 5
>
> These are not necessary, just use ARRAY_SIZE() for nr_resets.
>
Ack.
> > +
[...]
> > +
> > +static int rtd1625_iso_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct device *dev = &adev->dev;
> > + struct device *parent = dev->parent;
> > + struct rtk_reset_data *data;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + if (of_device_is_compatible(parent->of_node,
> "realtek,rtd1625-iso-s-clk")) {
> > + data->descs = rtd1625_iso_s_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_S_RSTN_MAX;
> > + } else {
> > + data->descs = rtd1625_iso_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_RSTN_MAX;
> > + }
>
> No need to parse OF compatible again. Store these in a struct, point
> auxiliary_device_id::driver_data to it, and use that here.
>
> regards
> Philipp
Agreed, I will do it in v10. Thanks.
Best Regards,
Yu-Chun
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Hennerich, Michael, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <ai_OeEegWavHcNF1@ashevche-desk.local>
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
> Sent: Monday, June 15, 2026 6:06 PM
> To: Paller, Kim Seer <KimSeer.Paller@analog.com>
> Cc: Jonathan Cameron <jic23@kernel.org>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux <linux@analog.com>;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > with AD3530R (channel configuration, LDAC triggering, powerdown
> > control), the main difference being the register address map due to
> > the dual-bank architecture, handled by table-driven helpers.
> >
> > Add AD3532R-specific register definitions, channel specs, per-bank
> > register arrays, a dedicated ad3532r_set_dac_powerdown(), and per-chip
> > regmap_config to limit debugfs-exposed register space to each
> > variant's actual address range.
>
> ...
>
>
> > help
> > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > - Digital to Analog Converter.
> > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
>
> This just shows how unscalable the above text is. That's why we usually
> recommend to make the list explicit and separated.
>
> Say yes here to build support for the following Analog Devices
> Digital to Analog Converters:
> - AD3530/AD3530R (8-channel)
> - AD3531/AD3531R (4-channel)
> - AD3532/AD3532R (16-channel)
>
> (and looking into the C-file change, perhaps add here as well distinctive
> information, such as number of channels, in the parentheses).
>
> > To compile this driver as a module, choose M here: the
> > module will be called ad3530r.
>
> ...
>
> > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > +#define AD3532R_INPUT_CH_0 0x10EB
> > +#define AD3532R_INPUT_CH_1 0x30EB
> > +#define AD3532R_MAX_REG_ADDR 0x30F9
>
> Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes together
> followed by "bank" 1). Jonathan, what's your preference here? Nuno, David?
>
> ...
>
> > +static ssize_t ad3532r_set_dac_powerdown(struct iio_dev *indio_dev,
> > + uintptr_t private,
> > + const struct iio_chan_spec *chan,
> > + const char *buf, size_t len)
> > +{
> > + struct ad3530r_state *st = iio_priv(indio_dev);
> > + unsigned int reg, pdmode, mask, val, local_ch;
> > + bool powerdown;
> > + int ret;
> > +
> > + ret = kstrtobool(buf, &powerdown);
>
> Do you need to include kstrtox.h?
Yes, kstrtobool() is declared in <linux/kstrtox.h>. I also ran IWYU and
it confirms <linux/kstrtox.h> belongs in the include list.
>
> > + if (ret)
> > + return ret;
> > +
> > + guard(mutex)(&st->lock);
>
> + blank line here.
>
> > + local_ch = chan->channel % AD3530R_CH_PER_BANK;
>
> > + reg = (chan->channel < AD3530R_CH_PER_BANK ?
> AD3532R_OUTPUT_OPERATING_MODE_0 :
> > + AD3532R_OUTPUT_OPERATING_MODE_2) +
> > + local_ch / AD3530R_CH_PER_REG;
>
> This is unreadable. Can you refactor it?
Would this be clearer?
unsigned int bank_base;
local_ch = chan->channel % AD3530R_CH_PER_BANK;
bank_base = chan->channel < AD3530R_CH_PER_BANK ?
AD3532R_OUTPUT_OPERATING_MODE_0 : AD3532R_OUTPUT_OPERATING_MODE_2;
reg = bank_base + local_ch / AD3530R_CH_PER_REG;
>
> > + mask = AD3530R_OP_MODE_CHAN_MSK(local_ch %
> AD3530R_CH_PER_REG);
> > +
> > + pdmode = powerdown ? st->chan[chan->channel].powerdown_mode :
> 0;
> > + val = field_prep(mask, pdmode);
> > +
> > + ret = regmap_update_bits(st->regmap, reg, mask, val);
> > + if (ret)
> > + return ret;
> > +
> > + st->chan[chan->channel].powerdown = powerdown;
> > +
> > + return len;
> > +}
>
> ...
>
> > + .num_banks = ARRAY_SIZE(ad3532r_if_config),
>
> Also check if array_size.h is included.
>
> --
> With Best Regards,
> Andy Shevchenko
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 10:07 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <891015c8-68df-4654-b1e7-94d73e74267c@oss.qualcomm.com>
On Wed, 2026-06-24 at 13:00 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:07 PM, Xin Xu wrote:
> > On Mon, 2026-06-22 at 13:40 +0200, Konrad Dybcio wrote:
> > > On 6/19/26 6:07 PM, Xin Xu wrote:
> > > > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > > > using GPIO84 as interrupt and GPIO76 as reset.
> > > >
> > > > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > > > ---
>
> [...]
>
> > > > + pm8008_default: pm8008-default-state {
> > > > + int-pins {
> > > > + pins = "gpio84";
> > > > + function = "gpio";
> > > > + bias-disable;
> > > > + drive-strength = <2>;
> > > > + input-enable;
> > > > + };
> > > > +
> > > > + reset-pins {
> > > > + pins = "gpio76";
> > > > + function = "gpio";
> > > > + bias-pull-up;
> > > > + drive-strength = <2>;
> > > > + output-high;
> > >
> > > Drop output-high, the driver will take care of setting the output
> > > state
> > >
> > > Konrad
> >
> > Thank you for your review!
> >
> > I will fix the coding style issues (blank line before status,
> > interrupts-extended, property order, and dropping output-high)
> > in the next version.
> >
> > I have verified all LDO voltages against the downstream device
> > tree:
> > https://github.com/MiCode/kernel_devicetree/tree/elish-r-oss/
> > The definitions can be found around lines 209–244 in
> > qcom/elish-sm8250-camera-board.dtsi
>
> Thanks. It's best if you grab the DTB from a running device (which
> has all the overlays applied etc.), which you can grab from
> /sys/firmware/fdt
>
> You can then pass that to DTC directly
>
> Konrad
For additional verification, I have extracted the device tree from
/sys/firmware/fdt on a running device. The voltage values match the
ones in my patch exactly. Below is the relevant pm8008 regulator
portion:
qcom,pm8008-regulator {
compatible = "qcom,pm8008-regulator";
pm8008_en-supply = <0x708>;
qcom,enable-ocp-broadcast;
vdd_l1_l2-supply = <0xad>;
vdd_l3_l4-supply = <0x2cf>;
phandle = <0x7e6>;
qcom,pm8008-l1@4000 {
reg = <0x4000>;
regulator-name = "pm8008_l1";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71c>;
};
qcom,pm8008-l2@4100 {
reg = <0x4100>;
regulator-name = "pm8008_l2";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x713>;
};
qcom,pm8008-l3@4200 {
reg = <0x4200>;
regulator-name = "pm8008_l3";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x714>;
};
qcom,pm8008-l4@4300 {
reg = <0x4300>;
regulator-name = "pm8008_l4";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x70e>;
};
qcom,pm8008-l5@4400 {
reg = <0x4400>;
regulator-name = "pm8008_l5";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71b>;
};
qcom,pm8008-l6@4400 {
reg = <0x4500>;
regulator-name = "pm8008_l6";
regulator-min-microvolt = <0x1b7740>; /* 1800000 */
regulator-max-microvolt = <0x1b7740>; /* 1800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x7e7>;
};
qcom,pm8008-l7@4400 {
reg = <0x4600>;
regulator-name = "pm8008_l7";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2c4020>; /* 2900000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x712>;
};
};
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:07 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Sa, Nuno, Andy Shevchenko, Hennerich, Michael,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux,
devicetree@vger.kernel.org
In-Reply-To: <20260621174548.5eca5db6@jic23-huawei>
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, June 22, 2026 12:46 AM
> To: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux
> <linux@analog.com>; devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, 15 Jun 2026 13:05:44 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > > with AD3530R (channel configuration, LDAC triggering, powerdown
> > > control), the main difference being the register address map due to
> > > the dual-bank architecture, handled by table-driven helpers.
> > >
> > > Add AD3532R-specific register definitions, channel specs, per-bank
> > > register arrays, a dedicated ad3532r_set_dac_powerdown(), and
> > > per-chip regmap_config to limit debugfs-exposed register space to
> > > each variant's actual address range.
> >
> > ...
> >
> >
> > > help
> > > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > > - Digital to Analog Converter.
> > > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
> >
> > This just shows how unscalable the above text is. That's why we
> > usually recommend to make the list explicit and separated.
> >
> > Say yes here to build support for the following Analog Devices
> > Digital to Analog Converters:
> > - AD3530/AD3530R (8-channel)
> > - AD3531/AD3531R (4-channel)
> > - AD3532/AD3532R (16-channel)
> >
> > (and looking into the C-file change, perhaps add here as well
> > distinctive information, such as number of channels, in the parentheses).
> >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad3530r.
> >
> > ...
> >
> > > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > > +#define AD3532R_INPUT_CH_0 0x10EB
> > > +#define AD3532R_INPUT_CH_1 0x30EB
> > > +#define AD3532R_MAX_REG_ADDR 0x30F9
> Whilst we are here, Sashiko thinks there is an off by one on that value as it's
> the lower of the two registers that make up channel 15.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260615-iio-
> ad3532r-support-v2-0-
> 84a0af8b83fa*40analog.com__;IyU!!A3Ni8CS0y2Y!88afCOStwucx32wuoeR
> SyZ9GpkZge9YDw5_PIMAf7SLs3OLykUC_qNRDUCnRw7wTwsxiIT1V-
> R8sH17sTg$
> It also suggests an existing bug that it would be good to look into.
I don't think it's off-by-one. INPUT_CHn registers are listed by LSB, so channel 15 is 0x30F8 (LSB) / 0x30F9 (MSB).
The driver addresses the MSB and the part defaults to descending mode, so the access goes 0x30F9 -> 0x30F8.
0x30F9 is also the highest valid address per the datasheet, so max_register looks correct same for AD3530R's 0xF9.
Does that match our understanding, or am I missing a case?
>
> >
> > Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes
> > together followed by "bank" 1). Jonathan, what's your preference here?
> Nuno, David?
> That is how people will typically check them vs the datasheet so I agree with
> numeric order. Maybe with a comment at the top about there effectively
> being two banks. Many of the registers are effectively copies for the new
> channels but not all of them, so a macro approach would probably be even
> more confusing.
>
> Jonathan
^ permalink raw reply
* Re: [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: sashiko-bot @ 2026-06-25 10:10 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, devicetree, robh, dri-devel
In-Reply-To: <20260625094449.708386-6-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The DC8000 panel enable, CRTC begin, and CRTC flush operations use incorrect registers and bits, directly contradicting the commit message and breaking hardware functionality.
- [Medium] The hw_irqs variable is passed to regmap_read() uninitialized and used without checking for read failures.
Pre-existing issues:
- [High] The DC8200 primary plane disable function erroneously sets the enable bit instead of clearing it, keeping the plane active.
- [High] The IRQ handler unconditionally dereferences dc->drm_dev, but the interrupt is enabled before dc->drm_dev is allocated and remains active after it is freed.
--
commit a518460571afb18a0b4ff8e14af894a66907ebde
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
controller (DC8000 generation) whose register layout differs from
the DC8200 in several important ways:
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
[Severity: High]
Do the functions implemented in this patch use the correct registers and bits
as described in the commit message?
In vs_dc8000_panel_enable_ex(), the code sets a reset bit
(VSDC_FB_CONFIG_RESET) in VSDC_FB_CONFIG instead of writing to PANEL_CONFIG.
Additionally, vs_dc8000_crtc_begin() and vs_dc8000_crtc_flush() use an
unmentioned VALID bit (VSDC_FB_CONFIG_VALID), and clear it after updates
complete, which seems to invert normal latch semantics.
Could this mismatch prevent the display panel from enabling properly?
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa1..d2fd8e4dff242 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_dc8000.o vs_drm.o vs_hwdb.o \
[Severity: High]
This is a pre-existing issue, but while reviewing the driver files included
here, I noticed a potential problem in
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex().
The function appears to call regmap_set_bits() on VSDC_FB_CONFIG_EX_FB_EN
instead of regmap_clear_bits():
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex() {
...
regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
VSDC_FB_CONFIG_EX_FB_EN);
...
}
Does this erroneously keep the primary plane active when the DRM framework
expects it to be turned off, potentially breaking power management?
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index fd1f5fe67a68b..9499fffbca58e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
[Severity: High]
This is a pre-existing issue, but I noticed a potential lifecycle regression
in vs_dc_probe() just below this block.
The function calls devm_request_irq() to register vs_dc_irq_handler() before
calling vs_drm_initialize(), which is responsible for allocating and assigning
dc->drm_dev.
If an interrupt fires during this window, for example if the bootloader left
VSYNC interrupts enabled, the handler is invoked:
vs_drm.c:vs_drm_handle_irq() {
...
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
...
}
Will this unconditionally dereference dc->drm_dev and cause a NULL pointer
dereference before vs_drm_initialize() has completed?
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW capability\n");
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 0000000000000..fbe0fa516cac9
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,86 @@
[ ... ]
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
[Severity: Medium]
Is it safe to use hw_irqs here if regmap_read() fails?
If regmap_read() returns an error code, hw_irqs will remain uninitialized
stack memory.
The function then proceeds to bitwise-AND this uninitialized value to
determine which VSYNC interrupts fired:
for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
unified |= VSDC_IRQ_VSYNC(i);
}
Could this result in spurious VSYNC events being dispatched to the DRM core if
a read failure occurs?
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
> +
> + return unified;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-ab2: Enable MU2 for DSP communication
From: Daniel Baluta @ 2026-06-25 10:13 UTC (permalink / raw)
To: shengjiu.wang, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625054709.301209-1-shengjiu.wang@oss.nxp.com>
On 6/25/26 08:47, shengjiu.wang@oss.nxp.com wrote:
> [You don't often get email from shengjiu.wang@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> Enable the MU2 (Message Unit 2) node on the i.MX8MP Audio Board v2.
> MU2 is required for inter-processor communication between the
> application CPU and the HiFi4 DSP, allowing DSP firmware to exchange
> control and status messages with the Linux host.
>
> Without this change, the DSP driver cannot establish the message
> channel and DSP audio processing is non-functional.
>
> Fixes: bf68c18150efc ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Abel Vesa @ 2026-06-25 10:12 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610-eliza_dt-v1-1-7bb72b75fc5b@oss.qualcomm.com>
On 26-06-10 17:40:09, Krishna Chaitanya Chundru wrote:
> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
> the GCC clock references to use the newly added PHY nodes instead of
> placeholder zeros.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> This patch depends on https://lore.kernel.org/all/20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com/
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 359 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 357 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 7e97361a5dc5..2a51da62270d 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -610,8 +610,8 @@ gcc: clock-controller@100000 {
>
> clocks = <&bi_tcxo_div2>,
> <&sleep_clk>,
> - <0>,
> - <0>,
> + <&pcie0_phy>,
> + <&pcie1_phy>,
> <&ufs_mem_phy 0>,
> <&ufs_mem_phy 1>,
> <&ufs_mem_phy 2>,
> @@ -716,6 +716,361 @@ mmss_noc: interconnect@1780000 {
> #interconnect-cells = <2>;
> };
>
> + pcie0: pcie@1c00000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c00000 0 0x3000>,
> + <0 0x40000000 0 0xf1d>,
> + <0 0x40000f20 0 0xa8>,
> + <0 0x40001000 0 0x1000>,
> + <0 0x40100000 0 0x100000>,
> + <0 0x01c03000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x40200000 0 0x100000>,
> + <0x02000000 0 0x40300000 0 0x40300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_0_BCR>,
> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_0 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
> +
> + operating-points-v2 = <&pcie0_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1480 0x1>,
> + <0x100 &apps_smmu 0x1481 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <0>;
> + num-lanes = <1>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
> +
No pinctrl states?
> +
> + pcie1: pcie@1c08000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c08000 0 0x3000>,
> + <0 0x44000000 0 0xf1d>,
> + <0 0x44000f20 0 0xa8>,
> + <0 0x44001000 0 0x1000>,
> + <0 0x44100000 0 0x100000>,
> + <0 0x01c0b000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_1_BCR>,
> + <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_1 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_1 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_1_GDSC>;
> +
> + operating-points-v2 = <&pcie1_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1400 0x1>,
> + <0x100 &apps_smmu 0x1401 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <1>;
> + num-lanes = <2>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
No pinctrl states?
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Konrad Dybcio @ 2026-06-25 10:18 UTC (permalink / raw)
To: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio
Cc: Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On 6/23/26 4:52 PM, Hans de Goede wrote:
> Hi All,
>
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.
>
> It might still be interesting to at least parse the ACPI tables and make
> the ACPI fwnodes available for device-drivers to use. I call this DT-ACPI
> hybrid mode.
>
> This mainly is an experiment for now and possibly a method for accelerating
> the ongoing effort to run Linux on currently available Snapdragon laptops.
I like the part where the ACPI tables are parsed and are visible to
Linux (so that the user can e.g. do acpidump even though DT is in use,
since the tables are in memory anyway)
I think the 'hybrid enumeration path' is a cool technical experiment,
which lets the user skip _some parts_ of writing a device tree, but
the benefits are too minor - we can only make use of this for devices
that already have ACPI support in Linux and whose nodes fit within the
"describe the actual hw and how it's wired up, not the functions it
exposes" model (because on Windows that all ends up being hijacked by
the PEP driver or something similar in the chain).
This is natural for DT, but not so much for ACPI
The hid-over-i2c example you gave looks useful on the surface, but
if the user already has to have the knowledge and skills to grab and
decompile the tables, assess the right path for the device and still
have to put it in the DT (which again, they would have had to create
at this point) after all, they may as well take the 40 extra seconds
as a single-time cost to fill in the i2c address and interrupt source
to create a valid/full DT node.
The path lookup mechanisms relies on the paths remaining stable,
which I would assume should be the case, but I wouldn't bet money
on it _always_ being the case.
To put it simply, I don't think we should spend time on trying to
forcefully make the incomplete (actually incomplete, since Windows
today loads ACPI fragments sourced from Windows Update at runtime
and relies on many drivers having hardcoded data) DSDTs be any
useful, because in their current form, we would need to rely on
quasi-boardfiles for most things anyway.
If we need to provide the firmware description (DT) externally
anyway, let's just stick to that alone.
Konrad
^ permalink raw reply
* Re: [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: sashiko-bot @ 2026-06-25 10:22 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, robh, devicetree, dri-devel
In-Reply-To: <20260625094449.708386-7-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added DCUltraLite chip restricts the max cursor size to 32x32, but the driver does not configure `drm->mode_config.cursor_width` or `cursor_height`. DRM core defaults to 64x64 when these fields are 0. This incorrectly exposes a `DRM_CAP_CURSOR_WIDTH` of 64 to userspace, causing atomic commits with 64x64 hardware cursors to be rejected with `-EINVAL`, breaking display compositors.
--
commit a3c0d8a714c977c54ec25009535f44e9ded7c881
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DCUltraLite chip identity to HWDB
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 91524d16f7785..7d630a667a3f0 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -129,6 +129,16 @@ static struct vs_chip_identity vs_chip_identities[] = {
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = 0x0, /* DCUltraLite */
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .generation = VSDC_GEN_DC8000,
> + .display_count = 1,
> + .max_cursor_size = 32,
[Severity: High]
Does this code expose an incorrect DRM_CAP_CURSOR_WIDTH to userspace?
Looking at vs_mode_config_init() in drivers/gpu/drm/verisilicon/vs_drm.c,
the driver does not seem to configure drm->mode_config.cursor_width or
cursor_height:
drivers/gpu/drm/verisilicon/vs_drm.c:vs_mode_config_init() {
...
drm->mode_config.helper_private = &vs_mode_config_helper_funcs;
}
When these fields are 0, the DRM core defaults to 64x64. This means userspace
compositors might query the capability, receive 64x64, and attempt to commit
a 64x64 hardware cursor.
If this new chip restricts the max cursor size to 32x32, will the driver's
atomic check reject the 64x64 state and break display compositors?
> + .formats = &vs_formats_no_yuv444,
> + },
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Philipp Zabel @ 2026-06-25 10:22 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], mturquette@baylibre.com,
sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Edgar Lee [李承諭],
afaerber@suse.com, Jyan Chou [周芷安],
bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <f3b747e20110424c8a434cbd271edb87@realtek.com>
On Do, 2026-06-25 at 10:05 +0000, Yu-Chun Lin [林祐君] wrote:
> Hi Philipp,
>
> > On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > > From: Cheng-Yu Lee <cylee12@realtek.com>
> > >
> > > Add support for the ISO (Isolation) domain reset controller on the
> > > Realtek
> > > RTD1625 SoC.
> > >
> > > The reset controller shares the same register space with the ISO clock
> > > controller. To handle this shared register space, the reset driver is
> > > implemented as an auxiliary driver. It will be instantiated and probed
> > > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> > >
> > > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > ---
> > > Changes in v9:
> > > - Extract reset-related code from the previous clock driver patch
> > > (formerly patch 9 in v8).
> > > ---
> > > drivers/reset/realtek/Makefile | 2 +-
> > > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > > +++++++++++++++++++++++
> > > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > > drivers/reset/realtek/reset-rtd1625-iso.c
> > >
> > > diff --git a/drivers/reset/realtek/Makefile
> > > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > > 100644
> > > --- a/drivers/reset/realtek/Makefile
> > > +++ b/drivers/reset/realtek/Makefile
> > > @@ -1,3 +1,3 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +reset-rtd1625-iso.o
> >
> > Is there any benefit to these two being separate modules?
> > I suggest you merge them into one: reset-rtd1625.o
> >
>
> If I merge them into a single 'reset-rtd1625' module,
> both the 'crt' and 'iso' clock drivers would trigger the probe
> process for the same reset driver name, which would lead to a
> duplicate driver registration error.
What do you mean by duplicate driver registration error?
There would only be one auxiliary_driver, with support for all three
auxiliary_device_id's.
regards
Philipp
^ permalink raw reply
* [PATCH] dt-bindings: arm: qcom: sort compatibles alphabetically by base SoC
From: Kathiravan Thirumoorthy @ 2026-06-25 10:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio,
Kathiravan Thirumoorthy
The compatible entries in qcom.yaml were not in alphabetical order by
their base SoC compatible string (the last const: qcom,* in each block),
making the file harder to audit and maintain. Sort the entries for
better maintenance.
No functional change; reordering only.
Assisted-by: Claude:claude-sonnet-4-6
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 490 ++++++++++++------------
1 file changed, 245 insertions(+), 245 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..dfbc82377fcf 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -49,18 +49,31 @@ properties:
- qcom,apq8074-dragonboard
- const: qcom,apq8074
- - items:
- - enum:
- - qcom,apq8060-dragonboard
- - qcom,msm8660-surf
- - const: qcom,msm8660
-
- items:
- enum:
- qcom,apq8084-mtp
- qcom,apq8084-sbc
- const: qcom,apq8084
+ - items:
+ - enum:
+ - sony,karin_windy
+ - const: qcom,apq8094
+
+ - items:
+ - enum:
+ - arrow,apq8096-db820c
+ - inforce,ifc6640
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096
+
+ - items:
+ - const: arrow,apq8096sg-db820c
+ - const: arrow,apq8096-db820c
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096sg
+ - const: qcom,apq8096
+
- items:
- enum:
- qcom,eliza-mtp
@@ -73,102 +86,126 @@ properties:
- items:
- enum:
- - qcom,mahua-crd
- - const: qcom,mahua
+ - 8dev,jalapeno
+ - alfa-network,ap120c-ac
+ - const: qcom,ipq4018
- items:
- enum:
- - fairphone,fp6
- - nothing,asteroids
- - const: qcom,milos
+ - qcom,ipq4019-ap-dk01.1-c1
+ - qcom,ipq4019-ap-dk04.1-c3
+ - qcom,ipq4019-ap-dk07.1-c1
+ - qcom,ipq4019-ap-dk07.1-c2
+ - qcom,ipq4019-dk04.1-c1
+ - const: qcom,ipq4019
- items:
- enum:
- - microsoft,dempsey
- - microsoft,makepeace
- - microsoft,moneypenny
- - motorola,falcon
- - samsung,ms013g
- - samsung,s3ve3g
- - const: qcom,msm8226
+ - qcom,ipq5018-rdp432-c2
+ - tplink,archer-ax55-v1
+ - const: qcom,ipq5018
- items:
- enum:
- - htc,memul
- - microsoft,superman-lte
- - microsoft,tesla
- - motorola,peregrine
- - samsung,matisselte
- - const: qcom,msm8926
- - const: qcom,msm8226
+ - qcom,ipq5210-rdp504
+ - const: qcom,ipq5210
- items:
- enum:
- - wingtech,wt82918hd
- - const: qcom,msm8929
+ - qcom,ipq5332-ap-mi01.2
+ - qcom,ipq5332-ap-mi01.3
+ - qcom,ipq5332-ap-mi01.6
+ - qcom,ipq5332-ap-mi01.9
+ - const: qcom,ipq5332
- items:
- enum:
- - asus,z00t
- - huawei,kiwi
- - longcheer,l9100
- - samsung,a7
- - sony,kanuti-tulip
- - square,apq8039-t2
- - wingtech,wt82918
- - wingtech,wt82918hdhw39
- - const: qcom,msm8939
+ - qcom,ipq5424-rdp466
+ - const: qcom,ipq5424
- items:
- enum:
- - sony,kugo-row
- - sony,suzu-row
- - const: qcom,msm8956
+ - qcom,ipq6018-cp01
+ - qcom,ipq6018-cp01-c1
+ - const: qcom,ipq6018
- items:
- enum:
- - qcom,msm8960-cdp
- - samsung,expressatt
- - const: qcom,msm8960
+ - mikrotik,rb3011
+ - qcom,ipq8064-ap148
+ - const: qcom,ipq8064
- items:
- enum:
- - sony,huashan
- - const: qcom,msm8960t
- - const: qcom,msm8960
+ - qcom,ipq8074-hk01
+ - qcom,ipq8074-hk10-c1
+ - qcom,ipq8074-hk10-c2
+ - const: qcom,ipq8074
- items:
- enum:
- - lge,hammerhead
- - samsung,hlte
- - sony,xperia-amami
- - sony,xperia-honami
- - sony,xperia-togari
- - const: qcom,msm8974
+ - qcom,ipq9574-ap-al02-c2
+ - qcom,ipq9574-ap-al02-c2-emmc
+ - qcom,ipq9574-ap-al02-c6
+ - qcom,ipq9574-ap-al02-c7
+ - qcom,ipq9574-ap-al02-c7-emmc
+ - qcom,ipq9574-ap-al02-c8
+ - qcom,ipq9574-ap-al02-c9
+ - const: qcom,ipq9574
- items:
- enum:
- - fairphone,fp2
- - htc,m8
- - oneplus,bacon
- - samsung,klte
- - sony,xperia-aries
- - sony,xperia-castor
- - sony,xperia-leo
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,ipq9650-rdp488
+ - const: qcom,ipq9650
- items:
- enum:
- - samsung,kltechn
- - const: samsung,klte
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,kaanapali-mtp
+ - qcom,kaanapali-qrd
+ - const: qcom,kaanapali
- items:
- enum:
- - longcheer,l9360
- - const: qcom,msm8976
+ - qcom,mahua-crd
+ - const: qcom,mahua
+
+ - description: Sierra Wireless MangOH Green with WP8548 Module
+ items:
+ - const: swir,mangoh-green-wp8548
+ - const: swir,wp8548
+ - const: qcom,mdm9615
+
+ - items:
+ - enum:
+ - fairphone,fp6
+ - nothing,asteroids
+ - const: qcom,milos
+
+ - items:
+ - enum:
+ - microsoft,dempsey
+ - microsoft,makepeace
+ - microsoft,moneypenny
+ - motorola,falcon
+ - samsung,ms013g
+ - samsung,s3ve3g
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - htc,memul
+ - microsoft,superman-lte
+ - microsoft,tesla
+ - motorola,peregrine
+ - samsung,matisselte
+ - const: qcom,msm8926
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - qcom,apq8060-dragonboard
+ - qcom,msm8660-surf
+ - const: qcom,msm8660
- items:
- enum:
@@ -217,11 +254,28 @@ properties:
- xiaomi,tiare
- const: qcom,msm8917
+ - items:
+ - enum:
+ - wingtech,wt82918hd
+ - const: qcom,msm8929
+
- items:
- enum:
- xiaomi,land
- const: qcom,msm8937
+ - items:
+ - enum:
+ - asus,z00t
+ - huawei,kiwi
+ - longcheer,l9100
+ - samsung,a7
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - wingtech,wt82918
+ - wingtech,wt82918hdhw39
+ - const: qcom,msm8939
+
- items:
- enum:
- flipkart,rimob
@@ -232,6 +286,57 @@ properties:
- xiaomi,vince
- const: qcom,msm8953
+ - items:
+ - enum:
+ - sony,kugo-row
+ - sony,suzu-row
+ - const: qcom,msm8956
+
+ - items:
+ - enum:
+ - qcom,msm8960-cdp
+ - samsung,expressatt
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - sony,huashan
+ - const: qcom,msm8960t
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - lge,hammerhead
+ - samsung,hlte
+ - sony,xperia-amami
+ - sony,xperia-honami
+ - sony,xperia-togari
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - fairphone,fp2
+ - htc,m8
+ - oneplus,bacon
+ - samsung,klte
+ - sony,xperia-aries
+ - sony,xperia-castor
+ - sony,xperia-leo
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - samsung,kltechn
+ - const: samsung,klte
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - longcheer,l9360
+ - const: qcom,msm8976
+
- items:
- enum:
- lg,bullhead
@@ -240,11 +345,6 @@ properties:
- xiaomi,libra
- const: qcom,msm8992
- - items:
- - enum:
- - sony,karin_windy
- - const: qcom,apq8094
-
- items:
- enum:
- huawei,angler
@@ -256,20 +356,6 @@ properties:
- sony,suzuran-row
- const: qcom,msm8994
- - items:
- - enum:
- - arrow,apq8096-db820c
- - inforce,ifc6640
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096
-
- - items:
- - const: arrow,apq8096sg-db820c
- - const: arrow,apq8096-db820c
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096sg
- - const: qcom,apq8096
-
- items:
- enum:
- oneplus,oneplus3
@@ -303,86 +389,6 @@ properties:
- xiaomi,sagit
- const: qcom,msm8998
- - items:
- - enum:
- - 8dev,jalapeno
- - alfa-network,ap120c-ac
- - const: qcom,ipq4018
-
- - items:
- - enum:
- - qcom,ipq4019-ap-dk01.1-c1
- - qcom,ipq4019-ap-dk04.1-c3
- - qcom,ipq4019-ap-dk07.1-c1
- - qcom,ipq4019-ap-dk07.1-c2
- - qcom,ipq4019-dk04.1-c1
- - const: qcom,ipq4019
-
- - items:
- - enum:
- - qcom,ipq5018-rdp432-c2
- - tplink,archer-ax55-v1
- - const: qcom,ipq5018
-
- - items:
- - enum:
- - qcom,ipq5210-rdp504
- - const: qcom,ipq5210
-
- - items:
- - enum:
- - qcom,ipq5332-ap-mi01.2
- - qcom,ipq5332-ap-mi01.3
- - qcom,ipq5332-ap-mi01.6
- - qcom,ipq5332-ap-mi01.9
- - const: qcom,ipq5332
-
- - items:
- - enum:
- - qcom,ipq5424-rdp466
- - const: qcom,ipq5424
-
- - items:
- - enum:
- - mikrotik,rb3011
- - qcom,ipq8064-ap148
- - const: qcom,ipq8064
-
- - items:
- - enum:
- - qcom,ipq8074-hk01
- - qcom,ipq8074-hk10-c1
- - qcom,ipq8074-hk10-c2
- - const: qcom,ipq8074
-
- - items:
- - enum:
- - qcom,ipq9574-ap-al02-c2
- - qcom,ipq9574-ap-al02-c2-emmc
- - qcom,ipq9574-ap-al02-c6
- - qcom,ipq9574-ap-al02-c7
- - qcom,ipq9574-ap-al02-c7-emmc
- - qcom,ipq9574-ap-al02-c8
- - qcom,ipq9574-ap-al02-c9
- - const: qcom,ipq9574
-
- - items:
- - enum:
- - qcom,ipq9650-rdp488
- - const: qcom,ipq9650
-
- - items:
- - enum:
- - qcom,kaanapali-mtp
- - qcom,kaanapali-qrd
- - const: qcom,kaanapali
-
- - description: Sierra Wireless MangOH Green with WP8548 Module
- items:
- - const: swir,mangoh-green-wp8548
- - const: swir,wp8548
- - const: qcom,mdm9615
-
- description: Qualcomm Technologies, Inc. Robotics RB1
items:
- enum:
@@ -403,6 +409,20 @@ properties:
- thundercomm,rubikpi3
- const: qcom,qcm6490
+ - items:
+ - enum:
+ - qcom,qcs404-evb-1000
+ - qcom,qcs404-evb-4000
+ - const: qcom,qcs404-evb
+ - const: qcom,qcs404
+
+ - items:
+ - enum:
+ - arduino,monza
+ - qcom,monaco-evk
+ - qcom,qcs8300-ride
+ - const: qcom,qcs8300
+
- description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
items:
- enum:
@@ -416,6 +436,31 @@ properties:
- qcom,qru1000-idp
- const: qcom,qru1000
+ - items:
+ - enum:
+ - qcom,sa8155p-adp
+ - const: qcom,sa8155p
+
+ - items:
+ - enum:
+ - qcom,sa8295p-adp
+ - qcom,sa8540p-ride
+ - const: qcom,sa8540p
+
+ - items:
+ - enum:
+ - qcom,sa8775p-ride
+ - qcom,sa8775p-ride-r3
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
+ - qcom,lemans-evk
+ - qcom,qcs9100-ride
+ - qcom,qcs9100-ride-r3
+ - const: qcom,qcs9100
+ - const: qcom,sa8775p
+
- description: Qualcomm AR2 Gen1 platform
items:
- enum:
@@ -828,14 +873,6 @@ properties:
- const: google,zombie-sku514
- const: qcom,sc7280
- - description: Xiaomi Poco F1
- items:
- - enum:
- - xiaomi,beryllium-ebbg
- - xiaomi,beryllium-tianma
- - const: xiaomi,beryllium
- - const: qcom,sdm845
-
- items:
- enum:
- lenovo,flex-5g
@@ -853,6 +890,11 @@ properties:
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
+ - items:
+ - enum:
+ - inforce,ifc6560
+ - const: qcom,sda660
+
- items:
- enum:
- lenovo,tbx605f
@@ -867,11 +909,6 @@ properties:
- sony,voyager-row
- const: qcom,sdm630
- - items:
- - enum:
- - inforce,ifc6560
- - const: qcom,sda660
-
- items:
- enum:
- fairphone,fp3
@@ -899,74 +936,13 @@ properties:
- const: google,bonito
- const: qcom,sdm670
- - items:
- - enum:
- - qcom,sdx55-mtp
- - qcom,sdx55-telit-fn980-tlb
- - qcom,sdx55-t55
- - const: qcom,sdx55
-
- - items:
- - enum:
- - qcom,sdx65-mtp
- - const: qcom,sdx65
-
- - items:
- - enum:
- - qcom,sdx75-idp
- - const: qcom,sdx75
-
- - items:
- - enum:
- - qcom,ipq6018-cp01
- - qcom,ipq6018-cp01-c1
- - const: qcom,ipq6018
-
- - items:
- - enum:
- - qcom,qcs404-evb-1000
- - qcom,qcs404-evb-4000
- - const: qcom,qcs404-evb
- - const: qcom,qcs404
-
- - items:
- - enum:
- - arduino,monza
- - qcom,monaco-evk
- - qcom,qcs8300-ride
- - const: qcom,qcs8300
-
- - items:
- - enum:
- - qcom,qcs615-ride
- - qcom,talos-evk
- - const: qcom,qcs615
- - const: qcom,sm6150
-
- - items:
- - enum:
- - qcom,sa8155p-adp
- - const: qcom,sa8155p
-
- - items:
- - enum:
- - qcom,sa8295p-adp
- - qcom,sa8540p-ride
- - const: qcom,sa8540p
-
- - items:
- - enum:
- - qcom,sa8775p-ride
- - qcom,sa8775p-ride-r3
- - const: qcom,sa8775p
-
- - items:
+ - description: Xiaomi Poco F1
+ items:
- enum:
- - qcom,lemans-evk
- - qcom,qcs9100-ride
- - qcom,qcs9100-ride-r3
- - const: qcom,qcs9100
- - const: qcom,sa8775p
+ - xiaomi,beryllium-ebbg
+ - xiaomi,beryllium-tianma
+ - const: xiaomi,beryllium
+ - const: qcom,sdm845
- items:
- enum:
@@ -989,6 +965,23 @@ properties:
- xiaomi,polaris
- const: qcom,sdm845
+ - items:
+ - enum:
+ - qcom,sdx55-mtp
+ - qcom,sdx55-telit-fn980-tlb
+ - qcom,sdx55-t55
+ - const: qcom,sdx55
+
+ - items:
+ - enum:
+ - qcom,sdx65-mtp
+ - const: qcom,sdx65
+
+ - items:
+ - enum:
+ - qcom,sdx75-idp
+ - const: qcom,sdx75
+
- items:
- enum:
- oneplus,billie2
@@ -1024,6 +1017,13 @@ properties:
- xiaomi,willow
- const: qcom,sm6125
+ - items:
+ - enum:
+ - qcom,qcs615-ride
+ - qcom,talos-evk
+ - const: qcom,qcs615
+ - const: qcom,sm6150
+
- items:
- enum:
- sony,pdx213
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260623-reorg_qcom_binding-0648bdef8db8
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 10:34 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, linux-input, lee, linux-leds, robh, conor+dt,
devicetree
In-Reply-To: <20260625081812.33474-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The YAML schema introduces a `ports` wrapper node for the `audio-codec`, which conflicts with the original TXT binding and existing device trees that define `port@X` directly as children.
- [Medium] The schema explicitly expects the power button subnode to be named exactly `key-power`, but the in-tree device tree uses `button`.
- [Medium] The `spi-cs-high` property, which is physically required by the hardware and was explicitly listed as required in the legacy text binding, has been omitted from the `required` list in the YAML schema.
--
commit 30a40e2d4eb937fd9bbca306ed8246e061a54ab4
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
[Severity: Medium]
Will this break validation for existing device trees?
The legacy text binding example shows port@0 and port@1 directly under the
audio-codec node, but this schema requires them to be wrapped in a ports
node. Because additionalProperties is set to false on audio-codec, direct
port@X nodes in existing device trees will be rejected.
[ ... ]
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
[Severity: Medium]
Is it intentional to restrict the subnode name strictly to key-power?
Existing in-tree device trees use button for this node. By strictly matching
key-power, existing configurations will be rejected as an undocumented
property during schema validation.
[ ... ]
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
[Severity: Medium]
Does this schema incorrectly omit spi-cs-high from the required list?
The legacy text binding explicitly listed spi-cs-high as a required property.
Without it, incomplete device trees lacking this hardware-critical property
will incorrectly pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=3
^ 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