* [PATCH 05/15] dt-bindings: display: ti,am65x-dss: Add AM62P DSS
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
TI's AM62P, J722S and AM67A SoCs contain same implementation of the
display subsystem (DSS). There are two instances of the DSS (DSS0 and
DSS1), each with two video ports (VP) and two video planes.
Additionally the SoCs contain two OLDI TXes (OLDI0 and OLDI1), a MIPI
DSI TX and a MIPI DPI output path.
DSS0 supports:
- VP0: OLDI0 in single-link mode, or OLDI0 and OLDI1 in dual-link or
clone mode.
- VP1: DPI
DSS1 supports:
- VP0: OLDI1 in single-link mode, or DPI
- VP1: DPI or DSI
The DSI is only connected to VP1 of DSS1, but OLDI and DPI are shared
between the DSS instances. Thus only a single VP can output to DPI, and
a single VP can use an OLDI block. Note that in single-link
configuration OLDI0 can be used by DSS0, and at the same time OLDI1 can
be used by DSS1.
The DSS IP itself is compatible with older SoCs. While we could use
"ti,am625-dss" compatible string, we add a new one "ti,am62p-dss" to be
on the safe side in case the driver needs to do something special for
the dual-DSS case in the future.
Original patch by Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
.../bindings/display/ti/ti,am65x-dss.yaml | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 588d72d4ec0d..fe6cbfa7cc8f 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -28,11 +28,38 @@ description: |
On AM62A7, the first VP is tied off in the SoC, and the second VP is routed to
external MIPI DPI pins.
+ AM62P SoC contains two instances of the DSS:
+ On AM62P DSS0, the first VP is connected to two OLDI TX instances (the second
+ TX shared with DSS1), the second VP to external MIPI DPI pins (shared with
+ DSS1).
+ On AM62P DSS1, the first VP is connected either to the second OLDI TX, or
+ external MIPI DPI pins. The second VP is connected to either the external MIPI
+ DPI pins or a Cadence DSI TX.
+
+ An important note about OLDIs on AM62P:
+
+ There are two OLDI hardware blocks. Each OLDI has certain configuration that
+ has to be done before it can be used. The OLDI blocks get this configuration
+ directly from the DSS block, via DSS registers. However, as a single OLDI
+ block can be used either with DSS0 or DSS1, the source for the configuration
+ changes according to a mux. This mux is set according to the OLDI
+ configuration registers in DSS0. Thus the OLDI control paths change at
+ runtime, and it is not obvious how to structure this in the DT bindings.
+
+ The solution used here is that each DSS node contains the OLDI nodes that can
+ be used with that DSS. Thus the DSS0 node has two OLDI child nodes, OLDI0 and
+ OLDI1, and the DSS1 node has one OLDI child node, OLDI1, so three OLDI DT
+ nodes in total. The two OLDI1 nodes thus refer to the same piece of hardware,
+ and they cannot be used at the same time. The selection which OLDI nodes to
+ use are chosen in the board dts files, so assuming the dts files are correct,
+ no resource conflict can happen.
+
properties:
compatible:
enum:
- ti,am625-dss
- ti,am62a7-dss
+ - ti,am62p-dss
- ti,am65x-dss
reg:
--
2.43.0
^ permalink raw reply related
* [PATCH 00/15] drm/tidss: Add BeagleY-AI display support (and some more)
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Jayesh Choudhary, Aradhya Bhatia, Andrew Davis
This series aims to add display support for all display interfaces on
BeagleY-AI board. More generally, it adds display support for TI AM62P,
J722S, and related SoCs, and, as a bit extra, improves AM62L's DPI
handling.
The main topics to highlight:
- The ti,am625-dss-dpi0-clk-ctrl feels a bit like a hack.
But it is a single quirk register, among other registers that belong
to either the firmware or other drivers. So what other options are
there? This has already been discussed e.g. in
https://lore.kernel.org/all/20250730-fix-edge-handling-v1-0-1bdfb3fe7922%40bootlin.com/
without proper conclusion.
- The tidss OLDI support will now use auxiliary device/driver. This seems
to solve quite neatly the requirement to have a power-domain for each
OLDI. The main issue that remains is that on AM62P (and similar) we
will have three OLDI TX DT nodes, even if there are only two in the
hardware.
With this series one can use the HDMI output on BeagleY-AI. I have also
tested the DSI output with Raspberry Pi's 7" DSI display, and OLDI
output with an oscilloscope (I don't have a suitable OLDI panel).
Tomi
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Andrew Davis (1):
arm64: dts: ti: beagley-ai: Enable HDMI display and audio
Jayesh Choudhary (1):
arm64: dts: ti: k3-am62p-j722s-common-main: Add support for DSS
Swamil Jain (1):
drm/tidss: Add support for AM62P display subsystem
Tomi Valkeinen (12):
dt-bindings: display: ti: Move ti,am62l-dss binding to a new binding file
dt-bindings: display: ti,am65x-dss: Simplify binding
dt-bindings: mfd: syscon: Add ti,am625-dss-dpi0-clk-ctrl compatible
dt-bindings: display: ti,am625-oldi: Add optional power-domain for OLDI
dt-bindings: display: ti,am65x-dss: Add AM62P DSS
drm/tidss: Remove extra pm_runtime_mark_last_busy
drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
drm/tidss: Add mechanism to detect DPI output
drm/tidss: Add external data and sync signal edge configuration
drm/tidss: Add support for DPIENABLE bit
drm/tidss: oldi: Fix OLDI signal polarities
drm/tidss: oldi: Convert OLDI to an aux driver
.../bindings/display/ti/ti,am625-oldi.yaml | 4 +
.../bindings/display/ti/ti,am62l-dss.yaml | 136 ++++++
.../bindings/display/ti/ti,am65x-dss.yaml | 176 +++----
Documentation/devicetree/bindings/mfd/syscon.yaml | 2 +
MAINTAINERS | 1 +
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 112 +++++
arch/arm64/boot/dts/ti/k3-am62p.dtsi | 16 +
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 197 ++++++++
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 16 +
drivers/gpu/drm/tidss/tidss_crtc.c | 10 +-
drivers/gpu/drm/tidss/tidss_crtc.h | 4 +-
drivers/gpu/drm/tidss/tidss_dispc.c | 46 +-
drivers/gpu/drm/tidss/tidss_dispc.h | 5 +-
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 5 +
drivers/gpu/drm/tidss/tidss_drv.c | 54 ++-
drivers/gpu/drm/tidss/tidss_drv.h | 5 +-
drivers/gpu/drm/tidss/tidss_kms.c | 55 ++-
drivers/gpu/drm/tidss/tidss_oldi.c | 531 +++++++++++++++------
drivers/gpu/drm/tidss/tidss_oldi.h | 8 +-
19 files changed, 1095 insertions(+), 288 deletions(-)
---
base-commit: 3131ff5a117498bb4b9db3a238bb311cbf8383ce
change-id: 20260420-beagley-ai-display-d7f634cde5f4
prerequisite-message-id: <20260415110409.2577633-1-s-jain1@ti.com>
prerequisite-patch-id: 654d90f9cddec8b41e6fb1b3776a632606fef88c
Best regards,
--
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
^ permalink raw reply
* [PATCH 07/15] drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
OLDI_LB_CTRL define is not used, and doesn't seem to exist at least on
some SoCs. Let's remove the define.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_oldi.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_oldi.h b/drivers/gpu/drm/tidss/tidss_oldi.h
index 8cd535c5ee65..a361e6dbfce3 100644
--- a/drivers/gpu/drm/tidss/tidss_oldi.h
+++ b/drivers/gpu/drm/tidss/tidss_oldi.h
@@ -20,7 +20,6 @@ struct tidss_oldi;
/* Register offsets */
#define OLDI_PD_CTRL 0x100
-#define OLDI_LB_CTRL 0x104
/* Power control bits */
#define OLDI_PWRDOWN_TX(n) BIT(n)
--
2.43.0
^ permalink raw reply related
* [PATCH 08/15] drm/tidss: Add mechanism to detect DPI output
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
There are situations where the driver needs to know if the output is
going to the DPI output or not. There is no trivial way to get this
information, as there is no "DPI bridge". We can only find this out in
reverse: check if the output is NOT DPI, and if that is negative, then
it must be DPI.
At the moment we have two non-DPI outputs: DSI and OLDI. DSI always has
"ti,j721e-dsi" DSI bridge connected to the DSI, so we can use that for
checking. OLDI doesn't have a compatible property, but we can check if
the DT node has "oldi-transmitters" node as a parent, and the dss node
itself as a grand-parent.
If the output is not connected to either of the above, it must be DPI.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_crtc.c | 10 +++++--
drivers/gpu/drm/tidss/tidss_crtc.h | 4 ++-
drivers/gpu/drm/tidss/tidss_dispc.c | 5 +++-
drivers/gpu/drm/tidss/tidss_dispc.h | 3 +-
drivers/gpu/drm/tidss/tidss_kms.c | 55 ++++++++++++++++++++++++++++++++++++-
5 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
index a31c21c5f855..dfdf61b01dcd 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -192,7 +192,8 @@ static void tidss_crtc_atomic_flush(struct drm_crtc *crtc,
return;
/* Write vp properties to HW if needed. */
- dispc_vp_setup(tidss->dispc, tcrtc->hw_videoport, crtc->state, false);
+ dispc_vp_setup(tidss->dispc, tcrtc->hw_videoport, crtc->state, false,
+ tcrtc->dpi_output);
/* Update plane positions if needed. */
tidss_crtc_position_planes(tidss, crtc, old_crtc_state, false);
@@ -235,7 +236,8 @@ static void tidss_crtc_atomic_enable(struct drm_crtc *crtc,
if (r != 0)
return;
- dispc_vp_setup(tidss->dispc, tcrtc->hw_videoport, crtc->state, true);
+ dispc_vp_setup(tidss->dispc, tcrtc->hw_videoport, crtc->state, true,
+ tcrtc->dpi_output);
tidss_crtc_position_planes(tidss, crtc, old_state, true);
/* Turn vertical blanking interrupt reporting on. */
@@ -417,7 +419,8 @@ static const struct drm_crtc_funcs tidss_crtc_funcs = {
struct tidss_crtc *tidss_crtc_create(struct tidss_device *tidss,
u32 hw_videoport,
- struct drm_plane *primary)
+ struct drm_plane *primary,
+ bool dpi_output)
{
struct tidss_crtc *tcrtc;
struct drm_crtc *crtc;
@@ -430,6 +433,7 @@ struct tidss_crtc *tidss_crtc_create(struct tidss_device *tidss,
return ERR_PTR(-ENOMEM);
tcrtc->hw_videoport = hw_videoport;
+ tcrtc->dpi_output = dpi_output;
init_completion(&tcrtc->framedone_completion);
crtc = &tcrtc->crtc;
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.h b/drivers/gpu/drm/tidss/tidss_crtc.h
index 040d1205496b..65df220698f6 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.h
+++ b/drivers/gpu/drm/tidss/tidss_crtc.h
@@ -20,6 +20,7 @@ struct tidss_crtc {
struct drm_crtc crtc;
u32 hw_videoport;
+ bool dpi_output;
struct drm_pending_vblank_event *event;
@@ -44,5 +45,6 @@ void tidss_crtc_error_irq(struct drm_crtc *crtc, u64 irqstatus);
struct tidss_crtc *tidss_crtc_create(struct tidss_device *tidss,
u32 hw_videoport,
- struct drm_plane *primary);
+ struct drm_plane *primary,
+ bool dpi_output);
#endif
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
index 58d5eb033bdb..c21ac3f51720 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -448,6 +448,7 @@ static const u16 *dispc_common_regmap;
struct dss_vp_data {
u32 *gamma_table;
+ bool dpi_output;
};
struct dispc_device {
@@ -2770,8 +2771,10 @@ static void dispc_vp_set_color_mgmt(struct dispc_device *dispc,
}
void dispc_vp_setup(struct dispc_device *dispc, u32 hw_videoport,
- const struct drm_crtc_state *state, bool newmodeset)
+ const struct drm_crtc_state *state, bool newmodeset,
+ bool dpi_output)
{
+ dispc->vp_data[hw_videoport].dpi_output = dpi_output;
dispc_vp_set_default_color(dispc, hw_videoport, 0);
dispc_vp_set_color_mgmt(dispc, hw_videoport, state, newmodeset);
}
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h b/drivers/gpu/drm/tidss/tidss_dispc.h
index 739d211d0018..6f53d554259c 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -131,7 +131,8 @@ void dispc_vp_disable_clk(struct dispc_device *dispc, u32 hw_videoport);
int dispc_vp_set_clk_rate(struct dispc_device *dispc, u32 hw_videoport,
unsigned long rate);
void dispc_vp_setup(struct dispc_device *dispc, u32 hw_videoport,
- const struct drm_crtc_state *state, bool newmodeset);
+ const struct drm_crtc_state *state, bool newmodeset,
+ bool dpi_output);
int dispc_runtime_suspend(struct dispc_device *dispc);
int dispc_runtime_resume(struct dispc_device *dispc);
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c b/drivers/gpu/drm/tidss/tidss_kms.c
index 8bb93194e5ac..bc8b10af9a48 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -122,6 +122,50 @@ static const struct drm_mode_config_funcs mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
+static const char * const tidss_internal_bridge_compatibles[] = {
+ "ti,j721e-dsi",
+};
+
+/*
+ * Detect whether the bridge is internal to the SoC or not. This is needed
+ * to find out whether we are using DPI output (thus no internal bridge).
+ * We detect this via two means:
+ * - If the bridge's of_node has a compatible, compare to known internal values.
+ * - If the bridge is a grand-child of DSS, and has "oldi-transmitters" parent.
+ */
+static bool tidss_is_bridge_internal(struct tidss_device *tidss,
+ struct drm_bridge *bridge)
+{
+ struct device_node *parent, *grand_parent;
+ struct property *prop;
+ bool is_internal;
+
+ if (WARN_ON(!bridge->of_node))
+ return false;
+
+ prop = of_find_property(bridge->of_node, "compatible", NULL);
+ for (const char *cp = of_prop_next_string(prop, NULL); cp;
+ cp = of_prop_next_string(prop, cp)) {
+ for (unsigned int i = 0;
+ i < ARRAY_SIZE(tidss_internal_bridge_compatibles); ++i) {
+ if (strcmp(cp, tidss_internal_bridge_compatibles[i]) == 0)
+ return true;
+ }
+ }
+
+ parent = of_get_parent(bridge->of_node);
+ grand_parent = of_get_parent(parent);
+
+ is_internal = parent && grand_parent &&
+ tidss->dev->of_node == grand_parent &&
+ of_node_name_eq(parent, "oldi-transmitters");
+
+ of_node_put(grand_parent);
+ of_node_put(parent);
+
+ return is_internal;
+}
+
static int tidss_dispc_modeset_init(struct tidss_device *tidss)
{
struct device *dev = tidss->dev;
@@ -133,6 +177,7 @@ static int tidss_dispc_modeset_init(struct tidss_device *tidss)
u32 hw_videoport;
struct drm_bridge *bridge;
u32 enc_type;
+ bool dpi_output;
};
const struct dispc_features *feat = tidss->feat;
@@ -149,6 +194,7 @@ static int tidss_dispc_modeset_init(struct tidss_device *tidss)
struct drm_panel *panel;
struct drm_bridge *bridge;
u32 enc_type = DRM_MODE_ENCODER_NONE;
+ bool dpi_output;
int ret;
ret = drm_of_find_panel_or_bridge(dev->of_node, i, 0,
@@ -160,6 +206,11 @@ static int tidss_dispc_modeset_init(struct tidss_device *tidss)
return dev_err_probe(dev, ret, "port %d probe failed\n", i);
}
+ if (bridge)
+ dpi_output = !tidss_is_bridge_internal(tidss, bridge);
+ else
+ dpi_output = true;
+
if (panel) {
u32 conn_type;
@@ -199,6 +250,7 @@ static int tidss_dispc_modeset_init(struct tidss_device *tidss)
pipes[num_pipes].hw_videoport = i;
pipes[num_pipes].bridge = bridge;
pipes[num_pipes].enc_type = enc_type;
+ pipes[num_pipes].dpi_output = dpi_output;
num_pipes++;
}
@@ -224,7 +276,8 @@ static int tidss_dispc_modeset_init(struct tidss_device *tidss)
tidss->planes[tidss->num_planes++] = &tplane->plane;
tcrtc = tidss_crtc_create(tidss, pipes[i].hw_videoport,
- &tplane->plane);
+ &tplane->plane,
+ pipes[i].dpi_output);
if (IS_ERR(tcrtc)) {
dev_err(tidss->dev, "crtc create failed\n");
return PTR_ERR(tcrtc);
--
2.43.0
^ permalink raw reply related
* [PATCH 09/15] drm/tidss: Add external data and sync signal edge configuration
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
The DPI output pipeline in K3 SoCs contains the display subsystem (DSS)
which produces the in-SoC parallel video signal, and a DPI block which
adjusts the signal to the external MIPI DPI output.
The DSS IP has registers to configure whether the data and sync signals
are driven on rising or falling clock edge, and on some SoCs these are
automatically conveyed to the DPI block which needs that configuration
to properly output the MIPI DPI signal.
However, on some SoCs the DPI block configuration has to be done
manually, using an extra register outside the DSS, DPI0_CLK_CTRL from
MAIN_CTRL_MMR_CFG0 block, which controls the DPI block's behavior.
The register is exposed to DSS via syscon 'ti,dpi-io-ctrl' node.
Add the support to get the regmap to the register, and configure the
bits before enabling the video output.
Original patch from Louis Chauvet <louis.chauvet@bootlin.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_dispc.c | 18 ++++++++++++++++++
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 4 ++++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
index c21ac3f51720..0f68e60b902b 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -467,6 +467,7 @@ struct dispc_device {
const struct dispc_features *feat;
struct clk *fclk;
+ struct regmap *syscon_dpi_io_ctrl;
bool is_enabled;
@@ -1201,6 +1202,12 @@ void dispc_vp_prepare(struct dispc_device *dispc, u32 hw_videoport,
mode->crtc_hdisplay - 1) |
FIELD_PREP(DISPC_VP_SIZE_SCREEN_VDISPLAY_MASK,
mode->crtc_vdisplay - 1));
+
+ if (dispc->vp_data[hw_videoport].dpi_output && dispc->syscon_dpi_io_ctrl) {
+ regmap_write(dispc->syscon_dpi_io_ctrl, 0x0,
+ (!ipc ? DPI0_CLK_CTRL_DATA_CLK_INVDIS : 0) |
+ (rf ? DPI0_CLK_CTRL_SYNC_CLK_INVDIS : 0));
+ }
}
void dispc_vp_enable(struct dispc_device *dispc, u32 hw_videoport)
@@ -2989,6 +2996,17 @@ int dispc_init(struct tidss_device *tidss)
dispc_init_errata(dispc);
+ dispc->syscon_dpi_io_ctrl = syscon_regmap_lookup_by_compatible("ti,am625-dss-dpi0-clk-ctrl");
+ if (IS_ERR(dispc->syscon_dpi_io_ctrl)) {
+ if (PTR_ERR(dispc->syscon_dpi_io_ctrl) != -ENODEV) {
+ r = dev_err_probe(dispc->dev, PTR_ERR(dispc->syscon_dpi_io_ctrl),
+ "DISPC: syscon_regmap_lookup_by_phandle failed.\n");
+ return r;
+ }
+
+ dispc->syscon_dpi_io_ctrl = NULL;
+ }
+
dispc->fourccs = devm_kcalloc(dev, ARRAY_SIZE(dispc_color_formats),
sizeof(*dispc->fourccs), GFP_KERNEL);
if (!dispc->fourccs)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
index 382027dddce8..4cdde24d8372 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -333,4 +333,8 @@ enum oldi_mode_reg_val { SPWG_18 = 0, JEIDA_24 = 1, SPWG_24 = 2 };
#define AM65X_OLDI_PWRDN_TX BIT(8)
+/* Bits in the MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL register */
+#define DPI0_CLK_CTRL_DATA_CLK_INVDIS BIT(8)
+#define DPI0_CLK_CTRL_SYNC_CLK_INVDIS BIT(9)
+
#endif /* __TIDSS_DISPC_REGS_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 10/15] drm/tidss: Add support for DPIENABLE bit
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
Many (or even all?) K3 SoCs have DSS VP_CONTROL.DPIENABLE bit described
in their documentation. This bit controls whether the DPI block is
enabled, and is set to 1 by default (i.e. DPI is enabled at HW reset).
However, in almost all SoCs the setting does not actually do anything,
and at the moment the bit is not managed by the driver.
The exception is AM62L, which does have DPIENABLE connected, and
disabling the DPI block when it is not in use provides power savings.
Let's add a new feature flag for this, 'has_vp_control_dpienable', and
implement the support. Disable DPIENABLE for all videoports at resume
time, so that it is 0 by default. Specifically enable and disable it in
dispc_vp_enable() and dispc_vp_disable() for DPI output.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_dispc.c | 23 +++++++++++++++++++++--
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 1 +
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
index 0f68e60b902b..9edce4a4873a 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -442,6 +442,8 @@ const struct dispc_features dispc_am62l_feats = {
},
.vid_order = {0},
+
+ .has_vp_control_dpienable = true,
};
static const u16 *dispc_common_regmap;
@@ -1212,6 +1214,11 @@ void dispc_vp_prepare(struct dispc_device *dispc, u32 hw_videoport,
void dispc_vp_enable(struct dispc_device *dispc, u32 hw_videoport)
{
+ if (dispc->feat->has_vp_control_dpienable &&
+ dispc->vp_data[hw_videoport].dpi_output)
+ VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 1,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
+
VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 1,
DISPC_VP_CONTROL_ENABLE_MASK);
}
@@ -1220,6 +1227,11 @@ void dispc_vp_disable(struct dispc_device *dispc, u32 hw_videoport)
{
VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 0,
DISPC_VP_CONTROL_ENABLE_MASK);
+
+ if (dispc->feat->has_vp_control_dpienable &&
+ dispc->vp_data[hw_videoport].dpi_output)
+ VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 0,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
}
void dispc_vp_unprepare(struct dispc_device *dispc, u32 hw_videoport)
@@ -2443,10 +2455,17 @@ static void dispc_vp_init(struct dispc_device *dispc)
dev_dbg(dispc->dev, "%s()\n", __func__);
- /* Enable the gamma Shadow bit-field for all VPs*/
- for (i = 0; i < dispc->feat->num_vps; i++)
+ for (i = 0; i < dispc->feat->num_vps; i++) {
+ /* Enable the gamma Shadow bit-field for all VPs*/
VP_REG_FLD_MOD(dispc, i, DISPC_VP_CONFIG, 1,
DISPC_VP_CONFIG_GAMMAENABLE_MASK);
+
+ if (dispc->feat->has_vp_control_dpienable) {
+ /* Disable DPIENABLE for all VPs */
+ VP_REG_FLD_MOD(dispc, i, DISPC_VP_CONTROL, 0,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
+ }
+ }
}
static void dispc_initial_config(struct dispc_device *dispc)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h b/drivers/gpu/drm/tidss/tidss_dispc.h
index 6f53d554259c..0fbfb86adfbf 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -92,6 +92,8 @@ struct dispc_features {
u32 num_vids;
struct dispc_vid_info vid_info[TIDSS_MAX_PLANES];
u32 vid_order[TIDSS_MAX_PLANES];
+ /* The DSS has VP_CONTROL.DPIENABLE bit */
+ bool has_vp_control_dpienable;
};
extern const struct dispc_features dispc_k2g_feats;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
index 4cdde24d8372..4246c72efdd5 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -230,6 +230,7 @@ enum dispc_common_regs {
#define DISPC_VP_CONTROL 0x4
#define DISPC_VP_CONTROL_DATALINES_MASK GENMASK(10, 8)
+#define DISPC_VP_CONTROL_DPIENABLE_MASK GENMASK(6, 6)
#define DISPC_VP_CONTROL_GOBIT_MASK GENMASK(5, 5)
#define DISPC_VP_CONTROL_ENABLE_MASK GENMASK(0, 0)
--
2.43.0
^ permalink raw reply related
* [PATCH 13/15] drm/tidss: Add support for AM62P display subsystem
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
From: Swamil Jain <s-jain1@ti.com>
The DSS controller on TI's AM62P SoC features two instances of the TI
DSS. Each DSS instance supports two video ports, similar to the DSS
controller found on the TI AM62X SoC. This allows three independent
video streams to be supported: OLDI, DPI, and DSI.
Since the DSS instances on AM62P are architecturally similar to those
on the AM62X DSS controller, the existing dispc_am625_feats
configuration can be reused for the AM62P DSS support.
This commit adds the necessary device tree compatibility entry for
"ti,am62p-dss" in the tidss driver, pointing to dispc_am625_feats,
thereby enabling DSS support on AM62P devices.
Signed-off-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index aef945101be4..2d056dc1c5ff 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -246,6 +246,7 @@ static const struct of_device_id tidss_of_table[] = {
{ .compatible = "ti,am625-dss", .data = &dispc_am625_feats, },
{ .compatible = "ti,am62a7-dss", .data = &dispc_am62a7_feats, },
{ .compatible = "ti,am62l-dss", .data = &dispc_am62l_feats, },
+ { .compatible = "ti,am62p-dss", .data = &dispc_am625_feats, },
{ .compatible = "ti,am65x-dss", .data = &dispc_am65x_feats, },
{ .compatible = "ti,j721e-dss", .data = &dispc_j721e_feats, },
{ }
--
2.43.0
^ permalink raw reply related
* [PATCH 11/15] drm/tidss: oldi: Fix OLDI signal polarities
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
OLDI has a few issues with how it handles the signal polarities:
- It always sets OLDI_DEPOL, which means DE active low
- It sets DRM_BUS_FLAG_DE_HIGH in struct drm_bridge_timings, i.e.
reverse to the OLDI_DEPOL
- It sets DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE in struct drm_bridge_timings,
but the TRM says "The DSS interface is clocked on the rising edge of
OLDI_FWD_P_CLK pixel clock", which I read as "OLDI samples on rising
edge".
- But the defined drm_bridge_timings is not actually used anywhere, even
if it is set to bridge->timings, so the bus flags are just ignored.
However, based on my testing, OLDI_DEPOL bit or the edge on which data
and syncs are driven doesn't seem to affect the OLDI output. Possibly
it's not as robust, but I did not see any effect with an oscilloscope.
However, the code is still quite broken, so let's fix it:
- Remove drm_bridge_timings
- Set the correct input_bus_cfg.flags in tidss_oldi_atomic_check()
- Set OLDI_DEPOL based on the DE bus flag
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_oldi.c | 38 ++++++++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_oldi.c b/drivers/gpu/drm/tidss/tidss_oldi.c
index 17c535bfa057..e925ddaa4fd6 100644
--- a/drivers/gpu/drm/tidss/tidss_oldi.c
+++ b/drivers/gpu/drm/tidss/tidss_oldi.c
@@ -164,7 +164,8 @@ static void tidss_oldi_tx_power(struct tidss_oldi *oldi, bool enable)
regmap_update_bits(oldi->io_ctrl, OLDI_PD_CTRL, mask, enable ? 0 : mask);
}
-static int tidss_oldi_config(struct tidss_oldi *oldi)
+static int tidss_oldi_config(struct tidss_oldi *oldi,
+ struct drm_bridge_state *bridge_state)
{
const struct oldi_bus_format *bus_fmt = NULL;
u32 oldi_cfg = 0;
@@ -183,7 +184,8 @@ static int tidss_oldi_config(struct tidss_oldi *oldi)
"OLDI%u: DSS port width %d not supported\n",
oldi->oldi_instance, bus_fmt->data_width);
- oldi_cfg |= OLDI_DEPOL;
+ if (bridge_state->input_bus_cfg.flags & DRM_BUS_FLAG_DE_LOW)
+ oldi_cfg |= OLDI_DEPOL; /* 1 = active low */
oldi_cfg = (oldi_cfg & (~OLDI_MAP)) | (bus_fmt->oldi_mode_reg_val << 1);
@@ -220,6 +222,22 @@ static int tidss_oldi_config(struct tidss_oldi *oldi)
return ret;
}
+static int tidss_oldi_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ bridge_state->input_bus_cfg.flags &=
+ ~(DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE);
+
+ bridge_state->input_bus_cfg.flags |=
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE;
+
+ return 0;
+}
+
static void tidss_oldi_atomic_pre_enable(struct drm_bridge *bridge,
struct drm_atomic_state *state)
{
@@ -228,6 +246,7 @@ static void tidss_oldi_atomic_pre_enable(struct drm_bridge *bridge,
struct drm_connector_state *conn_state;
struct drm_crtc_state *crtc_state;
struct drm_display_mode *mode;
+ struct drm_bridge_state *bridge_state;
if (oldi->link_type == OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK)
return;
@@ -245,10 +264,14 @@ static void tidss_oldi_atomic_pre_enable(struct drm_bridge *bridge,
if (WARN_ON(!crtc_state))
return;
+ bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
+ if (WARN_ON(!bridge_state))
+ return;
+
mode = &crtc_state->adjusted_mode;
/* Configure the OLDI params*/
- tidss_oldi_config(oldi);
+ tidss_oldi_config(oldi, bridge_state);
/* Set the OLDI serial clock (7 times the pixel clock) */
tidss_oldi_set_serial_clk(oldi, mode->clock * 7 * 1000);
@@ -329,7 +352,8 @@ tidss_oldi_mode_valid(struct drm_bridge *bridge,
}
static const struct drm_bridge_funcs tidss_oldi_bridge_funcs = {
- .attach = tidss_oldi_bridge_attach,
+ .attach = tidss_oldi_bridge_attach,
+ .atomic_check = tidss_oldi_atomic_check,
.atomic_pre_enable = tidss_oldi_atomic_pre_enable,
.atomic_post_disable = tidss_oldi_atomic_post_disable,
.atomic_get_input_bus_fmts = tidss_oldi_atomic_get_input_bus_fmts,
@@ -440,11 +464,6 @@ static int get_parent_dss_vp(struct device_node *oldi_tx, u32 *parent_vp)
return -ENODEV;
}
-static const struct drm_bridge_timings default_tidss_oldi_timings = {
- .input_bus_flags = DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
- | DRM_BUS_FLAG_DE_HIGH,
-};
-
void tidss_oldi_deinit(struct tidss_device *tidss)
{
for (int i = 0; i < tidss->num_oldis; i++) {
@@ -598,7 +617,6 @@ int tidss_oldi_init(struct tidss_device *tidss)
/* Register the bridge. */
oldi->bridge.of_node = child;
oldi->bridge.driver_private = oldi;
- oldi->bridge.timings = &default_tidss_oldi_timings;
tidss->oldis[tidss->num_oldis++] = oldi;
tidss->is_ext_vp_clk[oldi->parent_vp] = true;
--
2.43.0
^ permalink raw reply related
* [PATCH 14/15] arm64: dts: ti: k3-am62p-j722s-common-main: Add support for DSS
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Jayesh Choudhary, Aradhya Bhatia
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
TI's AM62P and J722S SoCs support 2 display subsystems (DSS), DSS0 and
DSS1, each with two video ports (VP) and two video planes. The outputs
from the DSS VPs can be routed to two OLDI TXes (OLDI0, OLDI1), a DSI
TX, or parallel DPI output.
DSS0 supports:
- VP0: OLDI0 in single-link mode or OLDI0 and OLDI1 in dual-link or
clone mode.
- VP1: DPI
DSS1 supports:
- VP0: OLDI1 in single-link mode, or DPI
- VP1: DPI or DSI
The DSI is only connected to VP1 of DSS1, but OLDI and DPI are shared
between the DSS instances. Thus only a single VP can output to DPI, and
a single VP can use an OLDI block. Note that in single-link
configuration OLDI0 can be used by DSS0, and at the same time OLDI1 can
be used by DSS1.
Add the necessary nodes to k3-am62p-j722s-common-main.dtsi, including
DSS0, DSS1, OLDI0, OLDI1, DPHY and DSI.
An important note about OLDIs:
We have two OLDI hardware blocks. Each OLDI has certain configuration
that has to be done before it can be used. The OLDI blocks get this
configuration directly from the DSS block, via DSS registers. However,
as a single OLDI block can be used either with DSS0 or DSS1, the
source for the configuration changes according to (probably, this is
unclear) a DSS related clock mux.
So, afaics, when thinking about Linux device hierarchy wrt. control
busses, OLDI blocks are children of DSS blocks, and they reside in a
special DSS bus. And the OLDI parent changes according to the mux. As
far as I know, there is no way we can represent this in the DT.
Thus the solution used here (and in the driver) is that each DSS node
contains the OLDI nodes that can be used with that DSS. Thus the DSS0
node has two child nodes, OLDI0 and OLDI1, and the DSS1 node has one
child node, OLDI1. The OLDI1 nodes thus refer to the same piece of
hardware, and they cannot be used at the same time. The selection which
OLDI nodes to use are chosen in the board dts files, so assuming the dts
files are correct, no resource conflict can happen.
This is not a very nice solution, but the hardware doesn't make it easy
to have a clean solution, and, most importantly, this works.
A note about DPI0_CLK_CTRL:
The SoCs also have a separate quirk/fix register for DPI data/sync edge.
See commit "dt-bindings: display: ti,am65x-dss: Add dpi-io-ctrl property
for data/sync edge synchronization" for details.
Here we add that quirk register, with the dss_dpi0_clk_ctrl node, and
refer to it from the DSS nodes.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
[j-choudhary@ti.com: Refactor changes for k3-am62p-j722s-common-main.dtsi
and add changes for new OLDI driver support]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
[tomi.valkeinen: various fixes and improvements]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 112 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62p.dtsi | 16 +++
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 16 +++
3 files changed, 144 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index 0e1af2a69ca2..263bab009021 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -64,6 +64,16 @@ audio_refclk1: clock-controller@82e4 {
#clock-cells = <0>;
};
+ dss_dpi0_clk_ctrl: dss-dpi0-clk-ctrl@8300 {
+ compatible = "ti,am625-dss-dpi0-clk-ctrl", "syscon";
+ reg = <0x8300 0x4>;
+ };
+
+ dss_oldi_io_ctrl: dss-oldi-io-ctrl@8600 {
+ compatible = "ti,am625-dss-oldi-io-ctrl", "syscon";
+ reg = <0x8600 0x200>;
+ };
+
phy_gmii_sel: phy@4044 {
compatible = "ti,am654-phy-gmii-sel";
reg = <0x4044 0x8>;
@@ -1110,6 +1120,108 @@ dphy0: phy@30110000 {
status = "disabled";
};
+ dss0: dss@30200000 {
+ compatible = "ti,am62p-dss";
+ reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30206000 0x00 0x1000>, /* vid */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ power-domains = <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>; /* DSS0 */
+ clocks = <&k3_clks 186 6>,
+ <&dss0_vp1_clk>,
+ <&k3_clks 186 2>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ oldi-transmitters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dss0_oldi0: oldi@0 {
+ reg = <0>;
+ clocks = <&k3_clks 186 0>;
+ clock-names = "serial";
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ status = "disabled";
+ power-domains = <&k3_pds 243 TI_SCI_PD_EXCLUSIVE>; /* OLDI0_VD */
+ };
+
+ dss0_oldi1: oldi@1 {
+ reg = <1>;
+ status = "disabled";
+ power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>; /* OLDI1_VD */
+ };
+ };
+ };
+
+ dss1: dss@30220000 {
+ compatible = "ti,am62p-dss";
+ reg = <0x00 0x30220000 0x00 0x1000>, /* common */
+ <0x00 0x30222000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30226000 0x00 0x1000>, /* vid */
+ <0x00 0x30227000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30228000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3022a000 0x00 0x1000>, /* vp1: Used for DPI/OLDI */
+ <0x00 0x3022b000 0x00 0x1000>, /* vp2: Used DPI/DSI */
+ <0x00 0x30221000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ power-domains = <&k3_pds 232 TI_SCI_PD_EXCLUSIVE>; /* DSS1 */
+ clocks = <&k3_clks 232 8>,
+ <&dss1_vp1_clk>,
+ <&k3_clks 232 4>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ oldi-transmitters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dss1_oldi1: oldi@1 {
+ reg = <1>;
+ clocks = <&k3_clks 232 0>;
+ clock-names = "serial";
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ status = "disabled";
+ power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>; /* OLDI1_VD */
+ };
+ };
+ };
+
+ dphy_tx0: phy@301c0000 {
+ compatible = "ti,j721e-dphy";
+ reg = <0x0 0x301c0000 0x0 0x1000>;
+ clocks = <&k3_clks 238 16>, <&k3_clks 238 1>;
+ clock-names = "psm", "pll_ref";
+ #phy-cells = <0>;
+ power-domains = <&k3_pds 238 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 238 1>;
+ assigned-clock-parents = <&k3_clks 238 2>;
+ assigned-clock-rates = <25000000>;
+ status = "disabled";
+ };
+
+ dsi0: dsi@30500000 {
+ compatible = "ti,j721e-dsi";
+ reg = <0x0 0x30500000 0x0 0x100000>, <0x0 0x30270000 0x0 0x100>;
+ clocks = <&k3_clks 231 2>, <&k3_clks 231 5>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ power-domains = <&k3_pds 231 TI_SCI_PD_EXCLUSIVE>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&dphy_tx0>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
+
vpu: video-codec@30210000 {
compatible = "ti,j721s2-wave521c", "cnm,wave521c";
reg = <0x00 0x30210000 0x00 0x10000>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
index 9d6266d6ddb8..074dc44ec049 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
@@ -144,6 +144,22 @@ cbass_wakeup: bus@b00000 {
};
};
+ dss0_vp1_clk: clock-divider-oldi-dss0 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 186 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
+ dss1_vp1_clk: clock-divider-oldi-dss1 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 232 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
#include "k3-am62p-j722s-common-thermal.dtsi"
};
diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
index 059c65ece183..f5b74281ab3d 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
@@ -227,6 +227,22 @@ cbass_wakeup: bus@b00000 {
};
};
+ dss0_vp1_clk: clock-divider-oldi-dss0 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 186 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
+ dss1_vp1_clk: clock-divider-oldi-dss1 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 232 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
#include "k3-am62p-j722s-common-thermal.dtsi"
};
--
2.43.0
^ permalink raw reply related
* [PATCH 15/15] arm64: dts: ti: beagley-ai: Enable HDMI display and audio
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Andrew Davis
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
From: Andrew Davis <afd@ti.com>
Enable HDMI support for BeagleY-AI platform. The display controller used is
TIDSS and the HDMI bridge used is IT66122.
Based on DT by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
[tomi.valkeinen: cosmetic fixes]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 197 +++++++++++++++++++++++++
1 file changed, 197 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
index 5255e04b9ac7..b7bcc90005d7 100644
--- a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
@@ -146,6 +146,34 @@ led-1 {
default-state = "on";
};
};
+
+ hdmi0: connector-hdmi {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "d";
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&it66122_out>;
+ };
+ };
+ };
+
+ sound0: sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "it66122 HDMI";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&hdmi_dailink_master>;
+ simple-audio-card,frame-master = <&hdmi_dailink_master>;
+
+ hdmi_dailink_master: simple-audio-card,cpu {
+ sound-dai = <&mcasp1>;
+ system-clock-direction-out;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&it66122>;
+ };
+ };
};
&main_pmx0 {
@@ -185,6 +213,20 @@ J722S_IOPAD(0x0240, PIN_INPUT, 7) /* (B24) MMC1_SDCD.GPIO1_48 */
bootph-all;
};
+ main_i2c1_pins_default: main-i2c1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
+ J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_gpio0_ioexp_intr_pins_default: main-gpio0-ioexp-intr-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0110, PIN_INPUT, 7) /* (G27) MMC2_DAT1.GPIO0_67 */
+ >;
+ };
+
mdio_pins_default: mdio-default-pins {
pinctrl-single,pins = <
J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
@@ -227,6 +269,47 @@ vdd_3v3_sd_pins_default: vdd-3v3-sd-default-pins {
J722S_IOPAD(0x0254, PIN_OUTPUT, 7) /* (E25) USB0_DRVVBUS.GPIO1_50 */
>;
};
+
+ dss1_pins_default: dss1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0100, PIN_OUTPUT, 0) /* (AB23) VOUT0_VSYNC */
+ J722S_IOPAD(0x00f8, PIN_OUTPUT, 0) /* (AB24) VOUT0_HSYNC */
+ J722S_IOPAD(0x0104, PIN_OUTPUT, 0) /* (AC26) VOUT0_PCLK */
+ J722S_IOPAD(0x00fc, PIN_OUTPUT, 0) /* (AC27) VOUT0_DE */
+ J722S_IOPAD(0x00b8, PIN_OUTPUT, 0) /* (W27) VOUT0_DATA0 */
+ J722S_IOPAD(0x00bc, PIN_OUTPUT, 0) /* (W25) VOUT0_DATA1 */
+ J722S_IOPAD(0x00c0, PIN_OUTPUT, 0) /* (W24) VOUT0_DATA2 */
+ J722S_IOPAD(0x00c4, PIN_OUTPUT, 0) /* (W23) VOUT0_DATA3 */
+ J722S_IOPAD(0x00c8, PIN_OUTPUT, 0) /* (W22) VOUT0_DATA4 */
+ J722S_IOPAD(0x00cc, PIN_OUTPUT, 0) /* (W21) VOUT0_DATA5 */
+ J722S_IOPAD(0x00d0, PIN_OUTPUT, 0) /* (Y26) VOUT0_DATA6 */
+ J722S_IOPAD(0x00d4, PIN_OUTPUT, 0) /* (Y27) VOUT0_DATA7 */
+ J722S_IOPAD(0x00d8, PIN_OUTPUT, 0) /* (AA24) VOUT0_DATA8 */
+ J722S_IOPAD(0x00dc, PIN_OUTPUT, 0) /* (AA27) VOUT0_DATA9 */
+ J722S_IOPAD(0x00e0, PIN_OUTPUT, 0) /* (AA25) VOUT0_DATA10 */
+ J722S_IOPAD(0x00e4, PIN_OUTPUT, 0) /* (AB25) VOUT0_DATA11 */
+ J722S_IOPAD(0x00e8, PIN_OUTPUT, 0) /* (AA23) VOUT0_DATA12 */
+ J722S_IOPAD(0x00ec, PIN_OUTPUT, 0) /* (AA22) VOUT0_DATA13 */
+ J722S_IOPAD(0x00f0, PIN_OUTPUT, 0) /* (AB26) VOUT0_DATA14 */
+ J722S_IOPAD(0x00f4, PIN_OUTPUT, 0) /* (AB27) VOUT0_DATA15 */
+ J722S_IOPAD(0x005c, PIN_OUTPUT, 1) /* (AC25) GPMC0_AD8.VOUT0_DATA16 */
+ J722S_IOPAD(0x0060, PIN_OUTPUT, 1) /* (U26) GPMC0_AD9.VOUT0_DATA17 */
+ J722S_IOPAD(0x0064, PIN_OUTPUT, 1) /* (V27) GPMC0_AD10.VOUT0_DATA18 */
+ J722S_IOPAD(0x0068, PIN_OUTPUT, 1) /* (V25) GPMC0_AD11.VOUT0_DATA19 */
+ J722S_IOPAD(0x006c, PIN_OUTPUT, 1) /* (V26) GPMC0_AD12.VOUT0_DATA20 */
+ J722S_IOPAD(0x0070, PIN_OUTPUT, 1) /* (V24) GPMC0_AD13.VOUT0_DATA21 */
+ J722S_IOPAD(0x0074, PIN_OUTPUT, 1) /* (V22) GPMC0_AD14.VOUT0_DATA22 */
+ J722S_IOPAD(0x0078, PIN_OUTPUT, 1) /* (V23) GPMC0_AD15.VOUT0_DATA23 */
+ >;
+ };
+
+ main_mcasp1_pins_default: main-mcasp1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0090, PIN_INPUT, 2) /* (P27) GPMC0_BE0n_CLE.MCASP1_ACLKX */
+ J722S_IOPAD(0x0098, PIN_INPUT, 2) /* (V21) GPMC0_WAIT0.MCASP1_AFSX */
+ J722S_IOPAD(0x008c, PIN_INPUT, 2) /* (N23) GPMC0_WEn.MCASP1_AXR0 */
+ >;
+ };
};
&cpsw3g {
@@ -284,6 +367,13 @@ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_I2C1_SDA */
>;
bootph-all;
};
+
+ hdmi_gpio_pins_default: hdmi-gpio-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x0038, PIN_INPUT_PULLUP | PIN_DEBOUNCE_CONF6, 7) /* (D8) MCU_MCAN0_RX.MCU_GPIO0_14 HDMI_INTn */
+ J722S_MCU_IOPAD(0x0034, PIN_OUTPUT_PULLUP, 7) /* (B2) MCU_MCAN0_TX.MCU_GPIO0_13 HDMI_RSTn */
+ >;
+ };
};
&wkup_uart0 {
@@ -385,6 +475,63 @@ rtc: rtc@68 {
};
};
+&main_i2c1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <400000>;
+ bootph-all;
+
+ it66122: bridge-hdmi@4c {
+ compatible = "ite,it66122";
+ reg = <0x4c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_gpio_pins_default>;
+ vcn33-supply = <&vdd_3v3>;
+ vcn18-supply = <&buck2_reg>;
+ vrf12-supply = <&ldo2_reg>;
+ reset-gpios = <&mcu_gpio0 13 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&mcu_gpio0>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * HDMI can be serviced with 3 potential VPs -
+ * (DSS0 VP1 / DSS1 VP0 / DSS1 VP1).
+ * For now, we will service it with DSS1 VP1.
+ */
+ port@0 {
+ reg = <0>;
+
+ it66122_in: endpoint {
+ bus-width = <24>;
+ remote-endpoint = <&dss1_dpi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ it66122_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+};
+
+&main_gpio0 {
+ status = "okay";
+};
+
+&mcu_gpio0 {
+ status = "okay";
+};
+
&sdhci1 {
/* SD/MMC */
vmmc-supply = <&vdd_mmc1>;
@@ -399,4 +546,54 @@ &sdhci1 {
status = "okay";
};
+&dss1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss1_pins_default>;
+
+ clocks = <&k3_clks 232 8>,
+ <&k3_clks 232 0>,
+ <&k3_clks 232 4>;
+
+ assigned-clocks = <&k3_clks 241 0>, /* DSS1-VP0 */
+ <&k3_clks 240 0>, /* DSS1-VP1 */
+ <&k3_clks 245 0>; /* DPI Output */
+
+ assigned-clock-parents = <&k3_clks 241 2>, /* PLL 17 HDMI */
+ <&k3_clks 240 1>, /* PLL 18 DSI */
+ <&k3_clks 245 2>; /* DSS1-DPI0 */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* DSS1-VP1: DPI/HDMI Output */
+ port@0 {
+ reg = <0>;
+
+ dss1_dpi0_out: endpoint {
+ remote-endpoint = <&it66122_in>;
+ };
+ };
+ };
+};
+
+&mcasp1 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp1_pins_default>;
+ auxclk-fs-ratio = <2177>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 1 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+};
+
#include "k3-j722s-ti-ipc-firmware.dtsi"
--
2.43.0
^ permalink raw reply related
* [PATCH 12/15] drm/tidss: oldi: Convert OLDI to an aux driver
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
Currently in the DT, OLDI is defined in child nodes under the DSS node.
The tidss driver will parse the DT, and create DRM bridges for the
OLDIs, and there are no Linux devices for the OLDIs.
On new SoCs the OLDIs have their own power-domains which we need to
control. The cleanest way to do this in DT is to add the PDs to the OLDI
nodes. But this means the OLDI bridge code would somehow have to
manually manage the PDs, the PDs not being under a Linux device, and
there isn't much support for that kind of setup in the PD framework.
A solution to this is to convert the OLDI to an auxiliary device/driver,
created by tidss:
- At module load time the tidss module will, in addition to registering
the tidss DRM driver, register an oldi auxiliary driver.
- At probe time tidss will parse the DT, and create an auxiliary device
for each OLDI.
The aux driver will probe, and as its of_node points to the OLDI node
containing the PD, the driver framework will take care of enabling and
disabling the PD when OLDI is used ("used" as in pm_runtime context).
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_drv.c | 51 +++-
drivers/gpu/drm/tidss/tidss_drv.h | 5 +-
drivers/gpu/drm/tidss/tidss_oldi.c | 493 ++++++++++++++++++++++++++-----------
drivers/gpu/drm/tidss/tidss_oldi.h | 7 +-
4 files changed, 400 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index 5cb3e746aeb3..aef945101be4 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -133,10 +133,6 @@ static int tidss_probe(struct platform_device *pdev)
return ret;
}
- ret = tidss_oldi_init(tidss);
- if (ret)
- return dev_err_probe(dev, ret, "failed to init OLDI\n");
-
pm_runtime_enable(dev);
pm_runtime_set_autosuspend_delay(dev, 1000);
@@ -147,24 +143,30 @@ static int tidss_probe(struct platform_device *pdev)
dispc_runtime_resume(tidss->dispc);
#endif
+ ret = tidss_oldi_create_devices(tidss);
+ if (ret) {
+ dev_err_probe(dev, ret, "failed to create OLDI devices\n");
+ goto err_runtime_suspend;
+ }
+
ret = tidss_modeset_init(tidss);
if (ret < 0) {
if (ret != -EPROBE_DEFER)
dev_err(dev, "failed to init DRM/KMS (%d)\n", ret);
- goto err_runtime_suspend;
+ goto err_destroy_oldis;
}
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
- goto err_runtime_suspend;
+ goto err_destroy_oldis;
}
tidss->irq = irq;
ret = tidss_irq_install(ddev, irq);
if (ret) {
dev_err(dev, "tidss_irq_install failed: %d\n", ret);
- goto err_runtime_suspend;
+ goto err_destroy_oldis;
}
drm_kms_helper_poll_init(ddev);
@@ -194,6 +196,9 @@ static int tidss_probe(struct platform_device *pdev)
err_irq_uninstall:
tidss_irq_uninstall(ddev);
+err_destroy_oldis:
+ tidss_oldi_destroy_devices(tidss);
+
err_runtime_suspend:
#ifndef CONFIG_PM
dispc_runtime_suspend(tidss->dispc);
@@ -201,8 +206,6 @@ static int tidss_probe(struct platform_device *pdev)
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
- tidss_oldi_deinit(tidss);
-
return ret;
}
@@ -218,6 +221,8 @@ static void tidss_remove(struct platform_device *pdev)
tidss_irq_uninstall(ddev);
+ tidss_oldi_destroy_devices(tidss);
+
#ifndef CONFIG_PM
/* If we don't have PM, we need to call suspend manually */
dispc_runtime_suspend(tidss->dispc);
@@ -225,8 +230,6 @@ static void tidss_remove(struct platform_device *pdev)
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
- tidss_oldi_deinit(tidss);
-
/* devm allocated dispc goes away with the dev so mark it NULL */
dispc_remove(tidss);
@@ -262,7 +265,31 @@ static struct platform_driver tidss_platform_driver = {
},
};
-drm_module_platform_driver(tidss_platform_driver);
+static int __init tidss_platform_driver_init(void)
+{
+ int ret;
+
+ ret = tidss_oldi_register_driver();
+ if (ret)
+ return ret;
+
+ ret = drm_platform_driver_register(&tidss_platform_driver);
+ if (ret) {
+ tidss_oldi_unregister_driver();
+ return ret;
+ }
+
+ return 0;
+}
+module_init(tidss_platform_driver_init);
+
+static void __exit tidss_platform_driver_exit(void)
+{
+ platform_driver_unregister(&tidss_platform_driver);
+ tidss_oldi_unregister_driver();
+}
+module_exit(tidss_platform_driver_exit);
+
MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@ti.com>");
MODULE_DESCRIPTION("TI Keystone DSS Driver");
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h b/drivers/gpu/drm/tidss/tidss_drv.h
index e1c1f41d8b4b..d3dba639b278 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.h
+++ b/drivers/gpu/drm/tidss/tidss_drv.h
@@ -16,7 +16,8 @@
#define TIDSS_MAX_OLDI_TXES 2
typedef u32 dispc_irq_t;
-struct tidss_oldi;
+
+struct auxiliary_device;
struct tidss_device {
struct drm_device ddev; /* DRM device for DSS */
@@ -34,7 +35,7 @@ struct tidss_device {
struct drm_plane *planes[TIDSS_MAX_PLANES];
unsigned int num_oldis;
- struct tidss_oldi *oldis[TIDSS_MAX_OLDI_TXES];
+ struct auxiliary_device *oldis[TIDSS_MAX_OLDI_TXES];
unsigned int irq;
diff --git a/drivers/gpu/drm/tidss/tidss_oldi.c b/drivers/gpu/drm/tidss/tidss_oldi.c
index e925ddaa4fd6..86a1e029fdb1 100644
--- a/drivers/gpu/drm/tidss/tidss_oldi.c
+++ b/drivers/gpu/drm/tidss/tidss_oldi.c
@@ -5,11 +5,13 @@
* Aradhya Bhatia <a-bhatia1@ti.com>
*/
+#include <linux/auxiliary_bus.h>
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/of_graph.h>
#include <linux/mfd/syscon.h>
#include <linux/media-bus-format.h>
+#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <drm/drm_atomic_helper.h>
@@ -20,6 +22,12 @@
#include "tidss_dispc_regs.h"
#include "tidss_oldi.h"
+static DEFINE_IDA(tidss_oldi_ida);
+
+struct tidss_oldi_platform_data {
+ struct tidss_device *tidss;
+};
+
struct tidss_oldi {
struct tidss_device *tidss;
struct device *dev;
@@ -251,6 +259,8 @@ static void tidss_oldi_atomic_pre_enable(struct drm_bridge *bridge,
if (oldi->link_type == OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK)
return;
+ WARN_ON(pm_runtime_get_sync(oldi->dev));
+
connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
if (WARN_ON(!connector))
@@ -296,6 +306,8 @@ static void tidss_oldi_atomic_post_disable(struct drm_bridge *bridge,
/* Clear OLDI Config */
tidss_disable_oldi(oldi->tidss, oldi->parent_vp);
+
+ pm_runtime_put_autosuspend(oldi->dev);
}
#define MAX_INPUT_SEL_FORMATS 1
@@ -464,174 +476,375 @@ static int get_parent_dss_vp(struct device_node *oldi_tx, u32 *parent_vp)
return -ENODEV;
}
-void tidss_oldi_deinit(struct tidss_device *tidss)
-{
- for (int i = 0; i < tidss->num_oldis; i++) {
- if (tidss->oldis[i]) {
- drm_bridge_remove(&tidss->oldis[i]->bridge);
- tidss->is_ext_vp_clk[tidss->oldis[i]->parent_vp] = false;
- tidss->oldis[i] = NULL;
- }
- }
-}
-
-int tidss_oldi_init(struct tidss_device *tidss)
+static int tidss_oldi_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *id)
{
- struct tidss_oldi *oldi;
- struct device_node *child;
- struct drm_bridge *bridge;
- u32 parent_vp, oldi_instance;
- int companion_instance = -1;
+ struct device *dev = &auxdev->dev;
+ struct tidss_oldi_platform_data *oldi_pdata = dev_get_platdata(dev);
+ struct tidss_device *tidss = oldi_pdata->tidss;
+ struct device_node *node = auxdev->dev.of_node;
enum tidss_oldi_link_type link_type = OLDI_MODE_UNSUPPORTED;
- struct device_node *oldi_parent;
- int ret = 0;
-
- tidss->num_oldis = 0;
+ int companion_instance = -1;
+ struct drm_bridge *bridge;
+ struct device_link *link;
+ struct tidss_oldi *oldi;
+ u32 oldi_instance;
+ u32 parent_vp;
+ int ret;
- oldi_parent = of_get_child_by_name(tidss->dev->of_node, "oldi-transmitters");
- if (!oldi_parent)
- /* Return gracefully */
- return 0;
+ ret = of_property_read_u32(node, "reg", &oldi_instance);
+ if (ret)
+ return ret;
- for_each_available_child_of_node(oldi_parent, child) {
- ret = get_parent_dss_vp(child, &parent_vp);
- if (ret) {
- if (ret == -ENODEV) {
- /*
- * ENODEV means that this particular OLDI node
- * is not connected with the DSS, which is not
- * a harmful case. There could be another OLDI
- * which may still be connected.
- * Continue to search for that.
- */
- continue;
- }
- goto err_put_node;
- }
+ ret = get_parent_dss_vp(node, &parent_vp);
+ if (ret)
+ return ret;
- ret = of_property_read_u32(child, "reg", &oldi_instance);
- if (ret)
- goto err_put_node;
+ /*
+ * Now that it's confirmed that OLDI is connected with DSS,
+ * let's continue getting the OLDI sinks ahead and other OLDI
+ * properties.
+ */
+ bridge = devm_drm_of_get_bridge(dev, node, OLDI_OUTPUT_PORT, 0);
+ if (IS_ERR(bridge)) {
+ /*
+ * Either there was no OLDI sink in the devicetree, or the OLDI
+ * sink has not been added yet. In any case, return.
+ */
+ ret = dev_err_probe(dev, PTR_ERR(bridge),
+ "no panel/bridge for OLDI%u.\n",
+ oldi_instance);
+ goto err_put_node;
+ }
+ link_type = get_oldi_mode(node, &companion_instance);
+ if (link_type == OLDI_MODE_UNSUPPORTED) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "OLDI%u: Unsupported OLDI connection.\n",
+ oldi_instance);
+ goto err_put_node;
+ } else if ((link_type == OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK) ||
+ (link_type == OLDI_MODE_CLONE_SINGLE_LINK)) {
/*
- * Now that it's confirmed that OLDI is connected with DSS,
- * let's continue getting the OLDI sinks ahead and other OLDI
- * properties.
+ * The OLDI driver cannot support OLDI clone mode properly at
+ * present. The clone mode requires 2 working encoder-bridge
+ * pipelines, generating from the same crtc. The DRM framework
+ * does not support this at present. If there were to be, say, 2
+ * OLDI sink bridges each connected to an OLDI TXes, they
+ * couldn't both be supported simultaneously. This driver still
+ * has some code pertaining to OLDI clone mode configuration in
+ * DSS hardware for future, when there is a better
+ * infrastructure in the DRM framework to support 2
+ * encoder-bridge pipelines simultaneously. Till that time, this
+ * driver shall error out if it detects a clone mode
+ * configuration.
*/
- bridge = devm_drm_of_get_bridge(tidss->dev, child,
- OLDI_OUTPUT_PORT, 0);
- if (IS_ERR(bridge)) {
- /*
- * Either there was no OLDI sink in the devicetree, or
- * the OLDI sink has not been added yet. In any case,
- * return.
- * We don't want to have an OLDI node connected to DSS
- * but not to any sink.
- */
- ret = dev_err_probe(tidss->dev, PTR_ERR(bridge),
- "no panel/bridge for OLDI%u.\n",
+ ret = dev_err_probe(dev, -EOPNOTSUPP,
+ "The OLDI driver does not support Clone Mode at present.\n");
+ goto err_put_node;
+ }
+
+ oldi = devm_drm_bridge_alloc(dev, struct tidss_oldi, bridge,
+ &tidss_oldi_bridge_funcs);
+ if (IS_ERR(oldi)) {
+ ret = PTR_ERR(oldi);
+ goto err_put_node;
+ }
+
+ oldi->parent_vp = parent_vp;
+ oldi->oldi_instance = oldi_instance;
+ oldi->companion_instance = companion_instance;
+ oldi->link_type = link_type;
+ oldi->dev = dev;
+ oldi->next_bridge = bridge;
+ oldi->tidss = tidss;
+
+ auxiliary_set_drvdata(auxdev, oldi);
+
+ /*
+ * Only the primary OLDI needs to reference the io-ctrl system
+ * registers, and the serial clock.
+ * We don't require a check for secondary OLDI in dual-link mode
+ * because the driver will not create a drm_bridge instance.
+ * But the driver will need to create a drm_bridge instance,
+ * for secondary OLDI in clone mode (once it is supported).
+ */
+ if (link_type != OLDI_MODE_SECONDARY_DUAL_LINK &&
+ link_type != OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK) {
+ oldi->io_ctrl = syscon_regmap_lookup_by_phandle(node,
+ "ti,oldi-io-ctrl");
+ if (IS_ERR(oldi->io_ctrl)) {
+ ret = dev_err_probe(oldi->dev, PTR_ERR(oldi->io_ctrl),
+ "OLDI%u: syscon_regmap_lookup_by_phandle failed.\n",
oldi_instance);
goto err_put_node;
}
- link_type = get_oldi_mode(child, &companion_instance);
- if (link_type == OLDI_MODE_UNSUPPORTED) {
- ret = dev_err_probe(tidss->dev, -EINVAL,
- "OLDI%u: Unsupported OLDI connection.\n",
+ oldi->serial = of_clk_get_by_name(node, "serial");
+ if (IS_ERR(oldi->serial)) {
+ ret = dev_err_probe(oldi->dev, PTR_ERR(oldi->serial),
+ "OLDI%u: Failed to get serial clock.\n",
oldi_instance);
goto err_put_node;
- } else if ((link_type == OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK) ||
- (link_type == OLDI_MODE_CLONE_SINGLE_LINK)) {
- /*
- * The OLDI driver cannot support OLDI clone mode
- * properly at present.
- * The clone mode requires 2 working encoder-bridge
- * pipelines, generating from the same crtc. The DRM
- * framework does not support this at present. If
- * there were to be, say, 2 OLDI sink bridges each
- * connected to an OLDI TXes, they couldn't both be
- * supported simultaneously.
- * This driver still has some code pertaining to OLDI
- * clone mode configuration in DSS hardware for future,
- * when there is a better infrastructure in the DRM
- * framework to support 2 encoder-bridge pipelines
- * simultaneously.
- * Till that time, this driver shall error out if it
- * detects a clone mode configuration.
- */
- ret = dev_err_probe(tidss->dev, -EOPNOTSUPP,
- "The OLDI driver does not support Clone Mode at present.\n");
- goto err_put_node;
- } else if (link_type == OLDI_MODE_SECONDARY_DUAL_LINK) {
- /*
- * This is the secondary OLDI node, which serves as a
- * companion to the primary OLDI, when it is configured
- * for the dual-link mode. Since the primary OLDI will
- * be a part of bridge chain, no need to put this one
- * too. Continue onto the next OLDI node.
- */
- continue;
}
+ }
- oldi = devm_drm_bridge_alloc(tidss->dev, struct tidss_oldi, bridge,
- &tidss_oldi_bridge_funcs);
- if (IS_ERR(oldi)) {
- ret = PTR_ERR(oldi);
- goto err_put_node;
- }
+ if (link_type != OLDI_MODE_SECONDARY_DUAL_LINK) {
+ /* Register the bridge. */
+ oldi->bridge.of_node = node;
+ oldi->bridge.driver_private = oldi;
- oldi->parent_vp = parent_vp;
- oldi->oldi_instance = oldi_instance;
- oldi->companion_instance = companion_instance;
- oldi->link_type = link_type;
- oldi->dev = tidss->dev;
- oldi->next_bridge = bridge;
+ tidss->is_ext_vp_clk[oldi->parent_vp] = true;
- /*
- * Only the primary OLDI needs to reference the io-ctrl system
- * registers, and the serial clock.
- * We don't require a check for secondary OLDI in dual-link mode
- * because the driver will not create a drm_bridge instance.
- * But the driver will need to create a drm_bridge instance,
- * for secondary OLDI in clone mode (once it is supported).
- */
- if (link_type != OLDI_MODE_SECONDARY_CLONE_SINGLE_LINK) {
- oldi->io_ctrl = syscon_regmap_lookup_by_phandle(child,
- "ti,oldi-io-ctrl");
- if (IS_ERR(oldi->io_ctrl)) {
- ret = dev_err_probe(oldi->dev, PTR_ERR(oldi->io_ctrl),
- "OLDI%u: syscon_regmap_lookup_by_phandle failed.\n",
- oldi_instance);
- goto err_put_node;
- }
+ drm_bridge_add(&oldi->bridge);
+ }
+
+ link = device_link_add(&auxdev->dev, tidss->dev,
+ DL_FLAG_PM_RUNTIME |
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link) {
+ ret = -EINVAL;
+ goto err_bridge_remove;
+ }
+
+ pm_runtime_enable(dev);
+ pm_runtime_set_autosuspend_delay(dev, 500);
+ pm_runtime_use_autosuspend(dev);
+
+ return 0;
+
+err_bridge_remove:
+ if (link_type != OLDI_MODE_SECONDARY_DUAL_LINK) {
+ drm_bridge_remove(&oldi->bridge);
+ tidss->is_ext_vp_clk[oldi->parent_vp] = false;
+ }
+
+err_put_node:
+ return ret;
+}
+
+static void tidss_oldi_remove(struct auxiliary_device *auxdev)
+{
+ struct tidss_oldi *oldi = auxiliary_get_drvdata(auxdev);
+ struct tidss_device *tidss = oldi->tidss;
+ struct device *dev = &auxdev->dev;
+
+ pm_runtime_dont_use_autosuspend(dev);
+ pm_runtime_disable(dev);
+
+ if (oldi->link_type != OLDI_MODE_SECONDARY_DUAL_LINK) {
+ drm_bridge_remove(&oldi->bridge);
- oldi->serial = of_clk_get_by_name(child, "serial");
- if (IS_ERR(oldi->serial)) {
- ret = dev_err_probe(oldi->dev, PTR_ERR(oldi->serial),
- "OLDI%u: Failed to get serial clock.\n",
- oldi_instance);
- goto err_put_node;
+ tidss->is_ext_vp_clk[oldi->parent_vp] = false;
+ }
+}
+
+static const struct auxiliary_device_id tidss_oldi_aux_id_table[] = {
+ { .name = "tidss.oldi" },
+ {}
+};
+
+static struct auxiliary_driver oldi_aux_driver = {
+ .name = "oldi",
+ .probe = tidss_oldi_probe,
+ .remove = tidss_oldi_remove,
+ .id_table = tidss_oldi_aux_id_table,
+};
+
+static void tidss_oldi_aux_device_release(struct device *dev)
+{
+ struct auxiliary_device *auxdev = to_auxiliary_dev(dev);
+
+ ida_free(&tidss_oldi_ida, auxdev->id);
+
+ of_node_put(auxdev->dev.of_node);
+
+ kfree(auxdev->dev.platform_data);
+ kfree(auxdev);
+}
+
+static struct auxiliary_device *
+tidss_oldi_create_device(struct tidss_device *tidss,
+ struct device_node *oldi_tx)
+{
+ struct tidss_oldi_platform_data *oldi_pdata;
+ struct auxiliary_device *companion_auxdev;
+ struct auxiliary_device *auxdev;
+ u32 oldi_aux_id;
+ int ret;
+
+ /*
+ * Allocate the ID first, so that we get a lower ID for the primary
+ * OLDI, instead of the companion grabbing it in the call below. Note
+ * that the ID allocated here often matches the OLDI hardware index,
+ * but not always.
+ * The OLDI hardware index cannot be used as an ID, as, say, OLDI 1 on
+ * two DSS instances would produce the exact same device name
+ * ("tidss.oldi.1").
+ */
+ ret = ida_alloc(&tidss_oldi_ida, GFP_KERNEL);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ oldi_aux_id = ret;
+
+ companion_auxdev = NULL;
+
+ /*
+ * If this is the primary OLDI and there is a companion, create the
+ * auxdev for the secondary OLDI first, as the secondary will act as
+ * a supplier for the primary OLDI.
+ */
+ if (!of_property_read_bool(oldi_tx, "ti,secondary-oldi")) {
+ struct device_node *companion_node;
+
+ companion_node = of_parse_phandle(oldi_tx, "ti,companion-oldi", 0);
+ if (companion_node) {
+ companion_auxdev =
+ tidss_oldi_create_device(tidss, companion_node);
+
+ of_node_put(companion_node);
+
+ if (IS_ERR(companion_auxdev)) {
+ dev_err(tidss->dev,
+ "Failed to create secondary oldi device\n");
+ ret = PTR_ERR(companion_auxdev);
+ goto err_free_ida;
}
}
+ }
- /* Register the bridge. */
- oldi->bridge.of_node = child;
- oldi->bridge.driver_private = oldi;
+ oldi_pdata = kzalloc_obj(*oldi_pdata);
+ if (!oldi_pdata) {
+ ret = -ENOMEM;
+ goto err_free_ida;
+ }
- tidss->oldis[tidss->num_oldis++] = oldi;
- tidss->is_ext_vp_clk[oldi->parent_vp] = true;
- oldi->tidss = tidss;
+ oldi_pdata->tidss = tidss;
- drm_bridge_add(&oldi->bridge);
+ auxdev = kzalloc_obj(*auxdev);
+ if (!auxdev) {
+ ret = -ENOMEM;
+ goto err_free_pdata;
+ }
+
+ *auxdev = (struct auxiliary_device) {
+ .name = "oldi",
+ .id = oldi_aux_id,
+ .dev = {
+ .parent = tidss->dev,
+ .of_node = of_node_get(oldi_tx),
+ .release = tidss_oldi_aux_device_release,
+ .platform_data = oldi_pdata,
+ },
+ };
+
+ ret = auxiliary_device_init(auxdev);
+ if (ret) {
+ dev_err(tidss->dev, "OLDI auxiliary_device_init failed: %d\n",
+ ret);
+ goto err_free_auxdev;
+ }
+
+ /*
+ * Create a device-link between the primary and the secondary, so that
+ * the secondary will be powered on when the primary is used.
+ */
+ if (companion_auxdev) {
+ struct device_link *link;
+
+ link = device_link_add(&auxdev->dev, &companion_auxdev->dev,
+ DL_FLAG_PM_RUNTIME |
+ DL_FLAG_AUTOREMOVE_CONSUMER |
+ DL_FLAG_AUTOREMOVE_SUPPLIER);
+ if (!link) {
+ dev_err(tidss->dev,
+ "device_link_add failed between primary and secondary OLDI\n");
+ ret = -EINVAL;
+ goto err_uninit_auxdev;
+ }
+ }
+
+ ret = auxiliary_device_add(auxdev);
+ if (ret) {
+ dev_err(tidss->dev, "OLDI auxiliary_device_add failed: %d\n",
+ ret);
+ goto err_uninit_auxdev;
}
- of_node_put(child);
- of_node_put(oldi_parent);
+ tidss->oldis[tidss->num_oldis++] = auxdev;
+
+ return auxdev;
+
+err_uninit_auxdev:
+ auxiliary_device_uninit(auxdev);
+ /* return here, as the rest are done in auxdev's release */
+ return ERR_PTR(ret);
+
+err_free_auxdev:
+ kfree(auxdev);
+err_free_pdata:
+ kfree(oldi_pdata);
+err_free_ida:
+ ida_free(&tidss_oldi_ida, oldi_aux_id);
+
+ return ERR_PTR(ret);
+}
+
+int tidss_oldi_create_devices(struct tidss_device *tidss)
+{
+ struct device_node *oldi_txes;
+ struct device_node *oldi_tx;
+ int ret;
+
+ oldi_txes = of_get_child_by_name(tidss->dev->of_node,
+ "oldi-transmitters");
+ if (!oldi_txes)
+ return 0;
+
+ /*
+ * Look for primary OLDIs and create devices for them. For dual-link
+ * cases, the primary's create_device call will also create the
+ * secondary device.
+ */
+ for_each_available_child_of_node(oldi_txes, oldi_tx) {
+ struct auxiliary_device *auxdev;
+
+ if (of_property_read_bool(oldi_tx, "ti,secondary-oldi"))
+ continue;
+
+ auxdev = tidss_oldi_create_device(tidss, oldi_tx);
+ if (IS_ERR(auxdev)) {
+ ret = PTR_ERR(auxdev);
+ goto err_destroy_oldis;
+ }
+ }
+
+ of_node_put(oldi_txes);
return 0;
-err_put_node:
- of_node_put(child);
- of_node_put(oldi_parent);
+err_destroy_oldis:
+ tidss_oldi_destroy_devices(tidss);
+
+ of_node_put(oldi_tx);
+ of_node_put(oldi_txes);
+
return ret;
}
+
+void tidss_oldi_destroy_devices(struct tidss_device *tidss)
+{
+ for (unsigned int i = 0; i < tidss->num_oldis; ++i)
+ auxiliary_device_destroy(tidss->oldis[i]);
+}
+
+int tidss_oldi_register_driver(void)
+{
+ return auxiliary_driver_register(&oldi_aux_driver);
+}
+
+void tidss_oldi_unregister_driver(void)
+{
+ auxiliary_driver_unregister(&oldi_aux_driver);
+}
diff --git a/drivers/gpu/drm/tidss/tidss_oldi.h b/drivers/gpu/drm/tidss/tidss_oldi.h
index a361e6dbfce3..2069bd46aaae 100644
--- a/drivers/gpu/drm/tidss/tidss_oldi.h
+++ b/drivers/gpu/drm/tidss/tidss_oldi.h
@@ -36,7 +36,10 @@ enum tidss_oldi_link_type {
OLDI_MODE_SECONDARY_DUAL_LINK,
};
-int tidss_oldi_init(struct tidss_device *tidss);
-void tidss_oldi_deinit(struct tidss_device *tidss);
+int tidss_oldi_create_devices(struct tidss_device *tidss);
+void tidss_oldi_destroy_devices(struct tidss_device *tidss);
+
+int tidss_oldi_register_driver(void);
+void tidss_oldi_unregister_driver(void);
#endif /* __TIDSS_OLDI_H__ */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 6/8] ARM: zte: Bring back zx29 UART support
From: Linus Walleij @ 2026-04-20 13:00 UTC (permalink / raw)
To: Stefan Dösinger
Cc: linux-arm-kernel, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-7-stefandoesinger@gmail.com>
On Tue, Apr 14, 2026 at 11:12 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
> zx platform"). I did not bring back the zx29-uart .compatible as the
> arm,primecell-periphid does the job.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
Topic should be prefixed:
"amba/serial: amba-pl011: ..."
Interesting with the AMBA pseudo-ID, but I kind of like the idea.
When bit 7 is set, bits [0..6] should be the JEDEC JEP106
"manufacturer ID" standard.
0xfe is assigned to "Numonyx Corporation".
Things without bit 7 set such as ARMs 0x41 and Qualcomms
0x51 are kind of cowboy values however. LSI 0xb6 is the only
vendor actually following the standard.
You could use 0x7e.
Or is this one of the cases where the Linux Foundation could
step in and actually ask JEDEC for a proper ID (despite 126 of
them being in use already....)
On the other hand I have seen how people just use these IDs
however they like, ST Micro uses 0x80 on Nomadik for example,
and the actual SGS/Thomson value assigned is 0x20 so should
have been 0xa0...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Krzysztof Kozlowski @ 2026-04-20 13:00 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Rob Herring (Arm), linux-kernel, Conor Dooley, Jonathan Corbet,
Alexandre Belloni, Greg Kroah-Hartman, linux-doc, devicetree,
Drew Fustini, Linus Walleij, Jiri Slaby, Russell King, soc,
Arnd Bergmann, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <6264667.lOV4Wx5bFT@strix>
On Sun, Apr 19, 2026 at 11:30:04AM +0300, Stefan Dösinger wrote:
> Hi Rob,
>
> Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
>
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > date:
>
> Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
> wrote the warning you pointed out, but I only checked the return value - which
> indicated success. Which I guess makes sense for a warning, since there seem
> to be a few preexisting ones. The warning itself was somewhere in the
> scrollback because I let dt_binding_check check all the files.
>
> So I learned I have to actually look at the output to see if there are any
> warnings.
Same with every other tool warnings, like compiler warnings...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 13:00 UTC (permalink / raw)
To: Sebastian Ene
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <aeYbdmshGZJ4GhXd@google.com>
Hi Sebastian,
> On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
>
> Hello Yeoreum,
>
>
> > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or
> > obtain RX/TX buffer information, leading to failures in FF-A calls.
>
> At the moment this already happens after you move back ffa_init() to
> device_initcall().
How? the kvm_arm_init() is device_initcall() if both built as built-in.
>
> >
> > During FF-A driver initialization, check whether pKVM has been initialized.
> > If not, defer probing of the FF-A driver.
> >
>
> I don't think you need to add this dependency. pKVM is
> installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> do the proxy initialization. The ARM-FFA driver comes after it (since
> pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> be able to handle smc(FF-A) calls in the hyp-proxy.
>
As Marc said, the before finalised_pkvm(), smc wouldn't be trapped
to pKVM. IOW, in case when both built as built-in,
if ffa_init() is called before finalised_pkvm(),
it couldn't proxy the FFA_VERSION, FFA_RXTX_MAP and FFA_PARTITION_INFO_GET
called by ffa_init().
How can you gurantee hyp_ffa_init() which is called by kvm_arm_init()
comes first even kvm_arm_init() and ffa_init() are on device_initcall?
[...]
Thanks
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Mark Rutland @ 2026-04-20 13:06 UTC (permalink / raw)
To: Breno Leitao
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org>
On Mon, Apr 20, 2026 at 05:42:11AM -0700, Breno Leitao wrote:
> arch_local_irq_enable() is a small wrapper that dispatches between two
> unmask paths: __daif_local_irq_enable() on most systems, and
> __pmr_local_irq_enable() on builds that use GIC PMR-based masking
> (Pseudo-NMI). Both leaf primitives are already __always_inline; the
> wrapper itself is plain "static inline".
>
> In practice the compiler does not always inline the wrapper.
I think this was my mistake, and we should have marked all the helpers
as __always_inline for noinstr safety, as x86 did in commit:
7a745be1cc90 ("x86/entry: __always_inline irqflags for noinstr")
I think we should mark all of the following as __always_inline in one
go:
* arch_local_irq_enable()
* arch_local_irq_disable()
* arch_local_save_flags()
* arch_irqs_disabled_flags()
* arch_irqs_disabled()
* arch_local_irq_save()
* arch_local_irq_restore()
... which then ensures noinstr safety, and has the side benefit of
giving nicer traces as you're suggesting here.
Are you happy to try that?
Mark.
> When it gets emitted out-of-line, samples taken inside it during the
> post-WFI IRQ unmask in default_idle_call() show up as
> arch_local_irq_enable overhead in profiles, with default_idle_call()
> lost from the unwound chain.
>
> This matters most at fleet scale. On a large arm64 fleet, the
> aggregate effect is that idle CPUs show up in fleet-wide profilers as
> "busy stuck in arch_local_irq_enable" instead of as idle
> (default_idle_call / cpu_startup_entry). Engineers looking at
> fleet-wide top-symbol dashboards see what looks like significant
> CPU-bound work in IRQ unmasking and chase a phantom hot path, when in
> fact the cost is the WFI wake-up cycle being attributed to the wrong
> function. Tooling has to special-case this symbol to suppress it,
> which is fragile across kernel versions. Inlining the wrapper makes
> idle CPUs appear idle in profiles - which is what they are.
>
> The same misattribution affects driver stalls. arm64 PMU overflow is
> delivered as a regular IRQ (no NMI on default builds), so a driver
> that holds local_irq_disable() for milliseconds defers every PMU
> sample to the moment it calls local_irq_enable(). With the wrapper
> out-of-line, the resulting fat sample is credited to
> arch_local_irq_enable rather than to the driver, and the FP-unwinder
> points the call chain at the driver's caller instead of the driver
> itself (the immediate caller is skipped because arch_local_irq_enable
> is a leaf with no saved frame). The driver is still visible in the
> profile from its other samples, but the stall cost itself is
> mis-attributed and the chain leading to it is one frame off, making
> fleet-wide root-cause analysis harder than it needs to be. Inlining
> the wrapper attributes the stall sample to the driver function that
> actually held IRQs disabled.
>
> Trade-offs:
>
> - Minor .text effect: every caller now expands the dispatch +
> underlying primitive at its call site. system_uses_irq_prio_masking()
> is a static-key check, so on non-pNMI systems the inlined body
> collapses to a single MSR daifclr; on pNMI systems it collapses to a
> single sysreg write.
>
> - Loss of a debugging convenience: there is no longer an
> arch_local_irq_enable symbol to set a breakpoint on. Callers must be
> targeted individually.
>
> - Compiler trust: __always_inline overrides size heuristics. The body
> is small enough that this should be unobjectionable, but it is a
> policy change.
>
> This patch only flips arch_local_irq_enable(). The same reasoning
> applies to arch_local_irq_disable()/save()/restore() which share the
> identical static-inline-wrapper-around-__always_inline-primitives
> pattern. Holding those off until profiles motivate them.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> arch/arm64/include/asm/irqflags.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index d4d7451c2c129..505ef5be53a71 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_enable(void)
> +static __always_inline void arch_local_irq_enable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_enable();
>
> ---
> base-commit: 615aad0f61e0c7a898184a394dc895c610100d4f
> change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
^ permalink raw reply
* Re: [PATCH RFC] arm64/irqflags: force inline of arch_local_irq_enable()
From: Breno Leitao @ 2026-04-20 13:15 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, kernel-team
In-Reply-To: <aeYkz_4WKDdb1NTp@J2N7QTR9R3>
On Mon, Apr 20, 2026 at 02:06:23PM +0100, Mark Rutland wrote:
> On Mon, Apr 20, 2026 at 05:42:11AM -0700, Breno Leitao wrote:
> > arch_local_irq_enable() is a small wrapper that dispatches between two
> > unmask paths: __daif_local_irq_enable() on most systems, and
> > __pmr_local_irq_enable() on builds that use GIC PMR-based masking
> > (Pseudo-NMI). Both leaf primitives are already __always_inline; the
> > wrapper itself is plain "static inline".
> >
> > In practice the compiler does not always inline the wrapper.
>
> I think this was my mistake, and we should have marked all the helpers
> as __always_inline for noinstr safety, as x86 did in commit:
>
> 7a745be1cc90 ("x86/entry: __always_inline irqflags for noinstr")
>
> I think we should mark all of the following as __always_inline in one
> go:
>
> * arch_local_irq_enable()
> * arch_local_irq_disable()
> * arch_local_save_flags()
> * arch_irqs_disabled_flags()
> * arch_irqs_disabled()
> * arch_local_irq_save()
> * arch_local_irq_restore()
>
> ... which then ensures noinstr safety, and has the side benefit of
> giving nicer traces as you're suggesting here.
>
> Are you happy to try that?
Absolutely, I'll work on testing it that and put together a patch
addressing all of them.
Should this be targeted for stable backports as well? If so, which
commit should I reference in the Fixes tag?
Thanks for the quick answer,
--breno
^ permalink raw reply
* [PATCH AUTOSEL 6.18] net: stmmac: Fix PTP ref clock for Tegra234
From: Sasha Levin @ 2026-04-20 13:07 UTC (permalink / raw)
To: patches, stable
Cc: Jon Hunter, Simon Horman, Jakub Kicinski, Sasha Levin,
alexandre.torgue, joabreu, davem, edumazet, pabeni,
mcoquelin.stm32, thierry.reding, vbhadram, ruppala, netdev,
linux-stm32, linux-arm-kernel, linux-tegra, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Jon Hunter <jonathanh@nvidia.com>
[ Upstream commit 1345e9f4e3f3bc7d8a0a2138ae29e205a857a555 ]
Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
0 before configuring timestamping") was added the following error is
observed on Tegra234:
ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
It turns out that the Tegra234 device-tree binding defines the PTP ref
clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
exposes this and that the PTP clock is not configured correctly.
In order to update device-tree to use the correct 'ptp_ref' name, update
the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
'ptp-ref' if this clock name is present.
Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
index d765acbe37548..21a0a11fc0118 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
@@ -9,7 +9,7 @@
#include "stmmac_platform.h"
static const char *const mgbe_clks[] = {
- "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp-ref", "mac"
+ "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp_ref", "mac"
};
struct tegra_mgbe {
@@ -215,6 +215,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat;
struct stmmac_resources res;
+ bool use_legacy_ptp = false;
struct tegra_mgbe *mgbe;
int irq, err, i;
u32 value;
@@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
if (!mgbe->clks)
return -ENOMEM;
- for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
+ /* Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
+ * Fall back when the legacy name is present.
+ */
+ if (of_property_match_string(pdev->dev.of_node, "clock-names",
+ "ptp-ref") >= 0)
+ use_legacy_ptp = true;
+
+ for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
mgbe->clks[i].id = mgbe_clks[i];
+ if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
+ dev_warn(mgbe->dev,
+ "Device-tree update needed for PTP clock!\n");
+ mgbe->clks[i].id = "ptp-ref";
+ }
+ }
+
err = devm_clk_bulk_get(mgbe->dev, ARRAY_SIZE(mgbe_clks), mgbe->clks);
if (err < 0)
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] wifi: mt76: don't return TXQ when exceeding max non-AQL packets
From: Sasha Levin @ 2026-04-20 13:07 UTC (permalink / raw)
To: patches, stable
Cc: David Bauer, Felix Fietkau, Sasha Levin, lorenzo, ryder.lee,
kvalo, matthias.bgg, angelogioacchino.delregno, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: David Bauer <mail@david-bauer.net>
[ Upstream commit 964f870e090e9c88a41e2890333421204cc0bdf4 ]
mt76_txq_send_burst does check if the number of non-AQL frames exceeds
the maximum. In this case the queue is returned to ieee80211_return_txq
when iterating over the scheduled TXQs in mt76_txq_schedule_list.
This has the effect of inserting said TXQ at the head of the list. This
means the loop will get the same TXQ again, which will terminate the
scheduling round. TXQs following in the list thus never get scheduled
for transmission.
This can manifest in high latency low throughput or broken connections
for said STAs.
Check if the non-AQL packet count exceeds the limit and not return the
TXQ in this case.
Schedule all TXQs for the STA in case the non-AQL limit can be satisfied
again.
Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://patch.msgid.link/20260129232321.276575-1-mail@david-bauer.net
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
I now have all the information needed for a complete analysis. Let me
compile my findings.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem**: `wifi: mt76:` (MediaTek mt76 WiFi driver)
- **Action verb**: "don't return" — indicates preventing incorrect
behavior, i.e., a bug fix
- **Summary**: Don't return TXQ to mac80211 scheduler when the non-AQL
packet limit is exceeded
### Step 1.2: Tags
- **Signed-off-by**: David Bauer (author), Felix Fietkau
(committer/maintainer)
- **Link**:
`https://patch.msgid.link/20260129232321.276575-1-mail@david-
bauer.net`
- No Fixes: tag, no Cc: stable, no Reported-by — all expected for a
commit under review
- Felix Fietkau (nbd@nbd.name) is the mt76 subsystem maintainer who
merged this
### Step 1.3: Commit Body
- **Bug described**: When `mt76_txq_send_burst` detects non-AQL packets
exceeding the limit, it returns 0. The TXQ is then returned to
mac80211 via `ieee80211_return_txq()`, which re-inserts it at the head
of the scheduling list (with airtime fairness). On the next iteration,
`ieee80211_next_txq()` sees the same TXQ with its round number already
set, returns NULL, and terminates the scheduling round.
- **Symptom**: "high latency low throughput or broken connections for
said STAs" — TXQs following the problematic one in the list never get
scheduled.
- **Root cause**: TXQ scheduling starvation due to improper return of
rate-limited TXQs
### Step 1.4: Hidden Bug Fix Detection
This is an explicit, clearly-described bug fix for a scheduling
starvation issue.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **Files changed**: 1 file — `drivers/net/wireless/mediatek/mt76/tx.c`
- **Changes**: ~20 lines added, 0 removed (two code additions)
- **Functions modified**: `mt76_tx_check_non_aql()`,
`mt76_txq_schedule_list()`
- **Scope**: Single-file, surgical fix in two specific functions
### Step 2.2: Code Flow Changes
**Hunk 1** (`mt76_tx_check_non_aql`):
- **Before**: Decrements `non_aql_packets` on tx completion, clamps to 0
if negative, returns
- **After**: Same, plus: when `pending == MT_MAX_NON_AQL_PKT - 1` (count
just dropped below limit), reschedules all TXQs for the STA via
`ieee80211_schedule_txq()`. This ensures TXQs that were dropped from
the scheduling list get re-added.
**Hunk 2** (`mt76_txq_schedule_list`):
- **Before**: After getting a TXQ from `ieee80211_next_txq()`, checks PS
flag and reset state, then proceeds to `mt76_txq_send_burst()` which
may early-return if non-AQL limit is hit. Then always calls
`ieee80211_return_txq()`.
- **After**: Adds a check `if (atomic_read(&wcid->non_aql_packets) >=
MT_MAX_NON_AQL_PKT) continue;` — skips the TXQ without returning it to
the scheduler, allowing the loop to proceed to the next TXQ.
### Step 2.3: Bug Mechanism
This is a **logic/scheduling correctness bug**. The mac80211 TXQ
scheduler has specific round-tracking semantics:
- `ieee80211_next_txq()` removes the TXQ and marks its round number
- `ieee80211_return_txq()` re-inserts it (at HEAD with airtime fairness)
- A subsequent `ieee80211_next_txq()` seeing the same TXQ's round number
→ returns NULL, ending the round
When a non-AQL-limited TXQ is returned to the list, it poisons the
scheduling round and starves all subsequent TXQs.
### Step 2.4: Fix Quality
- **Obviously correct**: Yes — the `continue` pattern is already used in
this function for PS flag and reset state checks
- **Minimal/surgical**: Yes — two small additions, no unrelated changes
- **Regression risk**: Very low — not returning a rate-limited TXQ is
correct; the rescheduling on tx completion ensures it gets re-added
when appropriate
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
- `mt76_tx_check_non_aql()` — core logic introduced by `e1378e5228aaa1`
(Felix Fietkau, 2020-08-23), refactored in `0fe88644c06063`
(2021-05-07)
- `mt76_txq_schedule_list()` — scheduling loop from `17f1de56df0512`
(2017-11-21), with non-AQL logic from `e1378e5228aaa1`
- The non-AQL mechanism itself was introduced in commit `e1378e5228aaa1`
which first appeared in **v5.10-rc1**
### Step 3.2: Fixes Tag
No Fixes: tag present. However, the bug was effectively introduced by
`e1378e5228aaa1` ("mt76: rely on AQL for burst size limits on tx
queueing") in v5.10-rc1.
### Step 3.3: File History
- `tx.c` has had 19 commits since v6.1, including multi-radio support
(`716cc146d5805`, Jan 2025) and wcid pointer wrapper (`dc66a129adf1f`,
Jul 2025)
- This patch is standalone — not part of a series
### Step 3.4: Author
- David Bauer: occasional mt76 contributor (5 commits found), has worked
on mt7915 MCU and other mt76 issues
- Felix Fietkau: mt76 subsystem maintainer who reviewed and merged this
### Step 3.5: Dependencies
- The `continue` in scheduling loop follows the existing pattern (PS
flag, reset state already use `continue`)
- The rescheduling uses `ieee80211_schedule_txq()` — available since
mac80211 TXQ API inception
- `wcid_to_sta()` — fundamental mt76 helper, present in all trees
- Minor adaptations needed for older trees (e.g., `__mt76_wcid_ptr` vs
`rcu_dereference`)
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1–4.5
b4 dig couldn't find the message-id, and lore.kernel.org is blocking
automated access. The patch link is
`https://patch.msgid.link/20260129232321.276575-1-mail@david-bauer.net`.
It was merged by Felix Fietkau (mt76 maintainer), which provides strong
implicit review. No NAKs or objections were found.
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Functions Modified
1. `mt76_tx_check_non_aql()` — called from `__mt76_tx_complete_skb()` on
every TX completion
2. `mt76_txq_schedule_list()` — core TX scheduling loop, called from
`mt76_txq_schedule()`
### Step 5.2: Callers
- `mt76_tx_check_non_aql()` → called from `__mt76_tx_complete_skb()`
which is the main TX completion path for ALL mt76 drivers
- `mt76_txq_schedule_list()` → called from `mt76_txq_schedule()` →
`mt76_txq_schedule_all()` → `mt76_tx_worker_run()` — the main TX
worker
### Step 5.3–5.4: Call Chain
TX completion path: hardware IRQ → driver tx_complete →
`__mt76_tx_complete_skb()` → `mt76_tx_check_non_aql()` → (new)
`ieee80211_schedule_txq()`. This is a very hot, commonly-exercised path.
### Step 5.5: Similar Patterns
The existing `continue` statements in `mt76_txq_schedule_list()` for PS
flag and reset state already follow the exact same pattern of skipping
TXQs without returning them.
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Buggy Code in Stable
The non-AQL mechanism (`e1378e5228aaa1`) was introduced in v5.10-rc1.
All active stable trees (5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y) contain
the buggy code.
### Step 6.2: Backport Complications
- The multi-radio refactoring (`716cc146d5805`, Jan 2025) and wcid_ptr
wrapper (`dc66a129adf1f`, Jul 2025) are post-6.12
- Older trees will need minor adaptation (e.g., different wcid lookup
syntax)
- The core logical change applies cleanly to all trees conceptually
### Step 6.3: No Related Fixes in Stable
No existing fix for this scheduling starvation issue was found in
stable.
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: Subsystem Criticality
- **Subsystem**: `drivers/net/wireless/mediatek/mt76` — one of the most
widely-used WiFi driver families in Linux
- **Criticality**: IMPORTANT — mt76 covers MT7603, MT7615, MT7915,
MT7921, MT7996 chipsets used in routers, laptops, and access points
- This affects ALL mt76 devices, not just a specific chipset
### Step 7.2: Subsystem Activity
Active development — 30 commits in recent history for tx.c alone.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Affected Users
All users of mt76 WiFi hardware (very broad: routers, embedded systems,
laptops). mt76 is one of the most popular WiFi driver families in the
Linux kernel.
### Step 8.2: Trigger Conditions
- Trigger: Multiple STAs connected, one STA hitting the non-AQL packet
limit (common during bursts before rate control information is
available, or under load)
- With airtime fairness enabled (default in many configurations):
immediate starvation of all other STAs in the same AC
- Very likely to trigger in multi-client AP scenarios (routers, access
points)
### Step 8.3: Failure Mode Severity
- **Failure mode**: High latency, low throughput, or broken connections
for affected STAs
- **Severity**: HIGH — loss of connectivity/severe degradation for WiFi
clients in multi-client scenarios
### Step 8.4: Risk-Benefit
- **Benefit**: HIGH — fixes scheduling starvation affecting all mt76
users with multiple clients
- **Risk**: VERY LOW — ~20 lines, follows existing patterns, single
file, obviously correct, merged by subsystem maintainer
- **Ratio**: Strongly favorable for backporting
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backporting:**
- Fixes a real, user-visible bug (high latency, broken connections)
- Affects all mt76 WiFi users with multiple clients — very broad impact
- Small, surgical fix (~20 lines, single file)
- Follows existing code patterns (`continue` for TXQ skipping)
- Merged by subsystem maintainer (Felix Fietkau)
- Bug exists in all stable trees since v5.10
- No regression risk — the fix is obviously correct
**AGAINST backporting:**
- No Fixes: tag or Cc: stable (expected)
- Minor adaptation needed for older trees due to intermediate
refactoring
- No syzbot/KASAN report (this is a logic/scheduling bug, not memory
safety)
### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — merged by maintainer, follows
established patterns
2. Fixes a real bug? **YES** — scheduling starvation causing high
latency/broken connections
3. Important issue? **YES** — connectivity loss for WiFi clients in
common multi-client scenarios
4. Small and contained? **YES** — ~20 lines, single file, two functions
5. No new features or APIs? **YES** — no new features
6. Can apply to stable? **YES** — with minor adaptation for older trees
### Step 9.3: Exception Categories
Not an exception category — this is a standard bug fix.
### Step 9.4: Decision
This is a clear bug fix for a significant scheduling starvation issue in
the mt76 WiFi driver. The fix is small, obviously correct, and addresses
a real user-visible problem (high latency, low throughput, broken
connections) that affects all mt76 WiFi users in multi-client scenarios.
## Verification
- [Phase 1] Parsed tags: Signed-off-by David Bauer (author) and Felix
Fietkau (maintainer/committer), Link to patch.msgid.link
- [Phase 2] Diff analysis: ~20 lines added in two functions in tx.c;
adds non-AQL limit check in scheduling loop + TXQ rescheduling on tx
completion
- [Phase 2] Verified `ieee80211_return_txq()` calls
`__ieee80211_schedule_txq()` which re-inserts at head with airtime
fairness (net/mac80211/tx.c lines 4116-4151)
- [Phase 2] Verified `ieee80211_next_txq()` terminates round when seeing
same TXQ's schedule_round (net/mac80211/tx.c lines 4103-4104)
- [Phase 3] git blame: non-AQL logic introduced in e1378e5228aaa1
(2020-08-23), first in v5.10-rc1
- [Phase 3] git describe: confirmed e1378e5228aaa1 is
`v5.10-rc1~107^2~150^2~2^2~34`
- [Phase 3] Existing `continue` pattern verified in
mt76_txq_schedule_list() for PS flag (line 542-543) and reset state
(line 546-547)
- [Phase 3] No dependent patches found; this is standalone
- [Phase 4] b4 dig: could not find match; lore blocked by anti-scraping
- [Phase 5] mt76_tx_check_non_aql called from __mt76_tx_complete_skb
(hot TX completion path, line 255)
- [Phase 5] mt76_txq_schedule_list called from mt76_txq_schedule →
mt76_txq_schedule_all → mt76_tx_worker_run (main TX worker)
- [Phase 6] Bug present in all stable trees 5.10.y through 6.12.y
(e1378e5228aaa1 in v5.10-rc1)
- [Phase 6] Backport needs minor adaptation for multi-radio refactoring
(716cc146d5805) and wcid_ptr wrapper (dc66a129adf1f)
- [Phase 8] Failure mode: scheduling starvation → high latency/broken
connections; severity HIGH
- UNVERIFIED: Exact mailing list review discussion (lore blocked);
however, maintainer merge provides implicit review confirmation
**YES**
drivers/net/wireless/mediatek/mt76/tx.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 9ec6d0b53a84a..0753acf2eccb8 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -227,7 +227,9 @@ mt76_tx_check_non_aql(struct mt76_dev *dev, struct mt76_wcid *wcid,
struct sk_buff *skb)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_sta *sta;
int pending;
+ int i;
if (!wcid || info->tx_time_est)
return;
@@ -235,6 +237,17 @@ mt76_tx_check_non_aql(struct mt76_dev *dev, struct mt76_wcid *wcid,
pending = atomic_dec_return(&wcid->non_aql_packets);
if (pending < 0)
atomic_cmpxchg(&wcid->non_aql_packets, pending, 0);
+
+ sta = wcid_to_sta(wcid);
+ if (!sta || pending != MT_MAX_NON_AQL_PKT - 1)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(sta->txq); i++) {
+ if (!sta->txq[i])
+ continue;
+
+ ieee80211_schedule_txq(dev->hw, sta->txq[i]);
+ }
}
void __mt76_tx_complete_skb(struct mt76_dev *dev, u16 wcid_idx, struct sk_buff *skb,
@@ -542,6 +555,9 @@ mt76_txq_schedule_list(struct mt76_phy *phy, enum mt76_txq_id qid)
if (!wcid || test_bit(MT_WCID_FLAG_PS, &wcid->flags))
continue;
+ if (atomic_read(&wcid->non_aql_packets) >= MT_MAX_NON_AQL_PKT)
+ continue;
+
phy = mt76_dev_phy(dev, wcid->phy_idx);
if (test_bit(MT76_RESET, &phy->state) || phy->offchannel)
continue;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: imx91-tqma9131: improve eMMC pad configuration
From: Sasha Levin @ 2026-04-20 13:07 UTC (permalink / raw)
To: patches, stable
Cc: Markus Niebel, Alexander Stein, Frank Li, Sasha Levin, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, linux, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
[ Upstream commit 44db7bc66eb38e85bb32777c5fd3a4e7baa84147 ]
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.
Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../boot/dts/freescale/imx91-tqma9131.dtsi | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
index 5792952b7a8e1..c99d7bc168483 100644
--- a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
@@ -272,20 +272,20 @@ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
/* enable SION for data and cmd pad due to ERR052021 */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = /* PD | FSEL 3 | DSE X5 */
- <MX91_PAD_SD1_CLK__USDHC1_CLK 0x5be>,
+ <MX91_PAD_SD1_CLK__USDHC1_CLK 0x59e>,
/* HYS | FSEL 0 | no drive */
<MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x1000>,
/* HYS | FSEL 3 | X5 */
- <MX91_PAD_SD1_CMD__USDHC1_CMD 0x400011be>,
+ <MX91_PAD_SD1_CMD__USDHC1_CMD 0x4000139e>,
/* HYS | FSEL 3 | X4 */
- <MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x4000119e>,
- <MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x4000119e>,
- <MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x4000119e>,
- <MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x4000119e>,
- <MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x4000119e>,
- <MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x4000119e>,
- <MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x4000119e>,
- <MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x4000119e>;
+ <MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x4000139e>,
+ <MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x4000139e>,
+ <MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x4000139e>,
+ <MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x4000139e>,
+ <MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x4000139e>,
+ <MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x4000139e>,
+ <MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x4000139e>,
+ <MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x4000139e>;
};
pinctrl_wdog: wdoggrp {
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] mmc: sdhci-esdhc-imx: wait for data transfer completion before reset
From: Sasha Levin @ 2026-04-20 13:07 UTC (permalink / raw)
To: patches, stable
Cc: Luke Wang, Bough Chen, Adrian Hunter, Ulf Hansson, Sasha Levin,
shawnguo, linux-imx, linux-mmc, linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Luke Wang <ziniu.wang_1@nxp.com>
[ Upstream commit 8ceb70c9f970bfbdceb1e51578850a60b9de2236 ]
On IMX7ULP platforms, certain SD cards (e.g. Kingston Canvas Go! Plus)
cause system hangs and reboots during manual tuning. These cards exhibit
large gaps (~16us) between tuning command response and data transmission.
When cmd CRC errors occur during tuning, the code assumes data errors even
tuning data hasn't been fully received and then reset host data circuit.
Per IMX7ULP reference manual, reset operations (RESET_DATA/ALL) need to
make sure no active data transfers. Previously, resetting while data was
in-flight would clear data circuit, including ADMA/SDMA address, causing
data to be transmitted to incorrect memory address. This patch adds
polling for data transfer completion before executing resets.
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Bough Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a comprehensive analysis. Let
me compile the final assessment.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem**: `mmc: sdhci-esdhc-imx:` (MMC host controller driver for
NXP i.MX ESDHC)
- **Action verb**: "wait" (defensive/preventive action)
- **Summary**: Wait for data transfer completion before resetting the
host data circuit to avoid system hang.
Record: [mmc: sdhci-esdhc-imx] [wait/prevent] [Prevent system hang by
ensuring data transfer is complete before reset]
### Step 1.2: Tags
- **Signed-off-by**: Luke Wang <ziniu.wang_1@nxp.com> (author, NXP
engineer)
- **Reviewed-by**: Bough Chen <haibo.chen@nxp.com> (NXP subsystem
maintainer for sdhci-esdhc-imx, prolific contributor)
- **Acked-by**: Adrian Hunter <adrian.hunter@intel.com> (senior
SDHCI/MMC subsystem maintainer)
- **Signed-off-by**: Ulf Hansson <ulf.hansson@linaro.org> (MMC subsystem
maintainer who merged this)
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable (expected)
- No Link: tag
Record: Reviewed by NXP subsystem expert (haibo.chen), ACK'd by sdhci
co-maintainer (Adrian Hunter), merged by MMC maintainer (Ulf Hansson).
Strong review chain.
### Step 1.3: Body Analysis
- **Bug**: On IMX7ULP platforms, certain SD cards (Kingston Canvas Go!
Plus) cause **system hangs and reboots** during manual tuning.
- **Root cause**: Large gaps (~16us) between tuning command response and
data transmission. When CRC errors occur during tuning, code resets
the host data circuit while data is still in-flight.
- **Failure mechanism**: Per IMX7ULP reference manual,
RESET_DATA/RESET_ALL must not be issued during active data transfer.
Resetting while data is in-flight clears the data circuit including
ADMA/SDMA address, causing **data to be transmitted to incorrect
memory address**.
- **Symptom**: System hang and reboot.
Record: Critical bug - system hang/reboot. DMA address corruption from
reset during active transfer. Hardware-documented requirement violated.
Specific SD card makes the timing gap visible.
### Step 1.4: Hidden Bug Fix Detection
This is NOT hidden - it's an explicit fix for system hangs. The commit
clearly describes a hardware requirement (per reference manual) that was
being violated, leading to DMA address corruption and system hangs.
Record: Explicit bug fix - system hang prevention. Not a disguised fix.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **Files changed**: 1 file (`drivers/mmc/host/sdhci-esdhc-imx.c`)
- **Lines added**: ~18 (2 for the define, 16 for the polling logic)
- **Lines removed**: 0
- **Functions modified**: `esdhc_reset()` - the core reset callback for
this driver
- **Scope**: Single-file, single-function, surgical fix
Record: [sdhci-esdhc-imx.c +18/-0] [esdhc_reset() modified] [Single-file
surgical fix]
### Step 2.2: Code Flow Change
1. **New define**: `ESDHC_DATA_INHIBIT_WAIT_US 100000` (100ms timeout)
2. **Before**: `esdhc_reset()` directly called `sdhci_and_cqhci_reset()`
without checking data transfer state
3. **After**: Before reset, if the reset mask includes
`SDHCI_RESET_DATA` or `SDHCI_RESET_ALL`, poll `ESDHC_PRSSTAT`
register waiting for `SDHCI_DATA_INHIBIT` to clear (indicating no
active data transfer). Timeout at 100ms with a warning. Then proceed
to reset.
Record: Added defensive wait-for-idle before data/full reset. 100ms
timeout with warning on failure. Non-blocking (proceeds even on
timeout).
### Step 2.3: Bug Mechanism
Category: **Hardware workaround / DMA corruption fix**
- The bug is a violation of hardware specification requirements (IMX7ULP
reference manual)
- Resetting while `SDHCI_DATA_INHIBIT` is set clears ADMA/SDMA addresses
mid-transfer
- Data goes to wrong memory address → system hang/reboot (effectively
memory corruption)
- The fix polls the Present State register bit 1 (DATA_INHIBIT) before
issuing reset
- Uses `readl_poll_timeout_atomic` with 2us polling interval and 100ms
max wait
Record: [HW requirement violation → DMA address corruption → system
hang] [Fix: poll for data idle before reset]
### Step 2.4: Fix Quality
- **Obviously correct**: Yes. The reference manual explicitly requires
waiting. The pattern of polling ESDHC_PRSSTAT is already used twice in
this driver (lines 471, 1028).
- **Minimal/surgical**: Yes. Only adds the required wait before existing
reset call.
- **Regression risk**: Very low. On timeout, it warns but still proceeds
with reset (graceful degradation). The 100ms timeout is generous.
Using `readl_poll_timeout_atomic` is appropriate since reset can be
called from interrupt context.
- **Red flags**: None. Well-contained, uses established patterns from
the same driver.
Record: High quality fix. Uses existing driver patterns. Graceful
timeout handling. Minimal regression risk.
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
- `esdhc_reset()` introduced in commit `0718e59ae259f7` by Russell King
(2014-04-25), present since ~v3.16
- Modified by `fb1dec44c6750b` (Brian Norris, 2022-10-26) to use
`sdhci_and_cqhci_reset`, present since v6.2
- The function has been stable in its current form since v6.2
Record: esdhc_reset() has existed since v3.16 (2014). Current form since
v6.2. Bug has been present since the function was introduced - the
hardware requirement was never respected.
### Step 3.2: No Fixes: tag present (expected).
### Step 3.3: File History
Recent changes to the file are mostly tuning-related fixes (manual
tuning, clock loopback, PM refactoring). The `esdhc_reset()` function
itself hasn't been touched recently (last change was the cqhci fix in
2022).
Record: No prerequisites identified. The fix is standalone.
### Step 3.4: Author
Luke Wang (ziniu.wang_1@nxp.com) is a regular NXP contributor with 14+
commits in the MMC subsystem and sdhci-esdhc-imx driver specifically.
He's contributed tuning improvements, PM refactoring, and other driver
fixes.
Record: Regular subsystem contributor from the hardware vendor (NXP).
### Step 3.5: Dependencies
- Uses `readl_poll_timeout_atomic` from `<linux/iopoll.h>` - already
included in all stable versions
- Uses `ESDHC_PRSSTAT` and `SDHCI_DATA_INHIBIT` - both already defined
- Uses `SDHCI_RESET_DATA` and `SDHCI_RESET_ALL` - standard SDHCI defines
- Only dependency: `sdhci_and_cqhci_reset` (present since v6.2). For
v5.15, the function uses `sdhci_reset` instead - minor backport
adjustment needed.
Record: Fully standalone for v6.1+. Minor adjustment needed for v5.15
(different reset function name). All APIs/macros already available.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1-4.5
I was unable to find the specific mailing list thread for this patch via
b4 dig (commit not in tree) or web searches. The patch was found
indirectly via the "1-bit bus width" series which built on top of the
file state after this patch was applied (blob `97461e20425d`).
The commit has strong review signals:
- **Reviewed-by** from Bough Chen (NXP maintainer of this driver, 30+
commits)
- **Acked-by** from Adrian Hunter (SDHCI co-maintainer, 100+ SDHCI
commits)
- **Signed-off-by** from Ulf Hansson (MMC subsystem maintainer who
merged it)
Record: Could not find lore thread directly (commit not yet in tree).
But review chain is complete: hardware vendor reviewer + SDHCI
maintainer ACK + subsystem maintainer merge.
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Functions Modified
- `esdhc_reset()` - the `.reset` callback in `sdhci_esdhc_ops`
### Step 5.2: Callers
`esdhc_reset` is called via `sdhci_do_reset()` (line 247 of sdhci.c)
through the ops->reset function pointer. `sdhci_do_reset` is called
from:
- `sdhci_reset_for_all()` - init, suspend/resume paths (SDHCI_RESET_ALL)
- `sdhci_reset_for_reason()` - error recovery, tuning abort, card
removal, CQE recovery (SDHCI_RESET_CMD, SDHCI_RESET_DATA)
- These are called from tuning abort, data error paths, card removal,
CQE recovery, and initialization
The fix specifically triggers on `SDHCI_RESET_DATA | SDHCI_RESET_ALL`,
which covers error recovery (data errors, request errors) and full
initialization.
Record: Called from multiple critical paths - error recovery, tuning
abort, card removal, init. High-traffic code path.
### Step 5.3-5.4: The affected code path is triggered during normal card
operations (tuning, error recovery). Any user of an i.MX SDHCI host
controller can trigger this.
### Step 5.5: Similar Patterns
The Freescale ESDHC of-driver (`sdhci-of-esdhc.c`) has a separate
`quirk_ignore_data_inhibit` for unreliable DATA_INHIBIT bits on some
controllers. The `readl_poll_timeout` pattern is already used twice in
this same driver for similar hardware waits.
Record: Pattern is consistent with existing driver practices.
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Buggy Code in Stable Trees
- `esdhc_reset()` exists in **all stable trees** (v5.15, v6.1, v6.6,
v6.12, v6.19)
- The bug has been present since the function was introduced in v3.16
(2014)
- IMX7ULP support was added before v5.15
Record: Bug exists in ALL active stable trees.
### Step 6.2: Backport Complications
- For v6.1, v6.6, v6.12, v6.19: Patch applies cleanly. `esdhc_reset()`
is identical.
- For v5.15: Minor adjustment needed - function calls `sdhci_reset()`
instead of `sdhci_and_cqhci_reset()`, but the added code goes BEFORE
that call, so it's unaffected.
Record: Clean apply for v6.1+. Trivial adjustment for v5.15.
### Step 6.3: No related fixes already in stable for this issue.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1
- **Subsystem**: drivers/mmc/host - MMC host controller drivers
- **Criticality**: IMPORTANT - MMC/SD cards are used for storage on
embedded platforms, IoT devices, and Android devices running i.MX
SoCs. System hangs on these platforms = production device failure.
### Step 7.2
The sdhci-esdhc-imx driver is actively maintained by NXP engineers. 28
changes between v6.6 and v6.19.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Affected Population
- Users of NXP i.MX SoCs with SDHCI host controllers (IMX7ULP
specifically named, but the fix applies to all i.MX ESDHC variants)
- Embedded/IoT devices, industrial controllers, automotive platforms
using NXP i.MX chips
- The bug is triggered with specific SD cards (Kingston Canvas Go! Plus
mentioned) during tuning
### Step 8.2: Trigger Conditions
- Occurs during SD card tuning (happens on card initialization/re-
initialization)
- Triggered when CRC errors occur during tuning while data has gaps in
transmission
- Not every card triggers it - depends on card timing characteristics
- Can happen on any boot/card insertion with affected cards
### Step 8.3: Failure Mode Severity
- **System hang and reboot** = CRITICAL
- DMA writes to incorrect memory address = potential **memory
corruption**
- The reset clears ADMA/SDMA addresses, so DMA writes to address 0 or
stale address
- This is a hardware-documented requirement violation
Record: CRITICAL severity. System hang, reboot, potential memory
corruption.
### Step 8.4: Risk-Benefit Ratio
- **BENEFIT**: HIGH - prevents system hangs/reboots on NXP i.MX
platforms with certain SD cards
- **RISK**: VERY LOW
- ~18 lines added, single function, single file
- Uses existing patterns from the same driver
- Graceful timeout (warning + proceed) prevents any new hangs from the
fix itself
- `readl_poll_timeout_atomic` is safe for all calling contexts
- Only adds a wait before an existing operation
Record: HIGH benefit / VERY LOW risk. Strongly favorable ratio.
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backporting:**
1. Fixes **system hangs and reboots** (CRITICAL severity)
2. Fixes **DMA address corruption** from violating hardware
specification
3. Small, surgical fix (~18 lines in one function, one file)
4. Uses existing patterns from the same driver (`readl_poll_timeout`)
5. Reviewed by NXP driver maintainer (haibo.chen), ACK'd by SDHCI co-
maintainer (Adrian Hunter), merged by MMC maintainer (Ulf Hansson)
6. Author is NXP engineer with deep knowledge of the hardware
7. Bug exists in ALL active stable trees (code unchanged since v6.2)
8. Patch applies cleanly to v6.1+ with no modifications needed
9. Graceful degradation on timeout (warn + continue)
10. References hardware reference manual as justification
**AGAINST backporting:**
- No concrete signals against. The fix is well-contained and low-risk.
**UNRESOLVED:**
- Could not find the original lore thread (commit appears very
recent/not yet merged)
- No Fixes: tag identifying original buggy commit (but bug has existed
since 2014)
### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES - follows hardware manual
requirement, reviewed by 3 maintainers, uses established driver
patterns
2. **Fixes a real bug?** YES - system hangs and reboots on real hardware
with real SD cards
3. **Important issue?** YES - system hang, reboot, DMA corruption =
CRITICAL
4. **Small and contained?** YES - ~18 lines, single function, single
file
5. **No new features/APIs?** CORRECT - no new features, just defensive
hardware wait
6. **Can apply to stable?** YES - applies cleanly to v6.1+, minor
adjustment for v5.15
### Step 9.3: Exception Categories
Not needed - this meets standard stable criteria as a critical bug fix.
### Step 9.4: Decision
This is a clear YES. It fixes a **critical** system hang/reboot caused
by violating a hardware-documented requirement, with a small, surgical,
well-reviewed patch that carries minimal regression risk.
## Verification
- [Phase 1] Parsed tags: Reviewed-by: haibo.chen (NXP), Acked-by: Adrian
Hunter (SDHCI maintainer), SOB: Ulf Hansson (MMC maintainer)
- [Phase 2] Diff analysis: ~18 lines added to `esdhc_reset()`, adds
`readl_poll_timeout_atomic` for DATA_INHIBIT before reset
- [Phase 2] Verified `readl_poll_timeout_atomic` is defined in
`include/linux/iopoll.h` (line 230)
- [Phase 2] Verified `ESDHC_PRSSTAT` defined at offset 0x24 in `sdhci-
esdhc.h` (line 34), same as `SDHCI_PRESENT_STATE`
- [Phase 2] Verified `SDHCI_DATA_INHIBIT` is 0x00000002 at `sdhci.h:82`
- [Phase 3] git blame: `esdhc_reset()` introduced in `0718e59ae259f7`
(2014), modified by `fb1dec44c6750b` (2022)
- [Phase 3] Confirmed `sdhci_and_cqhci_reset` present in v6.1 and v6.6
via `git merge-base --is-ancestor`
- [Phase 3] Confirmed `esdhc_reset()` in v6.1 and v6.6 is identical to
current mainline (before this patch)
- [Phase 3] Author Luke Wang has 14+ commits in MMC subsystem, regular
NXP contributor
- [Phase 3] No prerequisites identified - patch is standalone
- [Phase 4] b4 dig could not find thread (commit not in tree). Web
searches confirmed author's other patches and expertise.
- [Phase 5] `esdhc_reset` called via `sdhci_do_reset()` from error
recovery, tuning abort, init, CQE recovery paths
- [Phase 5] `readl_poll_timeout` pattern already used twice in this
driver (lines 471, 1028)
- [Phase 6] Confirmed `esdhc_reset()` exists identically in v6.1 and
v6.6 stable trees
- [Phase 6] Confirmed `<linux/iopoll.h>` is included in v6.1 (verified
directly)
- [Phase 6] For v5.15, `esdhc_reset` uses `sdhci_reset()` instead -
minor backport adjustment needed
- [Phase 7] IMX7ULP support (`usdhc_imx7ulp_data`) present in driver,
confirmed at line 324
- [Phase 8] Failure mode: system hang + reboot + DMA address corruption
→ CRITICAL severity
- UNVERIFIED: Could not access the original lore thread for this
specific patch
**YES**
drivers/mmc/host/sdhci-esdhc-imx.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index a7a5df673b0f6..97461e20425d8 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -216,6 +216,8 @@
#define ESDHC_FLAG_DUMMY_PAD BIT(19)
#define ESDHC_AUTO_TUNING_WINDOW 3
+/* 100ms timeout for data inhibit */
+#define ESDHC_DATA_INHIBIT_WAIT_US 100000
enum wp_types {
ESDHC_WP_NONE, /* no WP, neither controller nor gpio */
@@ -1453,6 +1455,22 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
static void esdhc_reset(struct sdhci_host *host, u8 mask)
{
+ u32 present_state;
+ int ret;
+
+ /*
+ * For data or full reset, ensure any active data transfer completes
+ * before resetting to avoid system hang.
+ */
+ if (mask & (SDHCI_RESET_DATA | SDHCI_RESET_ALL)) {
+ ret = readl_poll_timeout_atomic(host->ioaddr + ESDHC_PRSSTAT, present_state,
+ !(present_state & SDHCI_DATA_INHIBIT), 2,
+ ESDHC_DATA_INHIBIT_WAIT_US);
+ if (ret == -ETIMEDOUT)
+ dev_warn(mmc_dev(host->mmc),
+ "timeout waiting for data transfer completion\n");
+ }
+
sdhci_and_cqhci_reset(host, mask);
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: imx93-tqma9352: improve eMMC pad configuration
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Markus Niebel, Alexander Stein, Frank Li, Sasha Levin, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, linux, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
[ Upstream commit b6c94c71f349479b76fcc0ef0dc7147f3f326dff ]
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.
Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../boot/dts/freescale/imx93-tqma9352.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
index 82914ca148d3a..c095d7f115c21 100644
--- a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
@@ -270,21 +270,21 @@ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x106
/* enable SION for data and cmd pad due to ERR052021 */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
- /* PD | FSEL 3 | DSE X5 */
- MX93_PAD_SD1_CLK__USDHC1_CLK 0x5be
+ /* PD | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x59e
/* HYS | FSEL 0 | no drive */
MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1000
- /* HYS | FSEL 3 | X5 */
- MX93_PAD_SD1_CMD__USDHC1_CMD 0x400011be
- /* HYS | FSEL 3 | X4 */
- MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000119e
- MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000119e
- MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000119e
- MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000119e
- MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000119e
- MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000119e
- MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000119e
- MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000119e
+ /* HYS | PU | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000139e
+ /* HYS | PU | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000139e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000139e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000139e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000139e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000139e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000139e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000139e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000139e
>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] media: rc: fix race between unregister and urb/irq callbacks
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Sean Young, Haotian Zhang, Patrice Chotard, Hans Verkuil,
Sasha Levin, andrzej.hajda, neil.armstrong, rfoss, airlied,
daniel, bonbons, jikos, benjamin.tissoires, hverkuil-cisco,
mchehab, maximlevitsky, wens, jernej.skrabec, samuel, david,
benpicco, crope, gregkh, dri-devel, linux-kernel, linux-input,
linux-media, linux-arm-kernel, linux-sunxi, linux-staging
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Sean Young <sean@mess.org>
[ Upstream commit dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 ]
Some rc device drivers have a race condition between rc_unregister_device()
and irq or urb callbacks. This is because rc_unregister_device() does two
things, it marks the device as unregistered so no new commands can be
issued and then it calls rc_free_device(). This means the driver has no
chance to cancel any pending urb callbacks or interrupts after the device
has been marked as unregistered. Those callbacks may access struct rc_dev
or its members (e.g. struct ir_raw_event_ctrl), which have been freed by
rc_free_device().
This change removes the implicit call to rc_free_device() from
rc_unregister_device(). This means that device drivers can call
rc_unregister_device() in their remove or disconnect function, then cancel
all the urbs and interrupts before explicitly calling rc_free_device().
Note this is an alternative fix for an issue found by Haotian Zhang, see
the Closes: tags.
Reported-by: Haotian Zhang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Good - drivers using `devm_rc_allocate_device` don't call
`rc_unregister_device` manually (they use `devm_rc_register_device`
which handles cleanup automatically). The patch removes the
`managed_alloc` flag because it changes the contract:
`rc_unregister_device` no longer frees the device regardless of how it
was allocated. Instead, `devm_rc_alloc_release` (the devres release
callback) calls `rc_free_device`, and the regular drivers must add
explicit `rc_free_device` calls.
Now let me do the full analysis write-up.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
Record: [media: rc] [fix] [race between unregister and urb/irq
callbacks]
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reported-by:** Haotian Zhang <vulab@iscas.ac.cn> - the reporter
found multiple race conditions
- **Closes:** 4 separate lore.kernel.org links to bug reports (Nov 2025)
- **Reviewed-by:** Patrice Chotard <patrice.chotard@foss.st.com>
- **Signed-off-by:** Sean Young <sean@mess.org> (author, RC subsystem
maintainer)
- **Signed-off-by:** Hans Verkuil <hverkuil+cisco@kernel.org> (media
subsystem maintainer)
Record: Multiple bug reports (4 Closes: tags), reviewed by a maintainer,
written by the RC subsystem maintainer, merged by the media subsystem
maintainer. No Fixes: tag (expected).
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explains a **use-after-free race condition**:
1. `rc_unregister_device()` marks the device as unregistered
2. Then it calls `rc_free_device()`, which frees `struct rc_dev` and
`struct ir_raw_event_ctrl`
3. Between marking unregistered and freeing, there's no window for
drivers to cancel pending URBs/IRQs
4. Those pending callbacks may still access the freed `struct rc_dev` or
its members
Record: Bug = use-after-free due to race between device unregister and
URB/IRQ callbacks. Symptom = accessing freed memory. Root cause =
`rc_unregister_device()` implicitly calls `rc_free_device()` before
drivers can cancel pending async operations.
### Step 1.4: DETECT HIDDEN BUG FIXES
This is an explicit race condition / use-after-free fix. Not hidden.
Record: This is a clear, well-documented bug fix.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
41 files changed, ~58 insertions, ~36 deletions. Files span:
- Core: `rc-main.c`, `rc-ir-raw.c`, `rc-core.h`
- ~30+ driver files across media/rc, media/pci, media/usb, gpu/drm, hid,
staging
Record: Cross-subsystem change touching 41 files, but each driver change
is 1-3 lines. Core changes are ~10 lines net.
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Core changes:**
1. `rc-main.c`: `rc_unregister_device()` no longer calls
`rc_free_device()` (removes the `if (!dev->managed_alloc)
rc_free_device(dev)` block)
2. `rc-main.c`: `rc_dev_release()` now calls `ir_raw_event_free(dev)`
before `kfree(dev)` - this ensures raw event data is cleaned up when
the device struct is finally freed
3. `rc-main.c`: `devm_rc_allocate_device()` no longer sets
`managed_alloc = true`
4. `rc-ir-raw.c`: `ir_raw_event_unregister()` no longer calls
`ir_raw_event_free()` (moved to `rc_dev_release`)
5. `rc-ir-raw.c`: `ir_raw_event_free()` removes the `if (!dev)` guard
(now only called from `rc_dev_release`)
6. `rc-core.h`: Removes `managed_alloc` field from `struct rc_dev`
**Driver changes:** Every driver using `rc_unregister_device()` now also
calls `rc_free_device()` afterward. Some USB drivers also reorder
operations to call `rc_unregister_device()` BEFORE killing URBs, then
`rc_free_device()` AFTER killing URBs.
### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Race condition / Use-after-free**
Before the fix:
```
rc_unregister_device()
-> marks device unregistered
-> calls rc_free_device() -> frees struct rc_dev
// URB/IRQ callbacks can still fire and access freed rc_dev!
```
After the fix:
```
rc_unregister_device()
-> marks device unregistered
// Driver cancels URBs/IRQs here
rc_free_device()
-> safely frees struct rc_dev after all callbacks cancelled
```
Record: UAF race condition fix. Separating unregister from free gives
drivers a window to cancel async operations.
### Step 2.4: ASSESS THE FIX QUALITY
- Written by Sean Young (RC subsystem maintainer)
- Reviewed by Patrice Chotard
- Merged by Hans Verkuil (media maintainer)
- The approach is sound: it separates two concerns (marking unregistered
vs. freeing memory)
- Each per-driver change is trivial (add one `rc_free_device()` line)
- **Concern:** The scope is very large (41 files), though each change is
trivially mechanical
Record: High quality fix from the subsystem maintainer. Regression risk
is low per-driver but the sheer breadth is notable. The error path
changes in probe functions (removing `rdev = NULL` after
`rc_unregister_device`) are now correct because `rc_free_device(rdev)`
on the next goto target will properly free even after unregister.
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
The `managed_alloc` logic was introduced in commit `ddbf7d5a698c4d`
(2016, v4.10 era) by Heiner Kallweit. The implicit `rc_free_device()`
call in `rc_unregister_device()` has been present since `d8b4b5822f51e2`
(2010, v2.6.36 era). The race condition has existed since the very
beginning of the rc_core subsystem.
Record: Bug exists in all kernel versions since 2010 (v2.6.36+). Present
in all stable trees.
### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present (expected for autosel candidates).
### Step 3.3: CHECK FILE HISTORY
Multiple previous fixes for the same class of UAF bugs exist:
- `5abda7a16698d` "media: dm1105: Fix use after free bug in
dm1105_remove due to race condition"
- `29b0589a865b6` "media: rc: Fix use-after-free bugs caused by
ene_tx_irqsim()"
These were individual driver fixes for the same systemic issue. This
patch fixes it once and for all in the core.
Record: This is a systemic fix replacing multiple individual driver-
level workarounds.
### Step 3.4: CHECK THE AUTHOR
Sean Young is the RC subsystem maintainer. He has dozens of commits in
`drivers/media/rc/`. This is his subsystem.
Record: Author is the subsystem maintainer - highest trust level.
### Step 3.5: CHECK FOR DEPENDENCIES
This is a single, self-contained patch. All changes are coordinated. No
other patches are needed.
Record: Standalone fix, no dependencies.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Found via web search:
- v1: "[PATCH] media: rc: rc_unregister_device() should not call
rc_free_device()" (Dec 20, 2025)
- v2: "[PATCH v2] media: rc: fix race between unregister and urb/irq
callbacks" (Jan 26, 2026)
The v2 has the `Reviewed-by` tag from Patrice Chotard that v1 didn't
have.
Record: Patch went through 2 revisions. Applied version is v2 (latest).
Reviewed by maintainer.
### Step 4.2: WHO REVIEWED
- Reviewed-by: Patrice Chotard (STMicroelectronics, works on st_rc
driver)
- Signed-off-by: Hans Verkuil (media subsystem co-maintainer)
- CC'd: Numerous subsystem maintainers (Maarten Lankhorst, David Airlie
for DRM, etc.)
Record: Properly reviewed through the maintainer chain.
### Step 4.3: SEARCH FOR THE BUG REPORT
4 separate bug reports from Haotian Zhang (November 2025) about UAF
races in different RC drivers.
Record: Multiple independent bug reports confirm this is a real-world
issue.
### Step 4.4: RELATED PATCHES
This is the alternative/comprehensive fix. The original individual
patches from Haotian Zhang addressed each driver separately; Sean
Young's approach fixes the root cause in the core.
Record: This is the definitive fix rather than per-driver workarounds.
### Step 4.5: STABLE MAILING LIST
No specific stable discussion found. The patch does not have Cc: stable
tag.
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: KEY FUNCTIONS
- `rc_unregister_device()` - modified to remove implicit free
- `rc_free_device()` - now must be called explicitly by drivers
- `rc_dev_release()` - now frees raw event data
- `ir_raw_event_free()` - moved from unregister path to release path
- `ir_raw_event_unregister()` - no longer frees raw events
### Step 5.2: CALLERS
Every RC driver's remove/disconnect/exit function calls
`rc_unregister_device()`. The patch adds `rc_free_device()` to all of
them. This affects USB IR receivers, PCI TV tuner cards, embedded IR
receivers, DRM bridges, etc.
Record: Broad impact - every RC device driver is affected.
### Step 5.3-5.5: CALL CHAIN AND PATTERNS
The race is triggered during device removal (USB disconnect, PCI remove,
platform remove). This is a common path triggered by:
- USB device physical disconnect
- Module unload
- System shutdown
- Device unbind via sysfs
Record: The buggy path is easily triggered by physical device
disconnect. Not theoretical.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?
Yes. The buggy code in `rc_unregister_device()` (calling
`rc_free_device()` implicitly) has existed since 2010. It is present in
ALL stable trees.
Record: Bug affects all stable trees (6.6.y, 6.1.y, 5.15.y, etc.).
### Step 6.2: BACKPORT COMPLICATIONS
This patch touches 41 files. Some files may have diverged between
mainline and stable trees. Backporting will likely require resolving
minor conflicts in some drivers. The core changes to `rc-main.c`, `rc-
ir-raw.c`, and `rc-core.h` are critical and should apply with minor
fuzz. The per-driver changes are mechanical and can be adapted.
Record: Expected difficulty: **medium**. Core changes likely apply
cleanly. Some driver-specific changes may need minor adjustment due to
driver-specific changes in stable trees vs mainline.
### Step 6.3: RELATED FIXES IN STABLE
Individual UAF fixes like `5abda7a16698d` (dm1105) and `29b0589a865b6`
(ene_ir) may already be in some stable trees, but they only fix specific
drivers. This systemic fix is comprehensive.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: SUBSYSTEM CRITICALITY
Media/RC subsystem - used by IR receivers on:
- TV tuner cards (USB and PCI)
- Media center remotes (iMON, MCE, Xbox)
- Embedded IR receivers (sunxi, meson, hix5hd2)
- DRM bridges with CEC/RC
Record: IMPORTANT level - affects users of IR remote control hardware
(common in HTPCs, embedded media devices).
### Step 7.2: SUBSYSTEM ACTIVITY
Active subsystem with regular maintenance from Sean Young.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
All users with IR remote control hardware who disconnect or unbind the
device. This includes USB IR receivers (very common for HTPC setups),
PCI TV tuner cards with IR, and embedded systems with hardware IR.
Record: Moderate user population - anyone using Linux with IR remote
control hardware.
### Step 8.2: TRIGGER CONDITIONS
- Physical USB disconnect of IR receiver
- Module unload while IR device active
- Device unbind via sysfs
- System shutdown with pending IR operations
- Concurrent with incoming IR data
Record: Common trigger conditions. USB disconnect is the most frequent.
### Step 8.3: FAILURE MODE SEVERITY
Use-after-free: Accessing freed `struct rc_dev` or `struct
ir_raw_event_ctrl` from URB/IRQ callbacks. This leads to:
- Kernel crash/oops (most likely)
- Memory corruption (possible)
- Security vulnerability (potential, if attacker controls USB device)
Record: Severity: HIGH to CRITICAL. UAF can cause crashes and is
potentially exploitable.
### Step 8.4: RISK-BENEFIT RATIO
**Benefit:** HIGH - Fixes use-after-free race in all RC drivers
systemically. Prevents crashes during device disconnect. Fixes reported
real-world bug.
**Risk:** MEDIUM - 41 files touched, but each change is 1-3 lines and
mechanically identical (add `rc_free_device()` after
`rc_unregister_device()`). The core API change is well-designed. Some
USB drivers also reorder operations to call `rc_unregister_device()`
before `usb_kill_urb()`, which is the correct order.
Record: Benefit HIGH, Risk MEDIUM. The fix is well-designed but the
scope is large.
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**Evidence FOR backporting:**
- Fixes a real use-after-free race condition
- Multiple independent bug reports (4 Closes: tags)
- Written and signed by the RC subsystem maintainer (Sean Young)
- Reviewed by Patrice Chotard, merged by Hans Verkuil
- Bug has existed since 2010, affects all stable trees
- Previous individual driver fixes confirm this is a known issue pattern
- UAF can cause kernel crashes and is potentially exploitable
- The fix is logically correct - it separates unregister from free
**Evidence AGAINST backporting:**
- Very large scope: 41 files modified across multiple subsystems
- Changes a core API contract (rc_unregister_device no longer frees)
- Risk of backport conflicts due to per-driver divergence between
mainline and stable
- Some drivers may not exist in older stable trees, requiring manual
adaptation
- Removes `managed_alloc` infrastructure, affecting
`devm_rc_allocate_device()` users
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - reviewed by maintainers,
applied to mainline
2. Fixes a real bug? **YES** - UAF race condition with 4 bug reports
3. Important issue? **YES** - use-after-free / crash during device
disconnect
4. Small and contained? **NO** - 41 files is very large. However, each
change is mechanical (1-3 lines per file) and the core change is
small (~10 lines)
5. No new features or APIs? **YES** - only changes existing API behavior
6. Can apply to stable trees? **PARTIALLY** - core changes likely apply;
some driver changes may need adaptation
### Step 9.3: EXCEPTION CATEGORIES
Not applicable - this is a bug fix, not a device ID/quirk/DT/build fix.
### Step 9.4: DECISION
This is a genuine, important use-after-free fix from the subsystem
maintainer with multiple independent bug reports. However, the **scope
is extremely large** (41 files across multiple subsystems) and it
changes a core API contract. While each individual change is trivial and
mechanical, the sheer number of files makes this a high-risk backport.
If even one driver is missed or adapted incorrectly, it introduces a new
bug (memory leak from missing `rc_free_device()` or double-free from
calling it when not needed).
The stable kernel rules explicitly require patches to be "small and
contained." While the fix itself is correct and important, 41 files
touching DRM, HID, media PCI, media USB, and staging subsystems is not
small and contained. A backport of this magnitude would need careful
manual review for each stable tree to handle driver-specific divergence.
Verification:
- [Phase 1] Parsed tags: Reported-by: Haotian Zhang, 4 Closes: links,
Reviewed-by: Patrice Chotard, Signed-off-by: Sean Young (author/RC
maintainer), Hans Verkuil (media maintainer)
- [Phase 2] Diff analysis: 41 files changed, core change removes
implicit rc_free_device() from rc_unregister_device(), each driver
adds explicit rc_free_device() call
- [Phase 2] Verified: Current rc_unregister_device() at line 2046 has
`if (!dev->managed_alloc) rc_free_device(dev)` - confirmed the bug
exists
- [Phase 2] Verified: rc_dev_release() at line 1610 currently just does
`kfree(dev)` without freeing raw events - patch adds
ir_raw_event_free(dev) there
- [Phase 3] git blame: rc_unregister_device() implicit free from
d8b4b5822f51e2 (2010, v2.6.36), managed_alloc from ddbf7d5a698c4d
(2016, v4.10)
- [Phase 3] git show ddbf7d5a698c4d: confirmed managed_alloc was
introduced by Heiner Kallweit in 2016
- [Phase 3] Found related individual driver UAF fixes: 5abda7a16698d
(dm1105), 29b0589a865b6 (ene_ir)
- [Phase 3] git show 5abda7a16698d: confirmed dm1105 UAF race diagram
showing exactly the same pattern
- [Phase 4] Web search found v1 and v2 submissions: v1 Dec 2025, v2 Jan
26 2026
- [Phase 4] Found full v2 patch on freedesktop.org archives - matches
commit
- [Phase 4] 4 separate bug reports from Haotian Zhang (Nov 2025) confirm
real-world issue
- [Phase 5] Verified devm_rc_allocate_device callers (gpio-ir-recv,
meson-ir, etc.) don't manually call rc_unregister_device - they use
devm path, so they're unaffected
- [Phase 6] Bug exists since v2.6.36 (2010) - present in all stable
trees
- [Phase 8] Trigger: USB device disconnect during IR activity - common
operation
- UNVERIFIED: Whether all 41 files exist in all stable trees (some
drivers may have been added/removed between releases)
This is a borderline case. The fix addresses a real, reported use-after-
free bug from the subsystem maintainer with proper review. However, the
41-file scope makes it risky for stable. On balance, the UAF is serious
enough (crash, potential security) that it warrants backporting despite
the large scope, especially since each per-driver change is mechanically
identical and trivially verifiable.
**YES**
drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
drivers/hid/hid-picolcd_cir.c | 1 +
drivers/media/cec/core/cec-core.c | 2 +-
drivers/media/common/siano/smsir.c | 1 +
drivers/media/i2c/ir-kbd-i2c.c | 2 ++
drivers/media/pci/bt8xx/bttv-input.c | 3 ++-
drivers/media/pci/cx23885/cx23885-input.c | 1 +
drivers/media/pci/cx88/cx88-input.c | 3 ++-
drivers/media/pci/dm1105/dm1105.c | 1 +
drivers/media/pci/mantis/mantis_input.c | 1 +
drivers/media/pci/saa7134/saa7134-input.c | 1 +
drivers/media/pci/smipcie/smipcie-ir.c | 1 +
drivers/media/pci/ttpci/budget-ci.c | 1 +
drivers/media/rc/ati_remote.c | 6 +++---
drivers/media/rc/ene_ir.c | 2 +-
drivers/media/rc/fintek-cir.c | 3 ++-
drivers/media/rc/igorplugusb.c | 1 +
drivers/media/rc/iguanair.c | 1 +
drivers/media/rc/img-ir/img-ir-hw.c | 3 ++-
drivers/media/rc/img-ir/img-ir-raw.c | 3 ++-
drivers/media/rc/imon.c | 3 ++-
drivers/media/rc/ir-hix5hd2.c | 2 +-
drivers/media/rc/ir_toy.c | 1 +
drivers/media/rc/ite-cir.c | 2 +-
drivers/media/rc/mceusb.c | 1 +
drivers/media/rc/rc-ir-raw.c | 5 -----
drivers/media/rc/rc-loopback.c | 1 +
drivers/media/rc/rc-main.c | 6 +-----
drivers/media/rc/redrat3.c | 4 +++-
drivers/media/rc/st_rc.c | 2 +-
drivers/media/rc/streamzap.c | 7 ++++---
drivers/media/rc/sunxi-cir.c | 1 +
drivers/media/rc/ttusbir.c | 2 +-
drivers/media/rc/winbond-cir.c | 2 +-
drivers/media/rc/xbox_remote.c | 5 +++--
drivers/media/usb/au0828/au0828-input.c | 1 +
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 +
drivers/media/usb/dvb-usb/dvb-usb-remote.c | 6 ++++--
drivers/media/usb/em28xx/em28xx-input.c | 1 +
drivers/staging/media/av7110/av7110_ir.c | 1 +
include/media/rc-core.h | 2 --
41 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c
index d3f238b1f2a94..982306eb4f0a7 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2221,6 +2221,7 @@ static void sii8620_detach(struct drm_bridge *bridge)
return;
rc_unregister_device(ctx->rc_dev);
+ rc_free_device(ctx->rc_dev);
}
static int sii8620_is_packing_required(struct sii8620 *ctx,
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index d6faa0e00f95a..6d4c636e1c9f7 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -134,5 +134,6 @@ void picolcd_exit_cir(struct picolcd_data *data)
data->rc_dev = NULL;
rc_unregister_device(rdev);
+ rc_free_device(rdev);
}
diff --git a/drivers/media/cec/core/cec-core.c b/drivers/media/cec/core/cec-core.c
index 1953ce559ecaf..0fcd3b5e60c8d 100644
--- a/drivers/media/cec/core/cec-core.c
+++ b/drivers/media/cec/core/cec-core.c
@@ -338,8 +338,8 @@ int cec_register_adapter(struct cec_adapter *adap,
res = cec_devnode_register(&adap->devnode, adap->owner);
if (res) {
#ifdef CONFIG_MEDIA_CEC_RC
- /* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
+ rc_free_device(adap->rc);
adap->rc = NULL;
#endif
return res;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index af07fed21ae12..283770d583d56 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -92,6 +92,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
void sms_ir_exit(struct smscore_device_t *coredev)
{
rc_unregister_device(coredev->ir.dev);
+ rc_free_device(coredev->ir.dev);
pr_debug("\n");
}
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 5588cdd7ec20d..6047453170043 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -355,6 +355,7 @@ static void ir_work(struct work_struct *work)
mutex_unlock(&ir->lock);
if (rc == -ENODEV) {
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
ir->rc = NULL;
return;
}
@@ -972,6 +973,7 @@ static void ir_remove(struct i2c_client *client)
i2c_unregister_device(ir->tx_c);
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
}
static const struct i2c_device_id ir_kbd_id[] = {
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 373b6c6817d76..f704476506e07 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -572,8 +572,9 @@ void bttv_input_fini(struct bttv *btv)
if (btv->remote == NULL)
return;
- bttv_ir_stop(btv);
rc_unregister_device(btv->remote->dev);
+ bttv_ir_stop(btv);
+ rc_free_device(btv->remote->dev);
kfree(btv->remote);
btv->remote = NULL;
}
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index ffbbeca8a8e5f..554767b8ef2bf 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -402,6 +402,7 @@ void cx23885_input_fini(struct cx23885_dev *dev)
if (dev->kernel_ir == NULL)
return;
rc_unregister_device(dev->kernel_ir->rc);
+ rc_free_device(dev->kernel_ir->rc);
kfree(dev->kernel_ir->phys);
kfree(dev->kernel_ir->name);
kfree(dev->kernel_ir);
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index e958eecb29c5c..5d9ce4f9af011 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -509,8 +509,9 @@ int cx88_ir_fini(struct cx88_core *core)
if (!ir)
return 0;
- cx88_ir_stop(core);
rc_unregister_device(ir->dev);
+ cx88_ir_stop(core);
+ rc_free_device(ir->dev);
kfree(ir);
/* done */
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index de05d8b0f9dc5..bbd24769ae56b 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -763,6 +763,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
static void dm1105_ir_exit(struct dm1105_dev *dm1105)
{
rc_unregister_device(dm1105->ir.dev);
+ rc_free_device(dm1105->ir.dev);
}
static int dm1105_hw_init(struct dm1105_dev *dev)
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 34c0d979240fd..edb4cacf55d22 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -72,5 +72,6 @@ EXPORT_SYMBOL_GPL(mantis_input_init);
void mantis_input_exit(struct mantis_pci *mantis)
{
rc_unregister_device(mantis->rc);
+ rc_free_device(mantis->rc);
}
EXPORT_SYMBOL_GPL(mantis_input_exit);
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 5b71014157808..7f6680de31564 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -834,6 +834,7 @@ void saa7134_input_fini(struct saa7134_dev *dev)
return;
rc_unregister_device(dev->remote->dev);
+ rc_free_device(dev->remote->dev);
kfree(dev->remote);
dev->remote = NULL;
}
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index c0604d9c70119..0bbe4fa2d5a84 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -181,5 +181,6 @@ void smi_ir_exit(struct smi_dev *dev)
rc_unregister_device(rc_dev);
smi_ir_stop(ir);
+ rc_free_device(rc_dev);
ir->rc_dev = NULL;
}
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 3709c0fb23b07..8b496b959d7ea 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -249,6 +249,7 @@ static void msp430_ir_deinit(struct budget_ci *budget_ci)
cancel_work_sync(&budget_ci->ir.msp430_irq_bh_work);
rc_unregister_device(budget_ci->ir.dev);
+ rc_free_device(budget_ci->ir.dev);
}
static int ciintf_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 78abe810a88e7..51d85de24fae3 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -921,7 +921,6 @@ static int ati_remote_probe(struct usb_interface *interface,
input_free_device(input_dev);
exit_unregister_device:
rc_unregister_device(rc_dev);
- rc_dev = NULL;
exit_kill_urbs:
usb_kill_urb(ati_remote->irq_urb);
usb_kill_urb(ati_remote->out_urb);
@@ -941,18 +940,19 @@ static void ati_remote_disconnect(struct usb_interface *interface)
struct ati_remote *ati_remote;
ati_remote = usb_get_intfdata(interface);
- usb_set_intfdata(interface, NULL);
if (!ati_remote) {
dev_warn(&interface->dev, "%s - null device?\n", __func__);
return;
}
+ rc_unregister_device(ati_remote->rdev);
+ usb_set_intfdata(interface, NULL);
usb_kill_urb(ati_remote->irq_urb);
usb_kill_urb(ati_remote->out_urb);
if (ati_remote->idev)
input_unregister_device(ati_remote->idev);
- rc_unregister_device(ati_remote->rdev);
ati_remote_free_buffers(ati_remote);
+ rc_free_device(ati_remote->rdev);
kfree(ati_remote);
}
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index f8120605501ab..6f7dccc965e7f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1090,7 +1090,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
release_region(dev->hw_io, ENE_IO_SIZE);
exit_unregister_device:
rc_unregister_device(rdev);
- rdev = NULL;
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(dev);
@@ -1110,6 +1109,7 @@ static void ene_remove(struct pnp_dev *pnp_dev)
ene_rx_restore_hw_buffer(dev);
spin_unlock_irqrestore(&dev->hw_lock, flags);
+ rc_free_device(dev->rdev);
free_irq(dev->irq, dev);
release_region(dev->hw_io, ENE_IO_SIZE);
kfree(dev);
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index f7cfa8a073ebc..5055dfc3f4651 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -568,6 +568,7 @@ static void fintek_remove(struct pnp_dev *pdev)
struct fintek_dev *fintek = pnp_get_drvdata(pdev);
unsigned long flags;
+ rc_unregister_device(fintek->rdev);
spin_lock_irqsave(&fintek->fintek_lock, flags);
/* disable CIR */
fintek_disable_cir(fintek);
@@ -580,7 +581,7 @@ static void fintek_remove(struct pnp_dev *pdev)
free_irq(fintek->cir_irq, fintek);
release_region(fintek->cir_addr, fintek->cir_port_len);
- rc_unregister_device(fintek->rdev);
+ rc_free_device(fintek->rdev);
kfree(fintek);
}
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e034c93d57cf0..5ceb5ca44e235 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -242,6 +242,7 @@ static void igorplugusb_disconnect(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
usb_unpoison_urb(ir->urb);
usb_free_urb(ir->urb);
+ rc_free_device(ir->rc);
kfree(ir->buf_in);
}
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index c508f2536243e..0c5b8befb0af3 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -500,6 +500,7 @@ static void iguanair_disconnect(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
usb_kill_urb(ir->urb_in);
usb_kill_urb(ir->urb_out);
+ rc_free_device(ir->rc);
usb_free_urb(ir->urb_in);
usb_free_urb(ir->urb_out);
usb_free_coherent(ir->udev, MAX_IN_PACKET, ir->buf_in, ir->dma_in);
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 63f6f5b36838d..f30adf4d8444d 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1118,9 +1118,10 @@ void img_ir_remove_hw(struct img_ir_priv *priv)
struct rc_dev *rdev = hw->rdev;
if (!rdev)
return;
+ rc_unregister_device(rdev);
img_ir_set_decoder(priv, NULL, 0);
hw->rdev = NULL;
- rc_unregister_device(rdev);
+ rc_free_device(rdev);
#ifdef CONFIG_COMMON_CLK
if (!IS_ERR(priv->clk))
clk_notifier_unregister(priv->clk, &hw->clk_nb);
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 92fb7b555a0f6..f1460d4acf3e8 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -136,6 +136,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
if (!rdev)
return;
+ rc_unregister_device(rdev);
/* switch off and disable raw (edge) interrupts */
spin_lock_irq(&priv->lock);
raw->rdev = NULL;
@@ -145,7 +146,7 @@ void img_ir_remove_raw(struct img_ir_priv *priv)
img_ir_write(priv, IMG_IR_IRQ_CLEAR, IMG_IR_IRQ_EDGE);
spin_unlock_irq(&priv->lock);
- rc_unregister_device(rdev);
+ rc_free_device(rdev);
timer_delete_sync(&raw->timer);
}
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 7e92161105d53..310c9fc9ae91c 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2541,9 +2541,10 @@ static void imon_disconnect(struct usb_interface *interface)
if (ifnum == 0) {
ictx->dev_present_intf0 = false;
+ rc_unregister_device(ictx->rdev);
usb_kill_urb(ictx->rx_urb_intf0);
input_unregister_device(ictx->idev);
- rc_unregister_device(ictx->rdev);
+ rc_free_device(ictx->rdev);
if (ictx->display_supported) {
if (ictx->display_type == IMON_DISPLAY_TYPE_LCD)
usb_deregister_dev(interface, &imon_lcd_class);
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index edc46828509c8..1b061e4a3dcfa 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -331,7 +331,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
regerr:
rc_unregister_device(rdev);
- rdev = NULL;
clkerr:
clk_disable_unprepare(priv->clock);
err:
@@ -346,6 +345,7 @@ static void hix5hd2_ir_remove(struct platform_device *pdev)
clk_disable_unprepare(priv->clock);
rc_unregister_device(priv->rdev);
+ rc_free_device(priv->rdev);
}
#ifdef CONFIG_PM_SLEEP
diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c
index d6472de5da87d..089833e411786 100644
--- a/drivers/media/rc/ir_toy.c
+++ b/drivers/media/rc/ir_toy.c
@@ -536,6 +536,7 @@ static void irtoy_disconnect(struct usb_interface *intf)
usb_free_urb(ir->urb_out);
usb_kill_urb(ir->urb_in);
usb_free_urb(ir->urb_in);
+ rc_free_device(ir->rc);
kfree(ir->in);
kfree(ir->out);
kfree(ir);
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index bf544517c67a9..bde2a70512310 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1414,7 +1414,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
release_region(itdev->cir_addr, itdev->params->io_region_size);
exit_unregister_device:
rc_unregister_device(rdev);
- rdev = NULL;
exit_free_dev_rdev:
rc_free_device(rdev);
kfree(itdev);
@@ -1439,6 +1438,7 @@ static void ite_remove(struct pnp_dev *pdev)
release_region(dev->cir_addr, dev->params->io_region_size);
rc_unregister_device(dev->rdev);
+ rc_free_device(dev->rdev);
kfree(dev);
}
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ed55e9ec3c570..06222eee17540 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1850,6 +1850,7 @@ static void mceusb_dev_disconnect(struct usb_interface *intf)
usb_free_urb(ir->urb_in);
usb_free_coherent(dev, ir->len_in, ir->buf_in, ir->dma_in);
usb_put_dev(dev);
+ rc_free_device(ir->rc);
kfree(ir);
}
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 2e269ef5e26be..ba24c2f22d39f 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -648,9 +648,6 @@ int ir_raw_event_register(struct rc_dev *dev)
void ir_raw_event_free(struct rc_dev *dev)
{
- if (!dev)
- return;
-
kfree(dev->raw);
dev->raw = NULL;
}
@@ -674,8 +671,6 @@ void ir_raw_event_unregister(struct rc_dev *dev)
lirc_bpf_free(dev);
- ir_raw_event_free(dev);
-
/*
* A user can be calling bpf(BPF_PROG_{QUERY|ATTACH|DETACH}), so
* ensure that the raw member is null on unlock; this is how
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 78ac09b3cbd34..53d0540717b36 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -263,6 +263,7 @@ static int __init loop_init(void)
static void __exit loop_exit(void)
{
rc_unregister_device(loopdev.dev);
+ rc_free_device(loopdev.dev);
}
module_init(loop_init);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 821607504008a..dda3479ea3add 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1611,6 +1611,7 @@ static void rc_dev_release(struct device *device)
{
struct rc_dev *dev = to_rc_dev(device);
+ ir_raw_event_free(dev);
kfree(dev);
}
@@ -1773,7 +1774,6 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
}
rc->dev.parent = dev;
- rc->managed_alloc = true;
*dr = rc;
devres_add(dev, dr);
@@ -2042,11 +2042,7 @@ void rc_unregister_device(struct rc_dev *dev)
device_del(&dev->dev);
ida_free(&rc_ida, dev->minor);
-
- if (!dev->managed_alloc)
- rc_free_device(dev);
}
-
EXPORT_SYMBOL_GPL(rc_unregister_device);
/*
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b917a2a89188..3f828a564e192 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -1131,11 +1131,13 @@ static void redrat3_dev_disconnect(struct usb_interface *intf)
{
struct usb_device *udev = interface_to_usbdev(intf);
struct redrat3_dev *rr3 = usb_get_intfdata(intf);
+ struct rc_dev *rc = rr3->rc;
usb_set_intfdata(intf, NULL);
- rc_unregister_device(rr3->rc);
+ rc_unregister_device(rc);
led_classdev_unregister(&rr3->led);
redrat3_delete(rr3, udev);
+ rc_free_device(rc);
}
static int redrat3_dev_suspend(struct usb_interface *intf, pm_message_t message)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 6b70bac5f45d6..0ba06bfc9e14b 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -203,6 +203,7 @@ static void st_rc_remove(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, false);
clk_disable_unprepare(rc_dev->sys_clock);
rc_unregister_device(rc_dev->rdev);
+ rc_free_device(rc_dev->rdev);
}
static int st_rc_open(struct rc_dev *rdev)
@@ -334,7 +335,6 @@ static int st_rc_probe(struct platform_device *pdev)
return ret;
rcerr:
rc_unregister_device(rdev);
- rdev = NULL;
clkerr:
clk_disable_unprepare(rc_dev->sys_clock);
err:
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 5a18603f9a95c..7103da57c19f1 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -388,15 +388,16 @@ static void streamzap_disconnect(struct usb_interface *interface)
struct streamzap_ir *sz = usb_get_intfdata(interface);
struct usb_device *usbdev = interface_to_usbdev(interface);
- usb_set_intfdata(interface, NULL);
-
if (!sz)
return;
- usb_kill_urb(sz->urb_in);
rc_unregister_device(sz->rdev);
+ usb_set_intfdata(interface, NULL);
+
+ usb_kill_urb(sz->urb_in);
usb_free_urb(sz->urb_in);
usb_free_coherent(usbdev, sz->buf_in_len, sz->buf_in, sz->dma_in);
+ rc_free_device(sz->rdev);
kfree(sz);
}
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 92ef4e7c6f69f..cb4c56bf0752a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -371,6 +371,7 @@ static void sunxi_ir_remove(struct platform_device *pdev)
struct sunxi_ir *ir = platform_get_drvdata(pdev);
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
sunxi_ir_hw_exit(&pdev->dev);
}
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index 110a469001146..a2a64a860264b 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -333,7 +333,6 @@ static int ttusbir_probe(struct usb_interface *intf,
return 0;
out3:
rc_unregister_device(rc);
- rc = NULL;
out2:
led_classdev_unregister(&tt->led);
out:
@@ -373,6 +372,7 @@ static void ttusbir_disconnect(struct usb_interface *intf)
}
usb_kill_urb(tt->bulk_urb);
usb_free_urb(tt->bulk_urb);
+ rc_free_device(tt->rc);
usb_set_intfdata(intf, NULL);
kfree(tt);
}
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 515469dd82d4c..8e804661a6215 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1132,7 +1132,6 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
release_region(data->wbase, WAKEUP_IOMEM_LEN);
exit_unregister_device:
rc_unregister_device(data->dev);
- data->dev = NULL;
exit_free_rc:
rc_free_device(data->dev);
exit_unregister_led:
@@ -1163,6 +1162,7 @@ wbcir_remove(struct pnp_dev *device)
wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
rc_unregister_device(data->dev);
+ rc_free_device(data->dev);
led_classdev_unregister(&data->led);
diff --git a/drivers/media/rc/xbox_remote.c b/drivers/media/rc/xbox_remote.c
index 3e3da70cf8da0..c64123e9d16a5 100644
--- a/drivers/media/rc/xbox_remote.c
+++ b/drivers/media/rc/xbox_remote.c
@@ -277,14 +277,15 @@ static void xbox_remote_disconnect(struct usb_interface *interface)
struct xbox_remote *xbox_remote;
xbox_remote = usb_get_intfdata(interface);
- usb_set_intfdata(interface, NULL);
if (!xbox_remote) {
dev_warn(&interface->dev, "%s - null device?\n", __func__);
return;
}
- usb_kill_urb(xbox_remote->irq_urb);
rc_unregister_device(xbox_remote->rdev);
+ usb_set_intfdata(interface, NULL);
+ usb_kill_urb(xbox_remote->irq_urb);
+ rc_free_device(xbox_remote->rdev);
usb_free_urb(xbox_remote->irq_urb);
kfree(xbox_remote);
}
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 7dec1a360da6a..81d0165a3064d 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -357,6 +357,7 @@ void au0828_rc_unregister(struct au0828_dev *dev)
return;
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
/* done */
kfree(ir);
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index 600cff8a4abdc..bd86d250433df 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -187,6 +187,7 @@ static int dvb_usbv2_remote_exit(struct dvb_usb_device *d)
if (d->rc_dev) {
cancel_delayed_work_sync(&d->rc_query_work);
rc_unregister_device(d->rc_dev);
+ rc_free_device(d->rc_dev);
d->rc_dev = NULL;
}
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index 65e2c9e2cdc99..6dc11718dfb98 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -347,10 +347,12 @@ int dvb_usb_remote_exit(struct dvb_usb_device *d)
{
if (d->state & DVB_USB_STATE_REMOTE) {
cancel_delayed_work_sync(&d->rc_query_work);
- if (d->props.rc.mode == DVB_RC_LEGACY)
+ if (d->props.rc.mode == DVB_RC_LEGACY) {
input_unregister_device(d->input_dev);
- else
+ } else {
rc_unregister_device(d->rc_dev);
+ rc_free_device(d->rc_dev);
+ }
}
d->state &= ~DVB_USB_STATE_REMOTE;
return 0;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 20fdd59b55185..ab61d9a29b10e 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -853,6 +853,7 @@ static int em28xx_ir_fini(struct em28xx *dev)
goto ref_put;
rc_unregister_device(ir->rc);
+ rc_free_device(ir->rc);
kfree(ir->i2c_client);
diff --git a/drivers/staging/media/av7110/av7110_ir.c b/drivers/staging/media/av7110/av7110_ir.c
index 68b3979ba5f20..fdae467fd7ab8 100644
--- a/drivers/staging/media/av7110/av7110_ir.c
+++ b/drivers/staging/media/av7110/av7110_ir.c
@@ -151,6 +151,7 @@ int av7110_ir_init(struct av7110 *av7110)
void av7110_ir_exit(struct av7110 *av7110)
{
rc_unregister_device(av7110->ir.rcdev);
+ rc_free_device(av7110->ir.rcdev);
}
//MODULE_AUTHOR("Holger Waechtler <holger@convergence.de>, Oliver Endriss <o.endriss@gmx.de>");
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 35c7a0546f02e..7c964b5ad7926 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -81,7 +81,6 @@ struct lirc_fh {
/**
* struct rc_dev - represents a remote control device
* @dev: driver model's view of this device
- * @managed_alloc: devm_rc_allocate_device was used to create rc_dev
* @registered: set to true by rc_register_device(), false by
* rc_unregister_device
* @idle: used to keep track of RX state
@@ -156,7 +155,6 @@ struct lirc_fh {
*/
struct rc_dev {
struct device dev;
- bool managed_alloc;
bool registered;
bool idle;
bool encode_wakeup;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] wifi: mt76: mt792x: Fix a potential deadlock in high-load situations
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Leon Yen, Chia-Lin Kao (AceLan), Felix Fietkau, Sasha Levin,
lorenzo, ryder.lee, kvalo, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Leon Yen <leon.yen@mediatek.com>
[ Upstream commit bb2f07819d063a58756186cac6465341956ac0a4 ]
A deadlock may occur between two works, ps_work and mac_work, if their work
functions run simultaneously as they attempt to cancel each other by
calling cancel_delayed_work_sync().
mt792x_mac_work() -> ... -> cancel_delayed_work_sync(&pm->ps_work);
mt792x_pm_power_save_work() -> cancel_delayed_work_sync(&mphy->mac_work);
In high-load situations, they are queued but may not have chance to be
executed until the CPUs are released. Once the CPUs are available, there
is a high possibility that the ps_work function and mac_work function will
be executed simultaneously, resulting in a possible deadlock.
This patch replaces cancel_delayed_work_sync() with cancel_delayed_work()
in ps_work to eliminate the deadlock and make the code easier to maintain.
Signed-off-by: Leon Yen <leon.yen@mediatek.com>
Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://patch.msgid.link/20251215122231.3180648-1-leon.yen@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the data needed. Let me compile the full analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `wifi: mt76: mt792x`
- Action verb: "Fix"
- Summary: Fixes a potential deadlock between ps_work and mac_work in
high-load situations.
Record: [wifi/mt76/mt792x] [Fix] [Deadlock between two work functions
that cancel each other with _sync variant]
**Step 1.2: Tags**
- `Signed-off-by: Leon Yen <leon.yen@mediatek.com>` — Author from
MediaTek (the chip vendor)
- `Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>` — Tested
by a Canonical engineer
- `Link: https://patch.msgid.link/20251215122231.3180648-1-
leon.yen@mediatek.com`
- `Signed-off-by: Felix Fietkau <nbd@nbd.name>` — mt76 subsystem
maintainer accepted the patch
Record: Author is from MediaTek (chip vendor). Tested by Canonical
(Ubuntu). Accepted by mt76 maintainer Felix Fietkau. No Fixes: tag, no
Reported-by (expected since this is a code-analysis-based fix).
**Step 1.3: Commit Body**
The message describes:
- **Bug**: A deadlock between two delayed works: `ps_work` and
`mac_work`
- **Mechanism**: Both try to cancel each other using
`cancel_delayed_work_sync()`, which blocks until the target work
finishes
- **Trigger**: High-load situations where both works get queued and
execute simultaneously on different CPUs
- **Fix**: Replace `cancel_delayed_work_sync()` with
`cancel_delayed_work()` in ps_work
Record: Classic ABBA deadlock. Failure mode is system hang (deadlock).
Triggered under high CPU load with WiFi active.
**Step 1.4: Hidden Bug Fix?**
No — this is explicitly labeled "Fix" and clearly describes a deadlock.
Not hidden.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- 1 file changed: `drivers/net/wireless/mediatek/mt76/mt792x_mac.c`
- 1 line changed: `-cancel_delayed_work_sync(` → `+cancel_delayed_work(`
- Function modified: `mt792x_pm_power_save_work()`
- Scope: Single-file, single-line, surgical fix
**Step 2.2: Code Flow Change**
Before: `mt792x_pm_power_save_work()` calls
`cancel_delayed_work_sync(&mphy->mac_work)`, which blocks until any
currently-running `mac_work` completes.
After: It calls `cancel_delayed_work(&mphy->mac_work)`, which cancels a
pending work but does NOT wait for a running instance to finish.
**Step 2.3: Bug Mechanism — Deadlock**
The deadlock is an ABBA pattern between two work functions:
**Chain A** (mac_work → waits for ps_work):
```
mt792x_mac_work()
→ mt792x_mutex_acquire()
→ mt76_connac_mutex_acquire()
→ mt76_connac_pm_wake()
→ cancel_delayed_work_sync(&pm->ps_work) ← WAITS for ps_work
```
**Chain B** (ps_work → waits for mac_work):
```
mt792x_pm_power_save_work()
→ cancel_delayed_work_sync(&mphy->mac_work) ← WAITS for mac_work
```
If both execute simultaneously:
- CPU1's mac_work waits for ps_work to finish
- CPU2's ps_work waits for mac_work to finish
- **Classic ABBA deadlock → system hang**
The two works run on *different* workqueues (`mac_work` on ieee80211's
workqueue, `ps_work` on `dev->mt76.wq`), which confirms they CAN execute
in parallel on different CPUs.
**Step 2.4: Fix Quality**
- Obviously correct: removing `_sync` breaks the circular dependency
- The non-sync variant is safe here because after the cancel, `ps_work`
immediately returns. If `mac_work` is running, it will re-queue itself
(line 30-31) and will be properly managed in the next power-save
cycle. `mac_work` acquires `mt792x_mutex_acquire` which wakes the
device if needed.
- Minimal/surgical: exactly 1 function call changed
- Regression risk: Very low — the only difference is not waiting for a
running `mac_work` to finish, which is acceptable since `ps_work`
doesn't depend on `mac_work` completion
## PHASE 3: GIT HISTORY
**Step 3.1: Blame**
The buggy line was introduced by commit `c21a7f9f406bba` (Lorenzo
Bianconi, 2023-06-28), "wifi: mt76: mt7921: move shared runtime-pm code
on mt792x-lib". This was code movement that created the mt792x_mac.c
file, carrying the original deadlock-prone pattern from mt7921/mac.c.
**Step 3.2: Fixes tag** — No Fixes: tag present (expected).
**Step 3.3: Related changes** — The file has had several changes since,
but none addressing this specific deadlock.
**Step 3.4: Author** — Leon Yen is a MediaTek engineer with multiple
mt76 contributions, including WiFi/BT combo fixes and power management
work.
**Step 3.5: Dependencies** — None. This is a standalone one-line fix.
## PHASE 4: MAILING LIST RESEARCH
b4 dig did not find the exact commit (it matched a different file
change). The lore.kernel.org search was blocked. However, the commit
message Link tag points to the original submission:
`20251215122231.3180648-1-leon.yen@mediatek.com`. The patch was accepted
by Felix Fietkau (mt76 maintainer) and tested by a Canonical engineer.
Record: Maintainer-accepted, independently tested. Standalone patch (not
a series).
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**: `mt792x_pm_power_save_work()`
**Step 5.2: Callers**: This function is the work handler for
`pm.ps_work`, queued on `dev->mt76.wq` (an ordered workqueue) via
`mt76_connac_power_save_sched()`. It is called indirectly when the
device transitions to power-save mode.
**Step 5.3-5.4: Call chain**: The power-save work is scheduled via
`mt76_connac_mutex_release()` → `mt76_connac_power_save_sched()`, which
is called after every device register access. This is a very hot path
for any mt792x WiFi operation.
**Step 5.5: Similar patterns**: The `mt7615` driver has similar power-
save code at `drivers/net/wireless/mediatek/mt76/mt7615/mac.c`, but this
specific fix only addresses the mt792x code path.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1**: The buggy code was introduced in commit `c21a7f9f406bba`
(June 2023), which is present in v6.6 but NOT in v6.1. Affected stable
trees: v6.6.y, v6.12.y, and any later LTS.
**Step 6.2**: The fix is a one-line change. It should apply cleanly to
any tree containing the buggy code.
**Step 6.3**: No related fixes for this specific deadlock already in
stable.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1**: `drivers/net/wireless/mediatek/mt76` — WiFi driver for
MediaTek MT7921/MT7922/MT7925 chipsets. These are extremely popular WiFi
chips found in many modern laptops (Framework, Lenovo ThinkPad, Dell,
etc.). Criticality: **IMPORTANT** — affects many real users.
**Step 7.2**: The mt76 subsystem is very active with regular
contributions.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1**: Affects all users with MT7921/MT7922/MT7925 WiFi chipsets
(very large population, especially Ubuntu/Fedora laptop users).
**Step 8.2**: Trigger is high CPU load with active WiFi. Both works must
execute simultaneously. Under heavy load this is realistic — the commit
specifically says "In high-load situations, they are queued but may not
have chance to be executed until the CPUs are released."
**Step 8.3**: **Failure mode: DEADLOCK → system hang**. Severity:
**CRITICAL** — the system becomes unresponsive.
**Step 8.4**:
- Benefit: VERY HIGH — prevents deadlock/hang on popular hardware
- Risk: VERY LOW — 1-line change, removing a sync variant that was
causing the deadlock
- Ratio: Extremely favorable
## PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Fixes a real deadlock (ABBA pattern) verified through code analysis
- 1-line fix, obviously correct, minimal regression risk
- Affects widely-used WiFi hardware (MT7921/MT7922/MT7925)
- Tested by Canonical engineer (Ubuntu LTS relevance)
- Accepted by subsystem maintainer
- Buggy code exists in stable trees v6.6+
- Failure mode is system hang (CRITICAL)
- Author is from MediaTek (chip vendor, deep domain expertise)
**Evidence AGAINST backporting:**
- None significant
**Stable rules checklist:**
1. Obviously correct and tested? **YES** — 1-line change, independently
tested
2. Fixes a real bug? **YES** — deadlock under high load
3. Important issue? **YES** — system deadlock/hang (CRITICAL)
4. Small and contained? **YES** — 1 line in 1 file
5. No new features? **YES** — pure bug fix
6. Applies to stable? **YES** — clean apply expected for v6.6+
## Verification
- [Phase 1] Parsed tags: Tested-by from Canonical, maintainer SOB from
Felix Fietkau
- [Phase 2] Diff analysis: 1-line change in
`mt792x_pm_power_save_work()`, `cancel_delayed_work_sync` →
`cancel_delayed_work`
- [Phase 3] git blame: buggy code from commit c21a7f9f406bba (June
2023), code refactoring that moved runtime-PM code to mt792x-lib
- [Phase 3] `git merge-base --is-ancestor`: confirmed code is in v6.6
but NOT in v6.1
- [Phase 5] Traced deadlock chain: mac_work→mt792x_mutex_acquire→mt76_co
nnac_pm_wake→cancel_delayed_work_sync(&ps_work) vs
ps_work→cancel_delayed_work_sync(&mac_work)
- [Phase 5] Verified `dev->mt76.wq` is `alloc_ordered_workqueue`
(mac80211.c line 733) and mac_work uses ieee80211's workqueue
(different queues → parallel execution possible)
- [Phase 5] Verified `mt76_connac_power_save_sched` at line 62-83 of
mt76_connac_mac.c schedules ps_work, confirming the scheduling path
- [Phase 6] Confirmed fix applies to v6.6+ stable trees
- [Phase 7] mt76 is a widely used WiFi driver subsystem
- [Phase 8] Failure mode: system deadlock/hang, severity CRITICAL
**YES**
drivers/net/wireless/mediatek/mt76/mt792x_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_mac.c b/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
index 71dec93094ebd..888e5a5056731 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_mac.c
@@ -375,7 +375,7 @@ void mt792x_pm_power_save_work(struct work_struct *work)
}
if (!mt792x_mcu_fw_pmctrl(dev)) {
- cancel_delayed_work_sync(&mphy->mac_work);
+ cancel_delayed_work(&mphy->mac_work);
return;
}
out:
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.1] memory: brcmstb_memc: Expand LPDDR4 check to cover for LPDDR5
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Florian Fainelli, Krzysztof Kozlowski, Sasha Levin, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Florian Fainelli <florian.fainelli@broadcom.com>
[ Upstream commit a969a0835152984a0f556434eafdee0b84213670 ]
The same limitations that apply to LPDDR4 also apply to LPDDR5. Expand
the check and rename accordingly.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260122003501.1191059-1-florian.fainelli@broadcom.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to complete the full analysis. Let me
compile my findings.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: `memory: brcmstb_memc:` (Broadcom STB memory controller
driver)
- **Action verb**: "Expand" (extending an existing check)
- **Summary**: Expand LPDDR4 check to also cover LPDDR5 memory types
Record: [memory/brcmstb_memc] [expand] [Extend existing LPDDR4 hardware
limitation check to also apply to LPDDR5]
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Florian Fainelli <florian.fainelli@broadcom.com>
(author, Broadcom employee, original driver author)
- **Link**: https://patch.msgid.link/20260122003501.1191059-1-
florian.fainelli@broadcom.com
- **Signed-off-by**: Krzysztof Kozlowski <krzk@kernel.org> (subsystem
maintainer who applied it)
- No Fixes: tag, no Cc: stable, no Reported-by, no Tested-by, no
Reviewed-by
Record: Author is the original driver author (Florian Fainelli at
Broadcom). Applied by memory subsystem maintainer Krzysztof Kozlowski.
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The message says: "The same limitations that apply to LPDDR4 also apply
to LPDDR5. Expand the check and rename accordingly."
The limitation in question: On LPDDR4 chips, the inactivity timeout for
Self-Refresh Power Down (SRPD) cannot be changed because the dynamic
tuning process is affected by the inactivity timeout, making it non-
functional. This same limitation applies to LPDDR5.
Without this fix, on LPDDR5 hardware, a user writing to the `srpd` sysfs
attribute would successfully change the SRPD inactivity timeout, which
would break the dynamic tuning process, making the memory controller
non-functional.
Record: [Bug: missing LPDDR5 check allows dangerous SRPD timeout
modification on LPDDR5 hardware] [Symptom: dynamic memory tuning becomes
non-functional on LPDDR5 systems] [Root cause: original code only
checked for LPDDR4, not LPDDR5]
### Step 1.4: DETECT HIDDEN BUG FIXES
This IS a real bug fix disguised as "expand." The keyword "expand" masks
the fact that without this change, LPDDR5 users can corrupt their memory
controller tuning through the sysfs interface.
Record: [Yes, this is a hidden bug fix. It prevents a user from making
the dynamic tuning process non-functional on LPDDR5 hardware.]
---
## PHASE 2: DIFF ANALYSIS - LINE BY LINE
### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/memory/brcmstb_memc.c`
- **Lines added**: ~4 (new define, extra condition, rename)
- **Lines removed**: ~3 (old function name, old single condition)
- **Functions modified**: `brcmstb_memc_uses_lpddr4` renamed to
`brcmstb_memc_uses_lpddr45`, `srpd_store` (caller updated)
- **Scope**: Single-file, surgical fix
Record: [1 file changed, ~4 lines added, ~3 removed] [Functions:
brcmstb_memc_uses_lpddr4→brcmstb_memc_uses_lpddr45, srpd_store] [Single-
file surgical fix]
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1** - Define addition:
- Before: Only `CNTRLR_CONFIG_LPDDR4_SHIFT` (value 5) defined
- After: Also defines `CNTRLR_CONFIG_LPDDR5_SHIFT` (value 6)
**Hunk 2** - Function logic change:
- Before: `brcmstb_memc_uses_lpddr4()` returns true only if register
value == 5 (LPDDR4)
- After: `brcmstb_memc_uses_lpddr45()` returns true if register value ==
5 (LPDDR4) OR == 6 (LPDDR5)
**Hunk 3** - Caller update:
- Before: `srpd_store()` calls `brcmstb_memc_uses_lpddr4()`
- After: `srpd_store()` calls `brcmstb_memc_uses_lpddr45()`
The change affects the `srpd_store` sysfs path. When a user writes to
`/sys/.../srpd`, the check now correctly blocks the write for both
LPDDR4 and LPDDR5.
Record: [Before: LPDDR5 memory allowed dangerous SRPD timeout change.
After: LPDDR5 correctly blocked like LPDDR4.]
### Step 2.3: IDENTIFY THE BUG MECHANISM
This is a **hardware workaround/limitation enforcement** fix. Category
(h) - Hardware workarounds. The hardware has a limitation (LPDDR5
dynamic tuning breaks with SRPD timeout changes) that wasn't enforced in
software.
Record: [Hardware workaround - extending existing HW limitation check to
cover LPDDR5]
### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: Yes. The author is the Broadcom engineer who wrote
the driver and knows the hardware limitations.
- Minimal/surgical: Yes. Adds one define, one condition, renames a
function.
- Regression risk: Extremely low. The only change is that LPDDR5 systems
now return `-EOPNOTSUPP` from `srpd_store`, which is the correct
behavior. LPDDR4 and other memory types are unaffected.
Record: [Fix is obviously correct, minimal, and low regression risk]
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
From git blame, all the relevant code was introduced by Florian Fainelli
in commit `a4be90ff7a7d2` ("memory: brcmstb_memc: Add Broadcom STB
memory controller driver"), first appearing in v6.1-rc1. The buggy code
(missing LPDDR5 check) has been present since the driver was introduced.
Record: [Buggy code introduced in a4be90ff7a7d2, merged in v6.1-rc1.
Present in all stable trees from 6.1 onward.]
### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. This is expected.
### Step 3.3: CHECK FILE HISTORY
The file has had minimal changes: initial addition in v6.1, then a few
minor cleanups and build fixes. No major refactoring. The patch should
apply cleanly or with trivial adjustments to stable trees.
Record: [File has minimal history - 6 commits total. No conflicting
changes.]
### Step 3.4: CHECK THE AUTHOR
Florian Fainelli is the original author of this driver and a Broadcom
employee who is the de facto maintainer. His fix carries maximum
authority for this driver.
Record: [Author is the original driver author and de facto maintainer at
Broadcom]
### Step 3.5: CHECK FOR DEPENDENCIES
This is a standalone single-commit fix. No dependencies on other
commits.
Record: [Standalone fix, no dependencies]
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
b4 dig failed to find the commit by message-id (the commit may not be in
the local repo since we're on 7.0 and the commit isn't present in HEAD
yet). Lore is behind a challenge page. The Link tag points to `patch.msg
id.link/20260122003501.1191059-1-florian.fainelli@broadcom.com`.
Record: [Could not access lore discussion due to anti-bot protection.
The patch was accepted by maintainer Krzysztof Kozlowski.]
### Step 4.2-4.5: MAILING LIST RESEARCH
Unable to verify via lore due to access restrictions. However, the patch
was accepted by the memory subsystem maintainer with no modifications.
Record: [UNVERIFIED: Could not access mailing list discussion. Accepted
by maintainer.]
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: KEY FUNCTIONS
- `brcmstb_memc_uses_lpddr4` (renamed to `brcmstb_memc_uses_lpddr45`)
- `srpd_store` (caller)
### Step 5.2: TRACE CALLERS
`brcmstb_memc_uses_lpddr4` is called only from `srpd_store`, which is
the sysfs write handler for the `srpd` attribute. This is user-
accessible.
Record: [Called from srpd_store sysfs handler - user-triggered path]
### Step 5.3-5.4: CALL CHAIN
User writes to `/sys/devices/.../srpd` → `srpd_store()` →
`brcmstb_memc_uses_lpddr45()` reads hardware register → if LPDDR4/5,
returns -EOPNOTSUPP.
Record: [User-triggered via sysfs write. Direct path.]
### Step 5.5: SIMILAR PATTERNS
No similar patterns elsewhere - this is the only LPDDR type check in
this driver.
Record: [Unique check in this driver]
---
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The driver was introduced in v6.1-rc1 (commit `a4be90ff7a7d2`). It
exists in:
- 6.1.y (LTS) ✓
- 6.6.y (LTS) ✓
- 6.12.y ✓
- 7.0 ✓
Record: [Buggy code exists in all active stable trees: 6.1.y, 6.6.y,
6.12.y]
### Step 6.2: BACKPORT COMPLICATIONS
The file has had only minor changes across versions. The patch should
apply cleanly or with trivial context adjustments.
Record: [Expected clean apply across all stable trees]
### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fixes for LPDDR5 exist.
Record: [No prior fix for this issue in stable]
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: IDENTIFY SUBSYSTEM CRITICALITY
- **Subsystem**: drivers/memory - memory controller drivers
- **Criticality**: PERIPHERAL (specific Broadcom STB hardware) but the
consequences of the bug (making dynamic tuning non-functional) are
significant for affected users.
Record: [drivers/memory, PERIPHERAL - Broadcom STB specific, but real
hardware impact]
### Step 7.2: SUBSYSTEM ACTIVITY
Only 6 commits to this file over its entire existence (since 6.1).
Mature and stable code.
Record: [Mature, stable codebase with minimal changes]
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
Users of Broadcom STB SoCs with LPDDR5 memory. This is primarily
embedded/set-top-box devices.
Record: [Driver-specific: Broadcom STB users with LPDDR5 memory]
### Step 8.2: TRIGGER CONDITIONS
Triggered when a user (or system script) writes to the `srpd` sysfs
attribute on a system with LPDDR5 memory. On affected systems, the write
succeeds (should fail with -EOPNOTSUPP) and the SRPD configuration
change breaks the dynamic tuning process.
Record: [Triggered by sysfs write on LPDDR5 systems. Could be triggered
by power management scripts.]
### Step 8.3: FAILURE MODE SEVERITY
When triggered, the dynamic tuning process becomes "non-functional" (per
the existing code comment). This affects the memory controller's dynamic
tuning, which could lead to system instability or incorrect memory
timing. Severity: **MEDIUM-HIGH** for affected hardware.
Record: [Memory controller dynamic tuning becomes non-functional.
Severity: MEDIUM-HIGH]
### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: Prevents memory controller misconfiguration on LPDDR5
Broadcom STB systems. Real hardware fix for real users.
- **RISK**: Extremely low. Only adds one additional condition to an
existing check. The only behavioral change is that LPDDR5 systems now
correctly return -EOPNOTSUPP on SRPD write, matching the existing
LPDDR4 behavior.
- **Ratio**: Very favorable. Minimal risk, meaningful benefit for
affected hardware.
Record: [High benefit for affected users, minimal risk. Very favorable
ratio.]
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: COMPILE THE EVIDENCE
**FOR backporting:**
- Fixes a real hardware limitation enforcement bug on LPDDR5 systems
- Without the fix, users can break dynamic memory tuning on LPDDR5
Broadcom STB hardware
- Extremely small and surgical (adds 1 define, 1 condition, renames
function)
- Written by the original driver author (Florian Fainelli at Broadcom)
- Accepted by subsystem maintainer
- Applies cleanly to stable trees (minimal file history)
- Driver exists in all active LTS trees (6.1+)
- Falls into the "hardware quirk/workaround" exception category
- Zero regression risk to existing LPDDR4 or other memory type users
**AGAINST backporting:**
- Affects only Broadcom STB users with LPDDR5 memory (narrow user base)
- No Fixes: tag, no Reported-by (but this is expected for the review
pipeline)
- The commit message uses "expand" rather than "fix" language
### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - single condition addition, by
driver author
2. **Fixes a real bug?** YES - allows dangerous SRPD modification on
LPDDR5
3. **Important issue?** MEDIUM-HIGH - memory controller misconfiguration
4. **Small and contained?** YES - ~4 lines changed in 1 file
5. **No new features or APIs?** CORRECT - only extends an existing check
6. **Can apply to stable trees?** YES - driver exists since 6.1
### Step 9.3: EXCEPTION CATEGORIES
This falls into the **hardware quirk/workaround** category - extending
an existing hardware limitation check to cover newly-recognized
hardware.
### Step 9.4: DECISION
The fix is small, surgical, obviously correct, written by the driver
author, and prevents real hardware misconfiguration on LPDDR5 Broadcom
STB systems. The risk is negligible and the benefit is real for affected
users.
---
## Verification
- [Phase 1] Parsed tags: Signed-off-by by Florian Fainelli (driver
author), accepted by Krzysztof Kozlowski (maintainer). No
Fixes/Reported-by tags.
- [Phase 2] Diff analysis: 1 new #define, 1 additional condition in
existing check function, 1 function rename, 1 caller update. Total ~4
lines changed.
- [Phase 3] git blame: All code introduced in commit a4be90ff7a7d2
(v6.1-rc1) by same author (Florian Fainelli).
- [Phase 3] git describe --contains: confirmed driver first appeared in
v6.1-rc1.
- [Phase 3] git log v6.1..v6.6..v6.12: confirmed driver exists in all
active stable trees.
- [Phase 3] git log --author="Florian Fainelli": confirmed author is
original driver author and active maintainer.
- [Phase 3] File history: only 6 commits total, minimal churn, clean
backport expected.
- [Phase 5] Code analysis: brcmstb_memc_uses_lpddr4 called only from
srpd_store (sysfs write handler), user-triggerable path.
- [Phase 6] Driver exists in 6.1.y, 6.6.y, 6.12.y stable trees.
- [Phase 8] Failure mode: dynamic tuning becomes non-functional on
LPDDR5 systems. Severity MEDIUM-HIGH.
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
bot protection. Relied on maintainer acceptance and commit tags.
**YES**
drivers/memory/brcmstb_memc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/brcmstb_memc.c b/drivers/memory/brcmstb_memc.c
index ba73470b1b134..c28fe90936168 100644
--- a/drivers/memory/brcmstb_memc.c
+++ b/drivers/memory/brcmstb_memc.c
@@ -14,6 +14,7 @@
#define REG_MEMC_CNTRLR_CONFIG 0x00
#define CNTRLR_CONFIG_LPDDR4_SHIFT 5
+#define CNTRLR_CONFIG_LPDDR5_SHIFT 6
#define CNTRLR_CONFIG_MASK 0xf
#define REG_MEMC_SRPD_CFG_21 0x20
#define REG_MEMC_SRPD_CFG_20 0x34
@@ -34,14 +35,15 @@ struct brcmstb_memc {
u32 srpd_offset;
};
-static int brcmstb_memc_uses_lpddr4(struct brcmstb_memc *memc)
+static int brcmstb_memc_uses_lpddr45(struct brcmstb_memc *memc)
{
void __iomem *config = memc->ddr_ctrl + REG_MEMC_CNTRLR_CONFIG;
u32 reg;
reg = readl_relaxed(config) & CNTRLR_CONFIG_MASK;
- return reg == CNTRLR_CONFIG_LPDDR4_SHIFT;
+ return reg == CNTRLR_CONFIG_LPDDR4_SHIFT ||
+ reg == CNTRLR_CONFIG_LPDDR5_SHIFT;
}
static int brcmstb_memc_srpd_config(struct brcmstb_memc *memc,
@@ -95,7 +97,7 @@ static ssize_t srpd_store(struct device *dev, struct device_attribute *attr,
* dynamic tuning process will also get affected by the inactivity
* timeout, thus making it non functional.
*/
- if (brcmstb_memc_uses_lpddr4(memc))
+ if (brcmstb_memc_uses_lpddr45(memc))
return -EOPNOTSUPP;
ret = kstrtouint(buf, 10, &val);
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] media: stm32: dcmi: stop the dma transfer on overrun
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Alain Volmat, Sakari Ailus, Mauro Carvalho Chehab, Sasha Levin,
hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue,
linux-media, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Alain Volmat <alain.volmat@foss.st.com>
[ Upstream commit 4847286b87ccda7bdec8245f35c07203ce9eb0ed ]
Ensure to stop the dma transfer whenever receiving a overrun
to avoid having a buffer partially filled with a frame and
partially with the next frame.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the necessary information. Let me compile my
comprehensive analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem**: `media: stm32: dcmi:`
- **Action verb**: "stop" - implies fixing incorrect behavior (not
stopping something that should be stopped)
- **Summary**: Stops DMA transfer on hardware overrun to prevent frame
data corruption
### Step 1.2: Tags
- `Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>` - Author,
STMicroelectronics employee (the SoC vendor)
- `Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>` - media
subsystem co-maintainer
- `Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>` -
media subsystem maintainer
- No Fixes: tag, no Reported-by:, no Cc: stable (expected for autosel
candidates)
### Step 1.3: Commit Body
The commit explicitly describes data corruption: *"avoid having a buffer
partially filled with a frame and partially with the next frame"*. This
is frame-level data corruption during video capture. The mechanism is:
when DCMI hardware overruns, DMA continues writing into the active
buffer, mixing two different frames.
### Step 1.4: Hidden Bug Fix Detection
Despite using "ensure to stop" rather than "fix", this IS a data
corruption fix. The word "ensure" indicates adding a missing safety
action. The description of mixed frames in a buffer is a concrete, real-
world data corruption scenario.
Record: This is a real data corruption fix disguised with neutral
language.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- Single file modified: `drivers/media/platform/st/stm32/stm32-dcmi.c`
- Function modified: `dcmi_irq_thread()` (the threaded IRQ handler)
- ~12 lines added, 0 lines removed (net)
- Scope: single-function surgical fix
### Step 2.2: Code Flow Change
**BEFORE**: When `IT_OVR` (overrun) occurs, the handler just increments
counters and falls through. DMA continues to run, potentially filling
the buffer with data from the next frame.
**AFTER**: When `IT_OVR` occurs:
1. Disable DCMI capture (`reg_clear(dcmi->regs, DCMI_CR, CR_CAPTURE)`)
2. Increment counters (existing code)
3. Release spinlock
4. Terminate DMA (`dmaengine_terminate_sync`)
5. Restart capture cleanly (`dcmi_restart_capture`)
6. Return `IRQ_HANDLED` early
### Step 2.3: Bug Mechanism
**Category**: Data corruption / logic fix. The overrun condition means
the DCMI FIFO overflowed and data was lost. Without stopping DMA, the
buffer ends up with partial frame N data followed by frame N+1 data,
delivering a corrupt buffer to userspace.
### Step 2.4: Fix Quality
- **Obviously correct**: Yes - the terminate+restart pattern is already
used in `dcmi_process_jpeg()` in the same file
- **Minimal/surgical**: Yes - only the overrun handler is modified
- **Regression risk**: Low - `dmaengine_terminate_sync()` is safe in
threaded IRQ context; `dcmi_restart_capture()` has its own internal
locking
- **Locking correctness**: Verified - spinlock released before
`dmaengine_terminate_sync` (which may sleep); `dcmi_restart_capture`
takes its own lock internally
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
The overrun handler code was introduced by commit `1be0a2b702308f`
(2019, v5.2 cycle) which added overrun counting, and the irq thread
structure from `37404f91ef8b91` (2017, v4.14 cycle). The buggy behavior
(not stopping DMA on overrun) was intentionally introduced by commit
`a1029f552c3f` (2018, v4.17 cycle) titled *"rework overrun/error case"*
which REMOVED the DMA stop/restart on overrun. That 2018 commit's
rationale was: *"Dma will be restarted on current frame transfer
completion."* The new commit reverses this decision because the
assumption was wrong - DMA does not properly self-recover on overrun.
### Step 3.2: No Fixes tag present
The implicit Fixes target would be `a1029f552c3f` ("rework overrun/error
case", v4.17) which exists in ALL active stable trees.
### Step 3.3: File History
The `dcmi_irq_thread` function has been stable since 2019. Recent
changes to this file are minor cleanups (style, API renames) that don't
affect the overrun path.
### Step 3.4: Author Context
Alain Volmat is from STMicroelectronics (the SoC vendor). He is an
active contributor to the STM32 media subsystem, maintaining both DCMI
and DCMIPP drivers. The patch was reviewed and signed off by both media
subsystem co-maintainers.
### Step 3.5: Dependencies
The patch was submitted as 4/12 in a series. However, patches 1-3 touch
unrelated code paths (pm_ptr, dma config at probe, descriptor creation).
Patch 5 reworks locking (makes `dcmi_restart_capture` caller-locked),
but patch 4 works correctly with the CURRENT `dcmi_restart_capture`
which has its own internal locking. This patch is self-contained.
---
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1: Original Submission
Found at `http://lists.infradead.org/pipermail/linux-arm-
kernel/2026-January/1091896.html`. Part of series v2 "media: stm32:
dcmi: stability & performance enhancements" (12 patches). Cover letter
explicitly states: *"This series improve stability of the capture by
fixing the handling of the overrun which was leading to captured frame
corruption."*
### Step 4.2: Reviewers
Signed off by Sakari Ailus (media co-maintainer) and Mauro Carvalho
Chehab (media maintainer). The patch has proper maintainer chain sign-
off.
### Step 4.3-4.5: Bug Report / Stable Discussion
The bug was found during development by the hardware vendor
(STMicroelectronics). No explicit stable nomination was found, nor any
objections.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1-5.2: Function Analysis
`dcmi_irq_thread` is the threaded IRQ handler, called whenever the DCMI
hardware fires an interrupt (overrun, error, or frame complete). The
`IT_OVR` flag is set by the hardware when the DCMI internal FIFO
overflows. The `dcmi_restart_capture` → `dcmi_start_capture` →
`dcmi_start_dma` chain properly sets up a new DMA transfer and re-
enables capture.
### Step 5.3-5.4: The DMA stop + restart pattern
The same pattern exists in `dcmi_process_jpeg()` at line 434-440:
`dmaengine_terminate_sync` followed by `dcmi_restart_capture`. The
overrun fix replicates this proven pattern.
### Step 5.5: Similar Patterns
`dcmi_process_jpeg` already uses the exact same terminate+restart
pattern. `dcmi_dma_callback` also calls `dcmi_restart_capture` after DMA
completion. This is a well-established pattern in the driver.
---
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Buggy Code in Stable
The buggy overrun handler (just counting, not stopping DMA) exists since
v4.17 (commit `a1029f552c3f`). It is present in ALL active stable trees
(5.4, 5.10, 5.15, 6.1, 6.6, 6.12).
### Step 6.2: Backport Complications
The patch modifies a single function with clean context. The file path
changed from `stm32/stm32-dcmi.c` to `st/stm32/stm32-dcmi.c` in 6.5+,
but the function code is identical in context. Minor adjustment may be
needed for older trees.
### Step 6.3: No related fixes already in stable for this overrun issue.
---
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: Subsystem Criticality
- **Subsystem**: drivers/media/platform (embedded camera driver)
- **Criticality**: PERIPHERAL (specific STM32 hardware) but important
for embedded/IoT users
- STM32 SoCs are widely used in embedded systems, industrial cameras,
IoT devices
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Affected Users
STM32 DCMI users - embedded systems with camera interfaces on STM32MP1
SoCs.
### Step 8.2: Trigger Conditions
Overrun occurs when the camera sends data faster than DMA can drain the
DCMI FIFO. This is common during high-resolution or high-framerate
capture, or under system load. Not timing-dependent - it's a hardware
FIFO overflow condition.
### Step 8.3: Failure Mode Severity
**Data corruption** - frames delivered to userspace contain mixed data
from two different frames. For embedded camera applications (industrial
vision, surveillance, medical), this is a **HIGH** severity issue since
corrupted frames can lead to incorrect decisions.
### Step 8.4: Risk-Benefit
- **Benefit**: HIGH - prevents data corruption in active video capture
on STM32 platforms
- **Risk**: LOW - ~12 lines, single function, follows proven existing
pattern in the same driver, correct locking, no API changes
- **Ratio**: Strongly favorable
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backporting:**
- Fixes real data corruption (mixed frames in buffer)
- Small, surgical fix (12 lines in one function)
- Follows proven existing pattern in same driver (`dcmi_process_jpeg`)
- Author is from the hardware vendor (STMicroelectronics)
- Signed off by both media subsystem maintainers
- Correct locking model (spinlock released before sleeping call)
- Buggy code exists in all active stable trees
- Self-contained - does not depend on other patches in the series
**AGAINST backporting:**
- Part of a 12-patch series (but verified standalone correctness)
- Later patches (5, 7) further modify this code (but patch 4 is correct
without them)
- No explicit Cc: stable (expected for autosel candidates)
### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - pattern matches existing code
in same driver, vendor-tested
2. Fixes a real bug? **YES** - data corruption (mixed frames)
3. Important issue? **YES** - data corruption during video capture
4. Small and contained? **YES** - 12 lines, single function
5. No new features/APIs? **YES** - no new features
6. Can apply to stable? **YES** - code context is unchanged in stable
trees
### Step 9.3: No exception categories apply; this is a straightforward
bug fix.
---
## Verification
- [Phase 1] Parsed tags: SOBs from author (STMicroelectronics), Sakari
Ailus, Mauro Carvalho Chehab
- [Phase 2] Diff analysis: ~12 lines added to overrun path in
`dcmi_irq_thread()`, adds DMA stop + restart
- [Phase 3] git blame: overrun handler code from commit `1be0a2b702308f`
(2019, v5.2); bug-causing rework from `a1029f552c3f` (2018, v4.17)
- [Phase 3] git show `a1029f552c3f`: confirmed it intentionally removed
DMA stop/restart on overrun - present in all stable trees
- [Phase 3] Verified `dcmi_restart_capture()` has internal locking -
standalone patch is correct
- [Phase 4] Found original submission at lists.infradead.org; cover
letter confirms frame corruption fix
- [Phase 4] Verified patch 5/12 changes `dcmi_restart_capture` locking,
but patch 4 works with current code
- [Phase 4] Patch 7/12 changes `terminate_sync` to `terminate_async` -
optimization, not required for correctness
- [Phase 5] Verified same pattern (`dmaengine_terminate_sync` +
`dcmi_restart_capture`) exists in `dcmi_process_jpeg()` at lines
434-440
- [Phase 5] Verified `dcmi_start_capture()` re-enables CR_CAPTURE at
line 372, matching our clear at overrun
- [Phase 6] Confirmed code exists unchanged in all active stable trees
(5.4+)
- [Phase 8] Failure mode: data corruption (mixed frames) - severity HIGH
The fix is small, surgical, follows proven patterns in the same driver,
and prevents real data corruption on STM32 embedded platforms.
**YES**
drivers/media/platform/st/stm32/stm32-dcmi.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c b/drivers/media/platform/st/stm32/stm32-dcmi.c
index 13762861b7694..496e0781a957b 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -447,9 +447,21 @@ static irqreturn_t dcmi_irq_thread(int irq, void *arg)
spin_lock_irq(&dcmi->irqlock);
if (dcmi->misr & IT_OVR) {
+ /* Disable capture */
+ reg_clear(dcmi->regs, DCMI_CR, CR_CAPTURE);
+
dcmi->overrun_count++;
+
if (dcmi->overrun_count > OVERRUN_ERROR_THRESHOLD)
dcmi->errors_count++;
+
+ spin_unlock_irq(&dcmi->irqlock);
+ dmaengine_terminate_sync(dcmi->dma_chan);
+
+ if (dcmi_restart_capture(dcmi))
+ dev_err(dcmi->dev, "%s: Cannot restart capture\n", __func__);
+
+ return IRQ_HANDLED;
}
if (dcmi->misr & IT_ERR)
dcmi->errors_count++;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox