* [PATCH v5 13/19] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
__drm_atomic_helper_connector_state_reset() is used to initialize a
newly allocated drm_connector_state, and is being typically called by
the drm_connector_funcs.reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_connector_state instance, we will need to call
__drm_atomic_helper_connector_state_reset() from both the reset and
atomic_create hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_connector_state_reset() to
__drm_atomic_helper_connector_state_init().
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 12 ++++++------
include/drm/drm_atomic_state_helper.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 8762171c9432..e2e5a1b8a820 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -474,24 +474,24 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
kfree(state);
}
EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
/**
- * __drm_atomic_helper_connector_state_reset - reset the connector state
+ * __drm_atomic_helper_connector_state_init - Initialize the connector state
* @conn_state: atomic connector state, must not be NULL
- * @connector: connectotr object, must not be NULL
+ * @connector: connector object, must not be NULL
*
* Initializes the newly allocated @conn_state with default
* values. This is useful for drivers that subclass the connector state.
*/
void
-__drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
- struct drm_connector *connector)
+__drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
+ struct drm_connector *connector)
{
conn_state->connector = connector;
}
-EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
+EXPORT_SYMBOL(__drm_atomic_helper_connector_state_init);
/**
* __drm_atomic_helper_connector_reset - reset state on connector
* @connector: drm connector
* @conn_state: connector state to assign
@@ -506,11 +506,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
void
__drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state *conn_state)
{
if (conn_state)
- __drm_atomic_helper_connector_state_reset(conn_state, connector);
+ __drm_atomic_helper_connector_state_init(conn_state, connector);
connector->state = conn_state;
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_reset);
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 213f7e298008..9634a70e0401 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -68,11 +68,11 @@ struct drm_plane_state *
drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane);
void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state);
void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
-void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
+void __drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
struct drm_connector *connector);
void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state *conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
--
2.54.0
^ permalink raw reply related
* [PATCH v5 14/19] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
__drm_atomic_helper_connector_hdmi_reset() is typically used to
initialize a newly allocated drm_connector_state when the connector is
using the HDMI helpers, and is being called by the
drm_connector_funcs.reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_connector_state instance, we will need to call
__drm_atomic_helper_connector_hdmi_reset() from both the reset and
atomic_create hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_connector_hdmi_reset() to
__drm_atomic_helper_connector_hdmi_state_init().
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 15 ++++++++-------
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
include/drm/display/drm_hdmi_state_helper.h | 4 ++--
6 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 649969fca141..50408af746d8 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -270,12 +270,12 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
drm_atomic_helper_connector_reset(connector);
if (bridge_connector->bridge_hdmi)
- __drm_atomic_helper_connector_hdmi_reset(connector,
- connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector,
+ connector->state);
}
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 4867edbf2622..a331ebdd65af 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -304,29 +304,30 @@
* --kunitconfig=drivers/gpu/drm/tests \
* drm_atomic_helper_connector_hdmi_*
*/
/**
- * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
+ * __drm_atomic_helper_connector_hdmi_state_init() - Initialize all HDMI @drm_connector_state resources
* @connector: DRM connector
- * @new_conn_state: connector state to reset
+ * @new_conn_state: connector state to initialize
*
* Initializes all HDMI resources from a @drm_connector_state without
* actually allocating it. This is useful for HDMI drivers, in
- * combination with __drm_atomic_helper_connector_reset() or
- * drm_atomic_helper_connector_reset().
+ * combination with __drm_atomic_helper_connector_state_init(),
+ * drm_atomic_helper_connector_reset(), or
+ * drm_atomic_helper_connector_create_state().
*/
-void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
{
unsigned int max_bpc = connector->max_bpc;
new_conn_state->max_bpc = max_bpc;
new_conn_state->max_requested_bpc = max_bpc;
new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
}
-EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
+EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_state_init);
static enum hdmi_colorspace
output_color_format_to_hdmi_colorspace(const struct drm_connector *connector,
enum drm_output_color_format fmt)
{
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 07e2afcb4f95..3cad8f9bc529 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -283,11 +283,11 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
}
static void sun4i_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
}
static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
.detect = sun4i_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
index c9819c3fc635..e89e1af7a811 100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -166,11 +166,11 @@ static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
};
static void dummy_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
}
static const struct drm_connector_funcs dummy_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a161d3b00a25..74dce4be0c00 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -506,11 +506,11 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
}
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
+ __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
drm_atomic_helper_connector_tv_margins_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.force = drm_atomic_helper_connector_hdmi_force,
diff --git a/include/drm/display/drm_hdmi_state_helper.h b/include/drm/display/drm_hdmi_state_helper.h
index 0adc30c55ec9..13375bd0f4ae 100644
--- a/include/drm/display/drm_hdmi_state_helper.h
+++ b/include/drm/display/drm_hdmi_state_helper.h
@@ -9,12 +9,12 @@ struct drm_connector_state;
struct drm_display_mode;
struct hdmi_audio_infoframe;
enum drm_connector_status;
-void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state);
+void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state);
int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
struct drm_atomic_commit *state);
int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
--
2.54.0
^ permalink raw reply related
* [PATCH v5 15/19] drm/connector: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
to drm_private_obj") introduced a new pattern for allocating drm object
states.
Instead of relying on the reset() callback, it created a new
atomic_create_state hook. This is helpful because reset is a bit
overloaded: it's used to create the initial software state, reset it,
but also reset the hardware.
It can also be used either at probe time, to create the initial state
and possibly reset the hardware to an expected default, but also during
suspend/resume.
Both these cases come with different expectations too: during the
initialization, we want to initialize all states, but during
suspend/resume, drm_private_states for example are expected to be kept
around.
reset() also isn't fallible, which makes it harder to handle
initialization errors properly. This is only really relevant for some
drivers though, since all the helpers for reset only create a new
state, and don't touch the hardware at all.
It was thus decided to create a new hook that would allocate and
initialize a pristine state without any side effect:
atomic_create_state to untangle a bit some of it, and to separate the
initialization with the actual reset one might need during a
suspend/resume.
Continue the transition to the new pattern with connectors.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 26 ++++++++++++++++++++++++++
drivers/gpu/drm/drm_connector.c | 10 +++++++++-
drivers/gpu/drm/drm_mode_config.c | 31 ++++++++++++++++++++++++++++++-
include/drm/drm_atomic_state_helper.h | 2 ++
include/drm/drm_connector.h | 16 ++++++++++++++++
5 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index e2e5a1b8a820..07686e94aae0 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -532,10 +532,36 @@ void drm_atomic_helper_connector_reset(struct drm_connector *connector)
kfree(connector->state);
__drm_atomic_helper_connector_reset(connector, conn_state);
}
EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
+/**
+ * drm_atomic_helper_connector_create_state - default &drm_connector_funcs.atomic_create_state hook for connectors
+ * @connector: connector object
+ *
+ * Allocates and initializes pristine @drm_connector_state.
+ *
+ * This is useful for drivers that don't subclass @drm_connector_state.
+ *
+ * RETURNS:
+ * Pointer to new connector state, or ERR_PTR on failure.
+ */
+struct drm_connector_state *
+drm_atomic_helper_connector_create_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *state;
+
+ state = kzalloc_obj(*state);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ __drm_atomic_helper_connector_state_init(state, connector);
+
+ return state;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_create_state);
+
/**
* drm_atomic_helper_connector_tv_margins_reset - Resets TV connector properties
* @connector: DRM connector
*
* Resets the TV-related properties attached to a connector.
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..a0b132c658a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -616,11 +616,19 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
/*
* drm_connector_attach_max_bpc_property() requires the
* connector to have a state.
*/
- if (connector->funcs->reset)
+ if (connector->funcs->atomic_create_state) {
+ struct drm_connector_state *state;
+
+ state = connector->funcs->atomic_create_state(connector);
+ if (IS_ERR(state))
+ return PTR_ERR(state);
+
+ connector->state = state;
+ } else if (connector->funcs->reset)
connector->funcs->reset(connector);
drm_connector_attach_max_bpc_property(connector, 8, max_bpc);
connector->max_bpc = max_bpc;
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 2e2cd18a14b4..9d240817f8b6 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -235,10 +235,36 @@ static int drm_mode_config_crtc_reset_with_create_state(struct drm_crtc *crtc)
}
return drm_mode_config_crtc_create_state(crtc);
}
+static int drm_mode_config_connector_create_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state;
+
+ if (!connector->funcs->atomic_create_state)
+ return 0;
+
+ conn_state = connector->funcs->atomic_create_state(connector);
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ connector->state = conn_state;
+
+ return 0;
+}
+
+static int drm_mode_config_connector_reset_with_create_state(struct drm_connector *connector)
+{
+ if (connector->state) {
+ connector->funcs->atomic_destroy_state(connector, connector->state);
+ connector->state = NULL;
+ }
+
+ return drm_mode_config_connector_create_state(connector);
+}
+
/**
* drm_mode_config_reset - call ->reset callbacks
* @dev: drm device
*
* This functions calls all the crtc's, encoder's and connector's ->reset
@@ -278,13 +304,16 @@ void drm_mode_config_reset(struct drm_device *dev)
drm_for_each_encoder(encoder, dev)
if (encoder->funcs && encoder->funcs->reset)
encoder->funcs->reset(encoder);
drm_connector_list_iter_begin(dev, &conn_iter);
- drm_for_each_connector_iter(connector, &conn_iter)
+ drm_for_each_connector_iter(connector, &conn_iter) {
if (connector->funcs->reset)
connector->funcs->reset(connector);
+ else if (connector->funcs->atomic_create_state)
+ drm_mode_config_connector_reset_with_create_state(connector);
+ }
drm_connector_list_iter_end(&conn_iter);
}
EXPORT_SYMBOL(drm_mode_config_reset);
/*
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 9634a70e0401..f4b6d8833bc2 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -73,10 +73,12 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
void __drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
struct drm_connector *connector);
void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state *conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+struct drm_connector_state *
+drm_atomic_helper_connector_create_state(struct drm_connector *connector);
void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
struct drm_atomic_commit *state);
void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
void
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5ad62c207d00..529755c2e862 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1569,10 +1569,26 @@ struct drm_connector_funcs {
* when a connector is being hot-unplugged for drivers that support
* connector hotplugging (e.g. DisplayPort MST).
*/
void (*destroy)(struct drm_connector *connector);
+ /**
+ * @atomic_create_state:
+ *
+ * Allocate a pristine, initialized, state for the connector
+ * object and return it. This callback must have no side
+ * effects: in particular, the returned state must not be
+ * assigned to the object's state pointer and it must not affect
+ * the hardware state.
+ *
+ * RETURNS:
+ *
+ * A new, pristine, connector state instance or an error pointer
+ * on failure.
+ */
+ struct drm_connector_state *(*atomic_create_state)(struct drm_connector *connector);
+
/**
* @atomic_duplicate_state:
*
* Duplicate the current atomic state for this connector and return it.
* The core and helpers guarantee that any atomic state duplicated with
--
2.54.0
^ permalink raw reply related
* [PATCH v5 16/19] drm/mode-config: Create drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
drm_mode_config_reset() can be used to create the initial state, but
also to return to the initial state, when doing a suspend/resume cycle
for example.
It also affects both the software and the hardware, and drivers can
choose to reset the hardware as well. Most will just create an empty
state and the synchronisation between hardware and software states will
effectively be done when the first commit is done.
That dual role can be harmful, since some objects do need to be
initialized but also need to be preserved across a suspend/resume cycle.
drm_private_obj are such objects for example.
Thus, create another helper for drivers to call to initialize their
state when the driver is loaded, so we can make
drm_mode_config_reset() only about handling suspend/resume and similar.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic.c | 13 +++++-
drivers/gpu/drm/drm_mode_config.c | 89 +++++++++++++++++++++++++++++++++++++++
include/drm/drm_mode_config.h | 1 +
3 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d98586d89bbe..ea021250925c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -59,12 +59,21 @@
* preparing the update and kept alive as long as they are active in the
* device.
*
* Their respective lifetimes are:
*
- * - at reset time, the object reset implementation will allocate a new
- * default state and will store it in the object state pointer.
+ * - at driver initialization time, the driver will call
+ * drm_mode_config_create_initial_state() to allocate an initial,
+ * pristine, state for each object and will store it in the objects
+ * state pointer. Historically, this was one of
+ * drm_mode_config_reset() job, so one might still encounter it in a
+ * driver.
+ *
+ * - at reset time, for example during suspend/resume,
+ * drm_mode_config_reset() will reset the software and hardware state
+ * to a known default and will store it in the object's state pointer.
+ * Not all objects are affected by drm_mode_config_reset() though.
*
* - whenever a new update is needed:
*
* + A new &struct drm_atomic_commit is allocated using
* drm_atomic_commit_alloc().
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 9d240817f8b6..f432f485a914 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -21,10 +21,11 @@
*/
#include <linux/export.h>
#include <linux/uaccess.h>
+#include <drm/drm_atomic.h>
#include <drm/drm_drv.h>
#include <drm/drm_encoder.h>
#include <drm/drm_file.h>
#include <drm/drm_framebuffer.h>
#include <drm/drm_managed.h>
@@ -314,10 +315,98 @@ void drm_mode_config_reset(struct drm_device *dev)
}
drm_connector_list_iter_end(&conn_iter);
}
EXPORT_SYMBOL(drm_mode_config_reset);
+/**
+ * drm_mode_config_create_initial_state - Allocates the initial state
+ * @dev: drm device
+ *
+ * This functions creates the initial state for all the objects. Drivers
+ * can use this in e.g. probe to initialize their software state.
+ *
+ * It has two main differences with drm_mode_config_reset(): the reset()
+ * hooks aren't called and thus the hardware will be left untouched, but
+ * also the &drm_private_obj structures will be initialized as opposed
+ * to drm_mode_config_reset() that skips them.
+ *
+ * Returns: 0 on success, negative error value on failure.
+ */
+int drm_mode_config_create_initial_state(struct drm_device *dev)
+{
+ struct drm_crtc *crtc;
+ struct drm_colorop *colorop;
+ struct drm_plane *plane;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_private_obj *privobj;
+ int ret;
+
+ drm_for_each_privobj(privobj, dev) {
+ struct drm_private_state *privobj_state;
+
+ if (privobj->state)
+ continue;
+
+ if (!privobj->funcs->atomic_create_state)
+ continue;
+
+ privobj_state = privobj->funcs->atomic_create_state(privobj);
+ if (IS_ERR(privobj_state))
+ return PTR_ERR(privobj_state);
+
+ privobj->state = privobj_state;
+ }
+
+ drm_for_each_colorop(colorop, dev) {
+ struct drm_colorop_state *colorop_state;
+
+ if (colorop->state)
+ continue;
+
+ colorop_state = drm_atomic_helper_colorop_create_state(colorop);
+ if (IS_ERR(colorop_state))
+ return PTR_ERR(colorop_state);
+
+ colorop->state = colorop_state;
+ }
+
+ drm_for_each_plane(plane, dev) {
+ if (plane->state)
+ continue;
+
+ ret = drm_mode_config_plane_create_state(plane);
+ if (ret)
+ return ret;
+ }
+
+ drm_for_each_crtc(crtc, dev) {
+ if (crtc->state)
+ continue;
+
+ ret = drm_mode_config_crtc_create_state(crtc);
+ if (ret)
+ return ret;
+ }
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ if (connector->state)
+ continue;
+
+ ret = drm_mode_config_connector_create_state(connector);
+ if (ret) {
+ drm_connector_list_iter_end(&conn_iter);
+ return ret;
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_config_create_initial_state);
+
/*
* Global properties
*/
static const struct drm_prop_enum_list drm_plane_type_enum_list[] = {
{ DRM_PLANE_TYPE_OVERLAY, "Overlay" },
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e584652ddf67..d8f5b7e9673e 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -1005,9 +1005,10 @@ int __must_check drmm_mode_config_init(struct drm_device *dev);
static inline int drm_mode_config_init(struct drm_device *dev)
{
return drmm_mode_config_init(dev);
}
+int drm_mode_config_create_initial_state(struct drm_device *dev);
void drm_mode_config_reset(struct drm_device *dev);
void drm_mode_config_cleanup(struct drm_device *dev);
#endif
--
2.54.0
^ permalink raw reply related
* [PATCH v5 17/19] drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-19 9:01 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
The driver skeleton currently recommends calling
drm_mode_config_reset() at probe time to create the initial state.
Now that drm_mode_config_create_initial_state() exists to handle
initial state allocation without hardware side effects, update the
skeleton to recommend it instead.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 985c283cf59f..f537556b06a8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -340,11 +340,13 @@ void drm_minor_release(struct drm_minor *minor)
*
* // Further setup, display pipeline etc
*
* platform_set_drvdata(pdev, drm);
*
- * drm_mode_config_reset(drm);
+ * ret = drm_mode_config_create_initial_state(drm);
+ * if (ret)
+ * return ret;
*
* ret = drm_dev_register(drm);
* if (ret)
* return ret;
*
--
2.54.0
^ permalink raw reply related
* [PATCH v5 18/19] drm/tidss: Convert to atomic_create_state
From: Maxime Ripard @ 2026-05-19 9:02 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
Our driver uses reset to create the various object states, but only
calls the helper that allocate a new state. They are thus strictly
equivalent to the new atomic_create_state helpers, so let's switch to
these.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/tidss/tidss_crtc.c | 17 +++++++----------
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
index acab9307bdf3..400329aa2200 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -355,24 +355,21 @@ static void tidss_crtc_destroy_state(struct drm_crtc *crtc,
__drm_atomic_helper_crtc_destroy_state(&tstate->base);
kfree(tstate);
}
-static void tidss_crtc_reset(struct drm_crtc *crtc)
+static struct drm_crtc_state *tidss_crtc_create_state(struct drm_crtc *crtc)
{
struct tidss_crtc_state *tstate;
- if (crtc->state)
- tidss_crtc_destroy_state(crtc, crtc->state);
-
tstate = kzalloc_obj(*tstate);
- if (!tstate) {
- crtc->state = NULL;
- return;
- }
+ if (!tstate)
+ return ERR_PTR(-ENOMEM);
- __drm_atomic_helper_crtc_reset(crtc, &tstate->base);
+ __drm_atomic_helper_crtc_state_init(&tstate->base, crtc);
+
+ return &tstate->base;
}
static struct drm_crtc_state *tidss_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct tidss_crtc_state *state, *current_state;
@@ -403,14 +400,14 @@ static void tidss_crtc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
kfree(tcrtc);
}
static const struct drm_crtc_funcs tidss_crtc_funcs = {
- .reset = tidss_crtc_reset,
.destroy = tidss_crtc_destroy,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
+ .atomic_create_state = tidss_crtc_create_state,
.atomic_duplicate_state = tidss_crtc_duplicate_state,
.atomic_destroy_state = tidss_crtc_destroy_state,
.enable_vblank = tidss_crtc_enable_vblank,
.disable_vblank = tidss_crtc_disable_vblank,
};
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
index 1a8b44fb45f8..6d82976c2db1 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -176,12 +176,12 @@ static const struct drm_plane_helper_funcs tidss_primary_plane_helper_funcs = {
};
static const struct drm_plane_funcs tidss_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .reset = drm_atomic_helper_plane_reset,
.destroy = drm_plane_destroy,
+ .atomic_create_state = drm_atomic_helper_plane_create_state,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
--
2.54.0
^ permalink raw reply related
* [PATCH v5 19/19] drm/bridge_connector: Convert to atomic_create_state
From: Maxime Ripard @ 2026-05-19 9:02 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org>
The connector created by drm_bridge_connector only initializes a
pristine state in reset, which is equivalent to what
atomic_create_state would expect. Convert to it.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 50408af746d8..cafa498c3848 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -263,26 +263,33 @@ static void drm_bridge_connector_debugfs_init(struct drm_connector *connector,
if (bridge->funcs->debugfs_init)
bridge->funcs->debugfs_init(bridge, root);
}
}
-static void drm_bridge_connector_reset(struct drm_connector *connector)
+static struct drm_connector_state *
+drm_bridge_connector_create_state(struct drm_connector *connector)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ struct drm_connector_state *conn_state;
+
+ conn_state = drm_atomic_helper_connector_create_state(connector);
+ if (IS_ERR(conn_state))
+ return conn_state;
- drm_atomic_helper_connector_reset(connector);
if (bridge_connector->bridge_hdmi)
__drm_atomic_helper_connector_hdmi_state_init(connector,
- connector->state);
+ conn_state);
+
+ return conn_state;
}
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
- .reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
.force = drm_bridge_connector_force,
.fill_modes = drm_helper_probe_single_connector_modes,
+ .atomic_create_state = drm_bridge_connector_create_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
.oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-05-19 9:02 UTC (permalink / raw)
To: Krzysztof Kozlowski, rafael, bp, saket.dumbre, will, xueshuai,
mchehab, krzk+dt, dave, conor+dt, vishal.l.verma, jic23, corbet,
guohanjun, dave.jiang, catalin.marinas, lenb, tony.luck, skhan,
djbw, alison.schofield, ira.weiny, robh
Cc: devicetree, linux-acpi, linux-doc, Dmitry.Lamerov, linux-cxl,
Michael.Zhao2, acpica-devel, linux-kernel, linux-arm-kernel,
linux-edac
In-Reply-To: <5fb43b8d-e772-42af-ba78-d75abd87bd0c@kernel.org>
On 19/05/2026 08:04, Krzysztof Kozlowski wrote:
> On 18/05/2026 13:57, Ahmed Tiba wrote:
>> Describe the DeviceTree node that exposes the Arm firmware-first
>> CPER provider and hook the file into MAINTAINERS so the
>> binding has an owner.
>>
>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>
> Please implement previous comments.
Could you please clarify which previous DT comments you still see
as unaddressed?
My understanding was that I had addressed the earlier points on the YAML
description formatting, the `memory-region` description text, and the
example. If I missed a specific item beyond the one below, please point
me to it.
>
>> ---
>> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 71 ++++++++++++++++++++++
>> MAINTAINERS | 5 ++
>> 2 files changed, 76 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>> new file mode 100644
>> index 000000000000..81dc37390af5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>> @@ -0,0 +1,71 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Arm RAS CPER provider
>> +
>> +maintainers:
>> + - Ahmed Tiba <ahmed.tiba@arm.com>
>> +
>> +description:
>> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
>> + a firmware-first CPER error source directly via DeviceTree. Firmware
>> + provides the CPER Generic Error Status block and notifies the OS through
>> + an interrupt.
>> +
>> +properties:
>> + compatible:
>> + const: arm,ras-cper
>> +
>> + memory-region:
>> + oneOf:
>> + - items:
>> + - description:
>> + CPER Generic Error Status block exposed by firmware
>> + - items:
>> + - description:
>> + CPER Generic Error Status block exposed by firmware.
>
> Also, this is just a list with minItems. No need for oneOf.
>
Understood, I will drop the oneOf and use a plain list with minItems
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: Jan Kara @ 2026-05-19 9:12 UTC (permalink / raw)
To: Ian Kent
Cc: Jan Kara, NeilBrown, Horst Birthelmer, Amir Goldstein,
Miklos Szeredi, Jonathan Corbet, Shuah Khan, Alexander Viro,
Christian Brauner, linux-doc, linux-kernel, linux-fsdevel,
Horst Birthelmer
In-Reply-To: <b320ff9a-7f6f-44c3-940f-33f79cc5569f@themaw.net>
On Mon 18-05-26 21:39:13, Ian Kent wrote:
> On 18/5/26 16:19, Jan Kara wrote:
> > Hi Ian,
> >
> > On Mon 18-05-26 10:55:43, Ian Kent wrote:
> > > On 18/5/26 07:55, NeilBrown wrote:
> > > > On Fri, 15 May 2026, Horst Birthelmer wrote:
> > > > According to the email you linked, a problem arises when a directory has
> > > > a great many negative children. Code which walks the list of children
> > > > (such as fsnotify) while holding a lock can suffer unpredictable delays
> > > > and result in long lock-hold times. So maybe a limit on negative
> > > > dentries for any parent is what we really want. That would be clumsy to
> > > > implement I imagine.
> > > But the notion of dropping the dentry in ->d_delete() on last dput() is
> > > simple enough but did see regressions (the only other place in the VFS
> > > besides dentry_kill() that the inode is unlinked from the dentry on
> > > dput()). I wonder if the regression was related to the test itself
> > > deliberately recreating deleted files and if that really is normal
> > > behaviour. By itself that should prevent almost all negative dentries
> > > being retained. Although file systems could do this as well (think XFS
> > > inode recycling) it should be reasonable to require it be left to the
> > > VFS.
> > >
> > > But even that's not enough given that, in my case, there would still be
> > > around 4 million dentries in the LRU cache and in fsnotify there are
> > > directory child traversals holding the parent i_lock "spinlock" that are
> > > going to cause problems.
> > Do you mean there are very many positive children of a directory?
>
> Didn't quantify that.
>
> The symptom is the "Spinlock held for more than ... seconds" occurring in
> the log. So there are certainly a lot of children in the list, but it's
> an assumption the ratio of positive to negative entries is roughly the
> same as the overall ratio in the dcache.
OK, but that's not necessarily true. I have seen these complaints from the
kernel but in all the cases I remember it was due to negative dentries
accumultating in a particular directory. There are certain apps such as
ElasticSearch which really do like creating huge amounts of negative
dentries in one directory - they use hashes as filenames and use directory
lookup instead of a DB table lookup and lookup lots of non-existent keys...
> > > so why is this traversal even retained in fsnotify?
> > Not sure which traversal you mean but if you set watch on a parent, you
> > have to walk all children to set PARENT_WATCHED flag so that you don't miss
> > events on children...
>
> Yes, that traversal is what I'm questioning ... again thanks.
>
> I think the function name is still fsnotify_set_children_dentry_flags()
> in recent kernels, the subject of commit 172e422ffea2 I mentioned above.
OK, thanks.
> When you say miss events are you saying that accessing the parent dentry to
> work out if the child needs to respond to an event is quite expensive in the
> overall event processing context, that might make more sense to me ... or do
> I completely not yet understand the reasoning behind the need for the flag?
Close but not quite. The cost is the overhead of dget_parent() in
fsnotify_parent() which is often a couple of cache cold loads and atomic
instructions to find out we don't need to send any event for the current
write(2) or read(2) call. It gets worse if there are many IOs happening to
dentries in the same directory from multiple CPUs because instead of
cache-cold loads you get a cacheline contention on the parent.
> > > > But what if we move dentries to the end of the list when they become
> > > > negative, and to the start of the list when they become positive? Then
> > > > code which walks the child list could simply abort on the first
> > > > negative.
> > > >
> > > > I doubt that would be quite as easy as it sounds, but it would at least
> > > > be more focused on the observed symptom rather than some whole-system
> > > > number which only vaguely correlates with the observed symptom.
> > > >
> > > > Maybe a completely different approach: change children-walking code to
> > > > drop and retake the lock (with appropriate validation) periodically.
> > > > What too would address the specific symptom.
> > > Another good question.
> > >
> > > I have assumed that dropping and re-taking the lock cannot be done but
> > > this is a question I would like answered as well. Dropping and re-taking
> > > lock would require, as Miklos pointed out to me off-list, recording the
> > > list position with say a cursor, introducing unwanted complexity when it
> > > would be better to accept the cost of a single extra access to the parent
> > > flags (which I assume is one reason to set the flag in the child).
> > The parent access is actually more expensive than you might think. Based on
> > experience with past fsnotify related performance regression I expect some
> > 20% performance hit for small tmpfs writes if you add unconditional parent
> > access to the write path.
>
> That sounds like a lot for what should be a memory access of an already in
> memory structure since the parent must be accessed to traverse the list of
> child entries. I clearly don't fully understand the implications of what
> I'm saying but there has been mention of another context ...
Parent dentry is of course in memory but often cache cold - you don't need
the parent to do e.g. write(2) to an already open file. You seem to be
somewhat confused about the child dentry list traversal (or maybe I'm
misunderstanding) - that happens only when placing the notification mark
but definitely not for each IO operation.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [Linaro-mm-sig] Re: [PATCH RFC 2/5] dma-heap: charge dma-buf memory via explicit memcg
From: Albert Esteve @ 2026-05-19 9:17 UTC (permalink / raw)
To: Christian König
Cc: Barry Song, T.J. Mercier, Tejun Heo, Johannes Weiner,
Michal Koutný, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Michal Hocko, Roman Gushchin, Shakeel Butt, Muchun Song,
Andrew Morton, Benjamin Gaignard, Brian Starkey, John Stultz,
Christian Brauner, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Ondrej Mosnacek, Shuah Khan, cgroups, linux-doc,
linux-kernel, linux-media, dri-, linaro-mm-sig, linux-mm,
linux-security-module, selinux, linux-kselftest, mripard,
echanude
In-Reply-To: <9cc79977-9a42-40eb-bfa7-460881c1e10f@amd.com>
On Tue, May 19, 2026 at 9:53 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 5/18/26 14:06, Albert Esteve wrote:
> >>>>> udmabufs are already
> >>>>> memcg-charged, so adding a separate MEMCG_DMABUF would double count.
> >>>>> Are there any other exporters you had in mind that would benefit from
> >>>>> this approach?
> >>
> >> Well apart from DMA-buf memfd_create() is one of the things which as broken our neck in the past a couple of times.
> >>
> >> But thinking more about it what if instead of making this DMA-buf heaps specific what if we have a general cgroups function which allows to change accounting of a buffer referenced by a file descriptor to a different process?
> >>
> >> That would cover not only the DMA-buf heaps use case, but also all other DMA-buf with dmem and whatever we come up in the future as well.
> >
> > I removed a draft adding an ioctl for charge transfer from the series
> > before sending because I wanted to focus on the charge_pid_fd approach
> > and keep things simple, deferring the recharge path to a follow-up
> > depending on feedback.
> >
> > The main difference between my removed draft and what you're
> > describing, iiuc, is scope and layer: my draft was an explicit ioctl
> > on the dma-buf fd that the consumer calls to claim the charge (see
> > below), while you seem to be suggesting a more general kernel-internal
> > function that could work across buffer types and cgroup controllers,
> > so not necessarily userspace-initiated? A kernel-internal function
> > will need a way to identify the target process, which sounds similar
> > to the binder-backed approach from TJ [1]. For everything else, the
> > receiver still needs to declare itself, which the ioctl accomplishes.
> >
> > ```
> > # When an app imports a daemon-allocated buffer, it can transfer the
> > charge to itself:
> > int buf_fd = receive_dmabuf_from_daemon();
> > ioctl(buf_fd, DMA_BUF_IOCTL_XFER_CHARGE); /* charge now attributed to
> > apps's cgroup */
>
> Well that thinking goes into the right direction, but the requirements are still not completely covered as far as I can see.
>
> Let me explain below a bit more.
>
> >
> > [1] https://lore.kernel.org/cgroups/20230109213809.418135-1-tjmercier@google.com/
> >
> >>
> >> The only drawback I can see is that DMA-buf heap allocations would be temporarily accounted to the memory allocation daemon, but I don't think that this would be a problem.
> >
> > The main reasons we moved away from TJ's transfer-based approach
> > toward `charge_pid_fd` are: avoid the transient charge window on the
> > daemon's cgroup; and to decouple from Binder, allowing any allocator
> > to use it.
>
> Yeah those concerns are completely correct.
>
> The application should not volunteering says 'Charge that buffer to me.', but rather that the daemon says force charge that buffer to this application and tell me when the application is over its limit.
>
> >
> > Technically, both approaches could coexist, though. Of the three
> > scenarios TJ described:
> > - Scenario 2 is directly addressed by charge_pid_fd approach without
> > any transient charge on the daemon at the cost of one extra field in
> > the heap ioctl uAPI struct.
>
> Yeah extending the uAPI to pass in the pid on allocation time is not much of a problem, but you also need to modify the whole stack above it and that is a bit more trickier.
>
> > - Scenario 3 can be handled by the charge transfer function without
> > changes to SurfaceFlinger. The app or dequeueBuffer claims the charge
> > for itself or the app, respectively (depending on whether we include a
> > pid_fd field in the transfer ioctl). It also covers non-heap
> > exporters. The con in both variants is the transient charge window on
> > the daemon.
>
> It should be trivial for the deamon to charge the buffer to an application before handing it out.
Yeah, true.
>
> > Both approaches shift the responsibility for correct charging
> > attribution to userspace: first, 'charge_pid_fd` on the allocator's
> > side, and the transfer charge on the consumer's side.
>
> Yeah that's why I said it would be better if we do that without any uAPI change, but with all the uAPI we have to transfer file descriptors (dup(), fork(), passing FDs over sockets etc...) it could be really tricky to implement that.
>
> > Deciding on one, the other or both depends on how much we value
> > avoiding transient attribution, and how much we need a non-heap
> > generic solution. With the XFER_CHARGE we can cover both. Thus, the
> > `charge_pid_fd` approach in this RFC can be seen as a
> > performance/strictness optimisation, eliminating transient charges to
> > the daemon at the cost of a permanent uAPI addition to the heap ioctl
> > struct, but not strictly required for correctness.
>
> Well all we need is a uAPI which says charge this buffer (file descriptor) to that cgroup (pidfd).
So you favor having only the XFER_CHARGE variant. That is fine with me.
If that is fine for others also that could be the way forward. If we
extend it to accept either a pidfd or a cgroup fd (as commented
previously), we can cover all dma-buf use cases with a single
primitive:
```
ioctl(buf_fd, DMA_BUF_IOCTL_XFER_CHARGE, charge_fd);
```
With the daemon invoking this ioctl before handing out the buf_fd.
This should cover most usecases? Except for the memfd case, which
requires a separate mechanism. That would be follow-up work.
>
> With this at hand we should be able to handle all use cases at the same time.
>
> > On the other hand,
> > if we agree on the end goal of migrating other exporters to use
> > dma-buf heaps
>
> That won't work. DMA-buf heaps is actually only a rather small and Anroid specific use case.
>
> We have tons of other interfaces to allocate DMA-bufs which need to stay around because of HW restrictions and we do need a solution for them as well.
>
> Regards,
> Christian.
>
> >, and scenario 3 is addressed by adding the app's pid_fd
> > to SurfaceFlinger, then `charge_pid_fd` alone is a coherent/sufficient
> > approach despite the uAPI change.
> >
> >>
> >> Regards,
> >> Christian.
> >>
> >>>
> >>> Thanks
> >>> Barry
> >>
> >
>
^ permalink raw reply
* Re: [PATCH v4 09/10] dt-bindings: firmware: add arm,ras-cper
From: Krzysztof Kozlowski @ 2026-05-19 9:22 UTC (permalink / raw)
To: Ahmed Tiba, rafael, bp, saket.dumbre, will, xueshuai, mchehab,
krzk+dt, dave, conor+dt, vishal.l.verma, jic23, corbet, guohanjun,
dave.jiang, catalin.marinas, lenb, tony.luck, skhan, djbw,
alison.schofield, ira.weiny, robh
Cc: devicetree, linux-acpi, linux-doc, Dmitry.Lamerov, linux-cxl,
Michael.Zhao2, acpica-devel, linux-kernel, linux-arm-kernel,
linux-edac
In-Reply-To: <8bc812fd-cda5-485f-98d2-4901ec17c66f@arm.com>
On 19/05/2026 11:02, Ahmed Tiba wrote:
> On 19/05/2026 08:04, Krzysztof Kozlowski wrote:
>> On 18/05/2026 13:57, Ahmed Tiba wrote:
>>> Describe the DeviceTree node that exposes the Arm firmware-first
>>> CPER provider and hook the file into MAINTAINERS so the
>>> binding has an owner.
>>>
>>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>>
>> Please implement previous comments.
>
> Could you please clarify which previous DT comments you still see
> as unaddressed?
>
> My understanding was that I had addressed the earlier points on the YAML
> description formatting, the `memory-region` description text, and the
> example. If I missed a specific item beyond the one below, please point
> me to it.
You do not need other nodes for your device in the example. I asked why
this is needed for the example, but there was no answer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Paolo Abeni @ 2026-05-19 9:29 UTC (permalink / raw)
To: MD Danish Anwar, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao
Cc: netdev, linux-doc, linux-kernel, linux-arm-kernel,
Vladimir Oltean
In-Reply-To: <20260514075605.850674-3-danishanwar@ti.com>
On 5/14/26 9:56 AM, MD Danish Anwar wrote:
> @@ -201,6 +201,16 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
> ICSSG_PA_STATS(FW_HOST_TX_PKT_CNT),
> ICSSG_PA_STATS(FW_HOST_EGRESS_Q_PRE_OVERFLOW),
> ICSSG_PA_STATS(FW_HOST_EGRESS_Q_EXP_OVERFLOW),
> + ICSSG_PA_STATS(FW_HSR_FWD_CHECK_FAIL_DROP),
> + ICSSG_PA_STATS(FW_HSR_HE_CHECK_FAIL_DROP),
> + ICSSG_PA_STATS(FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES),
Sashiko noted that this statistic name exceed the ethtool string limit.
/P
^ permalink raw reply
* Re: Re: [PATCH v2] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: Horst Birthelmer @ 2026-05-19 9:37 UTC (permalink / raw)
To: Jan Kara
Cc: Matthew Wilcox, Horst Birthelmer, Miklos Szeredi, Jonathan Corbet,
Shuah Khan, Alexander Viro, Christian Brauner, linux-doc,
linux-kernel, linux-fsdevel, Horst Birthelmer
In-Reply-To: <mptmd2qxgqwkhfrq5dgwomysdnwoy6fnztr3ibrvbbsb7hvrv3@peg7mojzfucy>
On Tue, May 19, 2026 at 10:45:09AM +0200, Jan Kara wrote:
> Hi Horst!
>
> On Sun 17-05-26 09:57:41, Horst Birthelmer wrote:
> > On Sun, May 17, 2026 at 12:09:26AM +0100, Matthew Wilcox wrote:
> > > On Sat, May 16, 2026 at 04:52:54PM +0200, Horst Birthelmer wrote:
> > > > There was a discussion at LSFMM about servers with too many cached
> > > > negative dentries.
> > > > That gave me the idea to keep the dentries in general limited
> > > > if the system administrator needs it to.
> > >
> > > I feel you should link to the dozens of previous attempts at this kind
> > > of thing to show that you're aware that this has been tried before and
> > > you're doing something meaningfully different.
>
> <snip>
>
> > As a conclusion, I think I have an uncommon perspective on the cache entries
> > since I don't usually work on vfs but argue from the perspective of a fuse server
> > Where the kernel makes us waste resources. This hurts way more in the FUSE context
> > than in a 'normal' file system.
> > I have taken the look at the dentry cache just because people told me that this
> > has to be solved in the vfs (and I agree). I actually have a somewhat hacky patch
> > to do this from fuse and only for the fuse sb.
>
> So I'm a bit confused here. The changelog speaks only about negative
> dentries (and that's what the change also concentrates on). OTOH you've
> mentioned multiple times that you are not really interested in limiting
> negative dentries but rather positive ones because you have a problem with
> cached inodes. So can you perhaps formulate what is exactly the problem
> you're trying to solve?
Maybe the changelog was a bit misleading here.
I did of course prefer negative entries, since that could bring down the
number of cached entries. In retrospect that was probably a mistake but I
was somewhat afraid if I don't reduce those, too, someone would shurely
point out that it would be easier to cut those, since they are not really
used anyway, and would be cheap to free.
This was only to be more useful than just solving _my_ problem. Maybe not
a good approach, I don't know yet.
>
> Also you mention that cached (positive) dentries and inodes are a wasted
> memory when they aren't used. That is certainly a valid view, OTOH you can
> never predict future so you don't really know what will get used in the
> future and thus will be useful. That's why we currently side with the idea
> that memory that isn't used for something is wasted and unless there's
> something to use the memory for, we cache dentries & inodes & page cache in
> it.
>
> If I remember correctly the discussion we had at LSF, the problem why inode
> caching is a problem for you, although there's enough free memory and no
> memory pressure, is that these cached inodes pin memory on the other end of
> the FUSE communication channel and there we are getting short on memory. Is
> this what you're trying to solve?
You remember our conversation correctly and have masterfully summerized it in
the passage above. Yes, that is what I'm trying to solve.
The problem we are facing is, that the fuse server has to keep a lot of private
data and some data for locks (DLM) for the cached inodes and dentries.
(inodes are even more expensive due to byte range locking)
So my idea was to NOT keep unused (and negative) entries around.
Letting the admin set the limit where the kernel starts to clean, was just
for convenience. If it was up to me I would like to set this in the initial
negotiation in FUSE during mount.
The waste of memory for me is not in the kernel but in the fuse server. The
kernel is just the master of what we have to keep, and thus the kernel moved
to the center of attention.
In short:
all caching in the kernel hurts us since we have to keep our private data
for all positive dentries, and I want to get the most for the amount pain.
OTOH caching meta data is really useful but you have to have a good prediction
on what to keep. As we cannot predict that on either side of the kernel,
throwing away the unused parts when they get out of hand seemed like a good idea.
After the discussions here it seems like everybody has his own interpretation on
what useful data to cache is.
I'm really inclined to think about letting the lower layers decide what useful
cached data should be.
In this context probably a fuse server message as a notification for which data
it thinks can be thrown out, similar to the FORGET call but in the other direction
and if the kernel agrees it really sends a FORGET and we can clean up on the other
side.
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
Thanks a lot for looking at this,
I really appreciate it!
... and I hope I could clarify, what I was trying to do.
Horst
^ permalink raw reply
* Re: [PATCH RFC 2/5] dma-heap: charge dma-buf memory via explicit memcg
From: Albert Esteve @ 2026-05-19 9:43 UTC (permalink / raw)
To: Barry Song
Cc: Tejun Heo, Johannes Weiner, Michal Koutný, Jonathan Corbet,
Shuah Khan, Sumit Semwal, Christian König, Michal Hocko,
Roman Gushchin, Shakeel Butt, Muchun Song, Andrew Morton,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian Brauner, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Ondrej Mosnacek, Shuah Khan, cgroups, linux-doc,
linux-kernel, linux-media, dri-devel, linaro-mm-sig, linux-mm,
linux-security-module, selinux, linux-kselftest, mripard,
echanude
In-Reply-To: <CAGsJ_4xwJ7SAhKPJyRtMTw6psTO7H1EcFFpDw0po1W8PX4FE8g@mail.gmail.com>
On Tue, May 19, 2026 at 12:43 AM Barry Song <baohua@kernel.org> wrote:
>
> On Mon, May 18, 2026 at 8:16 PM Albert Esteve <aesteve@redhat.com> wrote:
> >
> > On Sat, May 16, 2026 at 9:37 AM Barry Song <baohua@kernel.org> wrote:
> > >
> > > On Tue, May 12, 2026 at 5:18 PM Albert Esteve <aesteve@redhat.com> wrote:
> > > >
> > > > On embedded platforms a central process often allocates dma-buf
> > > > memory on behalf of client applications. Without a way to
> > > > attribute the charge to the requesting client's cgroup, the
> > > > cost lands on the allocator, making per-cgroup memory limits
> > > > ineffective for the actual consumers.
> > > >
> > > > Add charge_pid_fd to struct dma_heap_allocation_data. When set to
> > > > a valid pidfd, DMA_HEAP_IOCTL_ALLOC resolves the target task's
> > > > memcg and charges the buffer there via mem_cgroup_charge_dmabuf()
> > > > inside dma_heap_buffer_alloc(). Without charge_pid_fd, and with
> > > > the mem_accounting module parameter enabled, the buffer is charged
> > > > to the allocator's own cgroup.
> > > >
> > > > Additionally, commit 3c227be90659 ("dma-buf: system_heap: account for
> > > > system heap allocation in memcg") adds __GFP_ACCOUNT to system-heap
> > > > page allocations. Keeping __GFP_ACCOUNT would charge the same pages
> > > > twice (once to kmem, once to MEMCG_DMABUF), thus remove it and route
> > > > all accounting through a single MEMCG_DMABUF path.
> > > >
> > > [...]
> > >
> > > > - if (mem_accounting)
> > > > - flags |= __GFP_ACCOUNT;
> > >
> > > Hi Albert,
> > >
> > > would it be better to move this and its description to patch 1? It
> > > looks like patch 1 already introduces the double accounting changes,
> > > and patch 2 is mainly just supporting remote charging.
> >
> > Hi Barry,
> >
> > Thanks for looking into this series! Yes, in my head I was trying to
> > keep patch 1, which was taken from a previous, different series, and
> > then diverge from it starting with patch 2. This would clarify the
> > difference between the two. But I can see it just added some confusion
> > (for example, patch 1 charges on dma_buf_export() and then it is moved
> > to dma_heap_buffer_alloc() in patch 2). I will reorganize it better
> > for the next version, including your suggestion.
>
> Yep, I understand the situation now. I also understand
> that you were referring to T.J.'s patch, which caused
> some back-and-forth confusion for readers when reading
> patches 1 and 2.
>
> >
> > >
> > > Also, mem_accounting is only used by system_heap.c; has this patchset
> > > also eliminated its need?
> >
> > No, mem_accounting is still handled in this patch for the general case
> > where no `charge_pid_fd` is used. See dma_heap_buffer_alloc() code:
> >
> > + if (memcg)
> > + css_get(&memcg->css);
> > + else if (mem_accounting)
> > + memcg = get_mem_cgroup_from_mm(current->mm);
>
> I see. What feels a bit odd to me is that mem_accounting
> could either be dropped (with unconditional charging), or
> it should cover both remote and local charge cases.
Good point. If I understand correctly, looking at patch [1] that
introduced the flag, the shared buffer caveats mentioned there are not
yet covered by this approach, so the flag should stay. I will make it
consistent and cover both remote and local charge cases.
[1] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-1-ecc6b62cc446@redhat.com/
>
> I don’t have a strong opinion here—it just feels a bit
> strange, since its description is quite generic for memcg:
>
> "Enable cgroup-based memory accounting for dma-buf heap
> allocations (default=false)."
>
> Best Regards
> Barry
>
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Geert Uytterhoeven @ 2026-05-19 9:43 UTC (permalink / raw)
To: David Laight
Cc: Ethan Nelson-Moore, linux-doc, devicetree, workflows, linux-arch,
dmaengine, linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260519094820.1f05ab8e@pumpkin>
Hi David,
On Tue, 19 May 2026 at 10:55, David Laight <david.laight.linux@gmail.com> wrote:
> The company I used to work for used 4 NIOS II inside an fpga.
> The instruction timing for one is pretty critical, it has some code that
> has to complete in 122 clocks (worst case).
> Our solution was to spend a few man-weeks writing a compatible cpu!
> I think it came out with fewer pipeline stalls (in particular it 'lost'
> the one for a (predicted) taken branch).
> The maximum clock frequency might be lower; but it is ok at 62.5MHz and the
> higher 125MHz in just impossible for all sorts of reasons.
>
> OTOH I really wouldn't run Linux on it!
Sounds similar to what CoreSemi is doing with J2 (nommu, also for
predictable latency), but their products do run Linux.
See the video from the LPC session at
https://lpc.events/event/19/contributions/2097/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Linaro-mm-sig] Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Maxime Ripard @ 2026-05-19 9:52 UTC (permalink / raw)
To: Boris Brezillon
Cc: Chia-I Wu, Liviu Dudau, Marcin Ślusarz, Ketil Johnsen,
David Airlie, Simona Vetter, Maarten Lankhorst, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <20260518091650.5a7a4f4a@fedora>
[-- Attachment #1: Type: text/plain, Size: 3983 bytes --]
Hi Boris,
On Mon, May 18, 2026 at 09:16:50AM +0200, Boris Brezillon wrote:
> On Wed, 13 May 2026 12:31:32 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > >
> > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > >
> > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > >
> > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > name is "" already?
> > > > > > >
> > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > This check prevents that.
> > > > > >
> > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > currently probe and boot the FW even though we never setup the
> > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > just retry the next time a group with the protected bit is created and
> > > > > > fail if we can find a protected heap?
> > > > >
> > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > process when we have a group with protected mode set.
> > > >
> > > > No, but we can force a full/slow reset and have that thing
> > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > which point the FW should start from a fresh state, and be able to
> > > > properly initialize the protected-related stuff if protected sections
> > > > are populated. Am I missing something?
> > >
> > > Right, we can do that. For some reason I keep associating the reset with the
> > > error handling and not with "normal" operations.
> > I kind of hope we end up with either
> >
> > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > the heap is missing, or
> > - panthor gets a dma-buf from userspace and does the full reset
> > - userspace also needs to provide a dma-buf for each protected
> > group for the suspend buffer
> >
> > than something in-between. The latter is more ad-hoc and basically
> > kicks the issue to the userspace.
>
> Indeed, the second option is more ad-hoc, but when you think about it,
> userspace has to have this knowledge, because it needs to know the
> dma-heap to use for buffer allocation that cross a device boundary
> anyway. Think about frames produced by a video decoder, and composited
> by the GPU into a protected scanout buffer that's passed to the KMS
> device. Why would the GPU driver be source of truth when it comes to
> choosing the heap to use to allocate protected buffers for the video
> decoder or those used for the display?
Just fyi, the trend is to go to devices listing the heaps userspace
should allocate from and/or using the heaps internally to allocate their
buffers, so that last part is where we're headed, and feels totally
reasonable to me.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH] docs: md: fix grammar in speed_limit description
From: MigMarGil @ 2026-05-19 9:56 UTC (permalink / raw)
To: corbet, skhan; +Cc: linux-doc, linux-kernel, MigMarGil
Replace 'This are' with 'These are' in the md sysfs speed limit
section to correct grammar and improve readability.
Signed-off-by: MigMarGil <miguel.martin.gil.uni@gmail.com>
---
Documentation/admin-guide/md.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst
index dc7eab191..003fd34f7 100644
--- a/Documentation/admin-guide/md.rst
+++ b/Documentation/admin-guide/md.rst
@@ -734,7 +734,7 @@ also have
They should be scaled by the bitmap_chunksize.
sync_speed_min, sync_speed_max
- This are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
+ These are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
however they only apply to the particular array.
If no value has been written to these, or if the word ``system``
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-05-19 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, rafael, bp, saket.dumbre, will, xueshuai,
mchehab, krzk+dt, dave, conor+dt, vishal.l.verma, jic23, corbet,
guohanjun, dave.jiang, catalin.marinas, lenb, tony.luck, skhan,
djbw, alison.schofield, ira.weiny, robh
Cc: devicetree, linux-acpi, linux-doc, Dmitry.Lamerov, linux-cxl,
Michael.Zhao2, acpica-devel, linux-kernel, linux-arm-kernel,
linux-edac
In-Reply-To: <d12b5738-ca14-40aa-930f-eddf3199818d@kernel.org>
On 19/05/2026 10:22, Krzysztof Kozlowski wrote:
> On 19/05/2026 11:02, Ahmed Tiba wrote:
>> On 19/05/2026 08:04, Krzysztof Kozlowski wrote:
>>> On 18/05/2026 13:57, Ahmed Tiba wrote:
>>>> Describe the DeviceTree node that exposes the Arm firmware-first
>>>> CPER provider and hook the file into MAINTAINERS so the
>>>> binding has an owner.
>>>>
>>>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
>>>
>>> Please implement previous comments.
>>
>> Could you please clarify which previous DT comments you still see
>> as unaddressed?
>>
>> My understanding was that I had addressed the earlier points on the YAML
>> description formatting, the `memory-region` description text, and the
>> example. If I missed a specific item beyond the one below, please point
>> me to it.
>
> You do not need other nodes for your device in the example. I asked why
> this is needed for the example, but there was no answer.
Understood. I wanted the example to show the full binding context,
including how the `memory-region` phandles point to the reserved memory,
but I see your point.
I will remove the `reserved-memory` node from the example and simplify
it to only the `arm,ras-cper` device node.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH net-next v3 02/14] libie: add PCI device initialization helpers to libie
From: Larysa Zaremba @ 2026-05-19 10:03 UTC (permalink / raw)
To: phasta, Bjorn Helgaas
Cc: Bjorn Helgaas, Tony Nguyen, davem, kuba, pabeni, edumazet,
andrew+netdev, netdev, Phani R Burra, przemyslaw.kitszel,
aleksander.lobakin, sridhar.samudrala, anjali.singhai,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, bhelgaas, linux-pci, Bharath R, Samuel Salin,
Aleksandr Loktionov
In-Reply-To: <7a477885c58709f287f6c1440fb7e31331227d10.camel@mailbox.org>
On Tue, May 19, 2026 at 10:20:27AM +0200, Philipp Stanner wrote:
> On Mon, 2026-05-18 at 16:54 -0500, Bjorn Helgaas wrote:
> > [+cc Philipp]
> >
> > On Fri, May 15, 2026 at 03:44:26PM -0700, Tony Nguyen wrote:
> > > From: Phani R Burra <phani.r.burra@intel.com>
> > >
> > > Add support functions for drivers to configure PCI functionality and access
> > > MMIO space.
> >
> > This looks kind of like what pcim_iomap_range() does, i.e., a way to
> > ioremap (BAR-idx, offset, size) pieces of PCI BARs. That sounds like
> > useful functionality.
I agree that pci_iomap_range() could simplify the implementation a little bit.
But libie_pci API is still needed for ixd and idpf.
I guess commit message lacks clarity. Apart from mapping separate ranges,
libie_pci also adds a list which is intended to be tranversed by a driver, e.g.
to pass certain IO mappings to the auxbus devices. Such list is also traversed
by the libie_pci_get_mmio_addr() helper. And there is also some input
validation, because ranges are received from a very customizable FW. So a lot of
driver-specific convenience stuff.
> >
> > Is there something Intel-specific or even ethernet-specific about
> > this? If devm_* and pcim_* don't do what you need, maybe they should
> > be extended or this could be made generic so any drivers could use it?
> >
> > This looks like a mix of managed (pcim_enable_device(),
> > pcim_request_region()), and unmanaged (ioremap(), iounmap()) things.
> > I haven't looked at how all this is used, but it's pretty easy to get
> > things wrong when mixing models.
> >
The mix of managed-unmanaged things is because of static and non-static regions.
Static regions do have a device lifetime. Dynamic are theoretically only valid
between hard resets (e.g. from idpf_vc_core_init() and idpf_vc_core_deinit), so
a nice thing to do in such case is to unmap them before the reset.
I settled on a "mixed" model, because this way libie_pci_init_dev() can befefit
from managed APIs, but region management part can stay much more flexible.
I do not think making this generic makes sense, it is rather tailored to the
requirements of idpf (data plane) + ixd (control plane) generation of intel
ethernet devices. I you have some examples that could use the same logic, I
could take a look.
For context:
Libie was generally created as a way to just reduce code duplication between
intel ethernet drivers. And we had a lot of code duplication. So this library is
mostly things that would be otherwise copy-pasted.
> > > +++ b/drivers/net/ethernet/intel/libie/pci.c
> > > @@ -0,0 +1,208 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/* Copyright (C) 2025 Intel Corporation */
> > > +
> > > +#include <linux/intel/libie/pci.h>
> > > +
> > > +/**
> > > + * libie_find_mmio_region - find MMIO region containing a range
> > > + * @mmio_list: list that contains MMIO region info
> > > + * @offset: range start offset
> > > + * @size: range size
> > > + * @bar_idx: BAR index containing the range to search
> > > + *
> > > + * Return: pointer to a MMIO region overlapping with the range in any way or
> > > + * NULL if no such region is mapped.
[...]
> > > +
> > > + if (offset + size > pci_resource_len(pdev, bar_idx))
> > > + return false;
> > > +
> > > + mr = libie_find_mmio_region(&mmio_info->mmio_list, offset, size,
> > > + bar_idx);
> > > + if (mr) {
> > > + pci_warn(pdev,
> > > + "Mapping of BAR%u (offset=%llu, size=%llu) intersecting region (offset=%llu, size=%llu) already exists\n",
> > > + bar_idx, (unsigned long long)mr->offset,
> > > + (unsigned long long)mr->size,
> > > + (unsigned long long)offset, (unsigned long long)size);
> > > + return mr->offset <= offset &&
> > > + mr->offset + mr->size >= offset + size;
> > > + }
> > > +
> > > + pa = pci_resource_start(pdev, bar_idx) + offset;
> > > + va = ioremap(pa, size);
>
> I agree with Bjorn, this certainly looks like something that can be
> covered by shared PCI infrastructure?
>
I terms of address calculation I agree that pci_iomap_range() could help shrink
the code a little bit.
> > > + if (!va) {
> > > + pci_err(pdev, "Failed to map BAR%u region\n", bar_idx);
> > > + return false;
> > > + }
> > > +
> > > + mr = kvzalloc_obj(*mr);
> > > + if (!mr) {
> > > + iounmap(va);
> > > + return false;
> > > + }
> > > +
> > > + mr->addr = va;
> > > + mr->offset = offset;
> > > + mr->size = size;
> > > + mr->bar_idx = bar_idx;
> > > +
> > > + list_add_tail(&mr->list, &mmio_info->mmio_list);
> > > +
> > > + return true;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(__libie_pci_map_mmio_region, "LIBIE_PCI");
> > > +
> > > +/**
> > > + * libie_pci_unmap_fltr_regs - unmap selected PCI device MMIO regions
> > > + * @mmio_info: contains list of MMIO regions to unmap
> > > + * @fltr: returns true, if region is to be unmapped
> > > + */
> > > +void libie_pci_unmap_fltr_regs(struct libie_mmio_info *mmio_info,
> > > + bool (*fltr)(struct libie_mmio_info *mmio_info,
> > > + struct libie_pci_mmio_region *reg))
> > > +{
> > > + struct libie_pci_mmio_region *mr, *tmp;
> > > +
> > > + list_for_each_entry_safe(mr, tmp, &mmio_info->mmio_list, list) {
> > > + if (!fltr(mmio_info, mr))
> > > + continue;
> > > + iounmap(mr->addr);
> > > + list_del(&mr->list);
> > > + kvfree(mr);
> > > + }
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(libie_pci_unmap_fltr_regs, "LIBIE_PCI");
> > > +
> > > +/**
> > > + * libie_pci_unmap_all_mmio_regions - unmap all PCI device MMIO regions
> > > + * @mmio_info: contains list of MMIO regions to unmap
> > > + */
> > > +void libie_pci_unmap_all_mmio_regions(struct libie_mmio_info *mmio_info)
> > > +{
> > > + struct libie_pci_mmio_region *mr, *tmp;
> > > +
> > > + list_for_each_entry_safe(mr, tmp, &mmio_info->mmio_list, list) {
> > > + iounmap(mr->addr);
> > > + list_del(&mr->list);
> > > + kvfree(mr);
> > > + }
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(libie_pci_unmap_all_mmio_regions, "LIBIE_PCI");
> > > +
> > > +/**
> > > + * libie_pci_init_dev - enable and reserve PCI regions of the device
> > > + * @pdev: PCI device information
> > > + *
> > > + * Return: %0 on success, -%errno on failure.
> > > + */
> > > +int libie_pci_init_dev(struct pci_dev *pdev)
> > > +{
> > > + int err;
> > > +
> > > + err = pcim_enable_device(pdev);
> > > + if (err)
> > > + return err;
> > > +
> > > + for (int bar = 0; bar < PCI_STD_NUM_BARS; bar++)
> > > + if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
> > > + err = pcim_request_region(pdev, bar, pci_name(pdev));
>
> So mappings are handled manually, and region requests automatically
> through devres?
>
> In case you can use (or add) a pcim_iomap_region() function for that,
> you would get consistent automatic devres management.
>
>
> Greetings,
> P.
>
> > > + if (err)
> > > + return err;
> > > + }
> > > +
> > > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> > > + if (err)
> > > + return err;
> > > +
> > > + pci_set_master(pdev);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_NS_GPL(libie_pci_init_dev, "LIBIE_PCI");
> > > +
> > > +MODULE_DESCRIPTION("Common Ethernet PCI library");
> > > +MODULE_LICENSE("GPL");
> > > diff --git a/include/linux/intel/libie/pci.h b/include/linux/intel/libie/pci.h
> > > new file mode 100644
> > > index 000000000000..effd072c55c8
> > > --- /dev/null
> > > +++ b/include/linux/intel/libie/pci.h
> > > @@ -0,0 +1,56 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > +/* Copyright (C) 2025 Intel Corporation */
> > > +
> > > +#ifndef __LIBIE_PCI_H
> > > +#define __LIBIE_PCI_H
> > > +
> > > +#include <linux/pci.h>
> > > +
> > > +/**
> > > + * struct libie_pci_mmio_region - structure for MMIO region info
> > > + * @list: used to add a MMIO region to the list of MMIO regions in
> > > + * libie_mmio_info
> > > + * @addr: virtual address of MMIO region start
> > > + * @offset: start offset of the MMIO region
> > > + * @size: size of the MMIO region
> > > + * @bar_idx: BAR index to which the MMIO region belongs to
> > > + */
> > > +struct libie_pci_mmio_region {
> > > + struct list_head list;
> > > + void __iomem *addr;
> > > + resource_size_t offset;
> > > + resource_size_t size;
> > > + u16 bar_idx;
> > > +};
> > > +
> > > +/**
> > > + * struct libie_mmio_info - contains list of MMIO regions
> > > + * @pdev: PCI device pointer
> > > + * @mmio_list: list of MMIO regions
> > > + */
> > > +struct libie_mmio_info {
> > > + struct pci_dev *pdev;
> > > + struct list_head mmio_list;
> > > +};
> > > +
> > > +#define libie_pci_map_mmio_region(mmio_info, offset, size, ...) \
> > > + __libie_pci_map_mmio_region(mmio_info, offset, size, \
> > > + COUNT_ARGS(__VA_ARGS__), ##__VA_ARGS__)
> > > +
> > > +#define libie_pci_get_mmio_addr(mmio_info, offset, ...) \
> > > + __libie_pci_get_mmio_addr(mmio_info, offset, \
> > > + COUNT_ARGS(__VA_ARGS__), ##__VA_ARGS__)
> > > +
> > > +bool __libie_pci_map_mmio_region(struct libie_mmio_info *mmio_info,
> > > + resource_size_t offset, resource_size_t size,
> > > + int num_args, ...);
> > > +void __iomem *__libie_pci_get_mmio_addr(struct libie_mmio_info *mmio_info,
> > > + resource_size_t offset,
> > > + int num_args, ...);
> > > +void libie_pci_unmap_all_mmio_regions(struct libie_mmio_info *mmio_info);
> > > +void libie_pci_unmap_fltr_regs(struct libie_mmio_info *mmio_info,
> > > + bool (*fltr)(struct libie_mmio_info *mmio_info,
> > > + struct libie_pci_mmio_region *reg));
> > > +int libie_pci_init_dev(struct pci_dev *pdev);
> > > +
> > > +#endif /* __LIBIE_PCI_H */
> > > --
> > > 2.47.1
> > >
>
^ permalink raw reply
* [agd5f:drm-next 36/58] htmldocs: Documentation/gpu/amdgpu/display/display-manager:50: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c:420: WARNING: Error in declarator or parameters
From: kernel test robot @ 2026-05-19 10:10 UTC (permalink / raw)
To: Alex Hung
Cc: oe-kbuild-all, Alex Deucher, Harry Wentland, Ivan Lipski,
linux-doc
tree: https://gitlab.freedesktop.org/agd5f/linux.git drm-next
head: 99cbcb3453b7d19cab507db9313ada9a38e82d01
commit: 82ffa89fa2803f9288163f538151a45581a88ca2 [36/58] drm/amd/display: Add KUnit test for color helpers
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260519/202605191223.ct8ZUEYU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605191223.ct8ZUEYU-lkp@intel.com/
All warnings (new ones prefixed by >>):
AMD plane color pipeline
------------------------ [docutils]
>> Documentation/gpu/amdgpu/display/display-manager:50: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c:420: WARNING: Error in declarator or parameters
Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 29]
STATIC_IFN_KUNIT const struct drm_color_lut * __extract_blob_lut (const struct drm_property_blob *blob, uint32_t *size)
-----------------------------^
Documentation/gpu/amdgpu/display/display-manager:50: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c:437: WARNING: Error in declarator or parameters
Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 29]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-19 10:30 UTC (permalink / raw)
To: Ethan Nelson-Moore, Wolfram Sang
Cc: Peter Zijlstra, Arnd Bergmann, Dinh Nguyen, linux-doc, devicetree,
workflows, Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev,
linux-pci, linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <CADkSEUjhq6HSdg4ignzbuJiN5uXATsTdxFbRJ3BMxs5=WUWLDg@mail.gmail.com>
Hi Ethan, hi Wolfram,
Thank you for your thoughtful responses.
On Mon, May 18, 2026 at 05:13:58PM -0700, Ethan Nelson-Moore wrote:
> Your reasoning makes complete sense. However, there is an alternative
> to maintaining the architecture in mainline.
>
> The Civil Infrastructure Platform project maintains super-LTS kernels
> (and a set of base Debian packages) for 10 years. They are intended to
> be used for exactly these kinds of devices.
> See here: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership
> and here: https://cip-project.org/about/linux-kernel-core-packages
>
> CIP will maintain kernel 6.12 until 2035. Is this long enough for your
> lifecycle? What kernel are you currently using? If it's newer than
> 6.12, we can easily wait until the next CIP SLTS release to remove
> Nios II support to avoid a downgrade.
This depends. For released/maintained firmware revisions we already
track CIP SLTS versions (candidates) to be prepared, the majority of which
is currently still running 6.1.x with 6.12.x up-and-coming.
But for the reasons outlined by you regarding architectural and feature
support in CIP SLTS, we do not, however, use the extended support duration
SLTS releases in production, and instead upgrade with the kernel.org LTS
branch release schedule and track these internally alongside mainline
to prevent major obstacles during version jumps.
2035 is still a rather tight timeframe for our typical support/phase-out
period (we would hope to get close to 2040 with the SLTS extensions),
which is also the reason for our targeted 'lifetime extension' for the
nios2 architecture for approximately 5 years, or more precisely ~2-3
SLTS kernels assuming the usual cadence of 2 years between SLTS versions
(+ some safety margin).
> Also, CIP focuses on architectures used by CIP members - currently I
> think they are x86 (32 and 64-bit), ARM (32 and 64-bit) and RISC-V.
> Since Siemens is already a CIP member, you can simply ask them to add
> Nios II to the list, and you can assist them with testing and directly
> submit patches to them once the standard 6.12 LTS period ends.
We have already been in contact with the CIP team (even though the
contact has unfortunately lapsed a bit, mostly our fault), but adding an
additional architecture seemed to be a more substantial effort.
N.B.: Due to past circumstances, we are a completely distinct business
entity from Siemens AG that merely shares the trademark and a common
history; but of course this should not hinder us from getting directly
involved in CIP (quite the opposite!). But this also requires some setup
time.
On Mon, May 18, 2026 at 10:46:55PM +0200, Wolfram Sang wrote:
> > If desired, we also would be happy to intensify our support regarding
> > reviews or testing to share the maintnance burden if it helps to keep
> > nios2 in mainline a bit longer.
>
> ... but given this, you might want to get added in MAINTAINERS as
> reviewer (or even maintainer) for nios2? Besides that your efforts are
> already worth it in my book, it would also ensure you get CCed on
> patches like this. Then, you are not depending on people like Arnd
> putting you in the loop manually.
Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
unsure about the netiquette (can I simply do so by self-proclamation? At
least the git history seems to suggest so...).
Best regards,
Simon
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 10:41 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marc Zyngier, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <CABgObfaM-JtNn2MuYXaiadQnLfAhTEaoHAcTG9=J6LkMcQCJ3A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote:
>
> > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a
> > new guest-visible feature in revision 3, but allowed userspace to
> > restore the old behaviour by setting it to revision 2. All my patch
> > above does, is make it possible to set it to revision 1 as
> > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously
> > changed the behaviour and bumped the default to 2 *without* allowing
> > userspace to restore the prior behaviour, and we've been carrying a
> > *revert* of that patch.
> >
> > Why would we *not* accept such a patch?
>
> Agreed. Even ignoring your revert, there's no reason why any upgrade
> past 49a1a2c70a7f has to be from after d53c2c29ae0d.
So where do we go from here?
I assume you'll be taking this Documentation patch via the KVM tree?
But what about the actual fix at
https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
This is a simple and unintrusive bug fix to make KVM/arm64 follow the
"common sense" requirement that the doc patch codifies, apparently
being rejected with the rather bizarre claim that KVM has no *need* to
maintain guest-visible compatibility across host kernel changes.
So... what next? Is one of the other KVM/arm64 maintainers going to
speak up? Paolo would you consider taking the fixes through your tree
directly?
Does Arm not actually *care* whether AArch64 is considered a stable and
mature platform for KVM hosting?
We don't have CONFIG_EXPERIMENTAL any more, do we? Or perhaps we could
mark it such. Is CONFIG_STAGING the right thing, for unstable things
which might violate the normal maturity expectations of the kernel?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Wolfram Sang @ 2026-05-19 10:55 UTC (permalink / raw)
To: Simon Schuster
Cc: Ethan Nelson-Moore, Peter Zijlstra, Arnd Bergmann, Dinh Nguyen,
linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster>
Hi Simon,
> > ... but given this, you might want to get added in MAINTAINERS as
> > reviewer (or even maintainer) for nios2? Besides that your efforts are
> > already worth it in my book, it would also ensure you get CCed on
> > patches like this. Then, you are not depending on people like Arnd
> > putting you in the loop manually.
>
> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> unsure about the netiquette (can I simply do so by self-proclamation? At
> least the git history seems to suggest so...).
In your case, you can do so, I'd say. You explained your very reasonable
interest in the architecture and have already shown efforts to keep it,
as we can see from the git history. The final call will be done by Dinh
Nguyen obviously with whom you probably need to sort out details. But I
can't imagine your offer for help will be rejected, quite the contrary.
Happy hacking,
Wolfram
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Miguel Ojeda @ 2026-05-19 11:07 UTC (permalink / raw)
To: Simon Schuster
Cc: Ethan Nelson-Moore, Wolfram Sang, Peter Zijlstra, Arnd Bergmann,
Dinh Nguyen, linux-doc, devicetree, workflows, Linux-Arch,
dmaengine, linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster>
On Tue, May 19, 2026 at 12:41 PM Simon Schuster
<schuster.simon@siemens-energy.com> wrote:
>
> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> unsure about the netiquette (can I simply do so by self-proclamation? At
> least the git history seems to suggest so...).
Up to the existing maintainer, in general.
I would also suggest changing the support level to "Supported",
instead of "Maintained" -- that would help justify keeping it in
mainline.
I hope that helps a bit...
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] docs: fix typo in uniwill-laptop.rst
From: Ilpo Järvinen @ 2026-05-19 11:09 UTC (permalink / raw)
To: Sakurai Shun
Cc: Armin Wolf, Jonathan Corbet, Shuah Khan, platform-driver-x86,
linux-doc, linux-kernel
In-Reply-To: <20260517024148.9642-1-ssh1326@icloud.com>
On Sun, 17 May 2026, Sakurai Shun wrote:
> Replace "benifit" with "benefit".
>
> Signed-off-by: Sakurai Shun <ssh1326@icloud.com>
Thanks for the patch.
When sending an update, you should collect the tags from the earlier
version.
No need to send another version because of it, I've added Armin's
Reviewed-by while applying to review-ilpo-next (it will appear there later
once I push the local changes into the public repo).
--
i.
> ---
> Documentation/wmi/devices/uniwill-laptop.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/wmi/devices/uniwill-laptop.rst b/Documentation/wmi/devices/uniwill-laptop.rst
> index e246bf293..65583b239 100644
> --- a/Documentation/wmi/devices/uniwill-laptop.rst
> +++ b/Documentation/wmi/devices/uniwill-laptop.rst
> @@ -189,7 +189,7 @@ Indexed IO
>
> Indexed IO with IO ports with a granularity of a single byte can be performed using the ``RIOP``
> (read) and ``WIOP`` (write) ACPI control methods. Those ACPI methods are unused because they
> -provide no benifit when compared to the native IO port access functions provided by the kernel.
> +provide no benefit when compared to the native IO port access functions provided by the kernel.
>
> Special thanks go to github user `pobrn` which developed the
> `qc71_laptop <https://github.com/pobrn/qc71_laptop>`_ driver on which this driver is partly based.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox