* [PATCH v12 24/25] drm/bridge: Document bridge chain format selection
From: Nicolas Frattaroli @ 2026-04-09 15:45 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260409-color-format-v12-0-ce84e1817a27@collabora.com>
The bridge chain format selection behaviour was, until now,
undocumented. With the addition of the "color format" DRM property, it's
not sufficiently complex enough that documentation is warranted,
especially for driver authors trying to do the right thing.
Add a high-level overview of how the process is supposed to work, and
mention what the display driver is supposed to do if it wants to make
use of this functionality.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/gpu/drm-kms-helpers.rst | 6 ++++++
drivers/gpu/drm/drm_bridge.c | 40 +++++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index b4a9e5ae81f6..bf5a9d909cf3 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -169,6 +169,12 @@ Bridge Operations
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: bridge operations
+Bridge Chain Format Selection
+-----------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+ :doc: bridge chain format selection
+
Bridge Connector Helper
-----------------------
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 7c1516864d96..5cc7d281ef7f 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -198,6 +198,46 @@
* driver.
*/
+/**
+ * DOC: bridge chain format selection
+ *
+ * A bridge chain, from display output processor to connector, may contain
+ * bridges capable of converting between bus formats on their inputs, and
+ * output formats on their outputs. For example, a bridge may be able to convert
+ * from RGB to YCbCr 4:4:4, and pass through YCbCr 4:2:0 as-is, but not convert
+ * from RGB to YCbCr 4:2:0. This means not all input formats map to all output
+ * formats.
+ *
+ * Further adding to this, a desired output color format, as specified with the
+ * "color format" DRM property, might not correspond 1:1 to what the display
+ * driver should set at its output. The bridge chain it feeds into may only be
+ * able to reach the desired output format, if a conversion from a different
+ * starting format is performed.
+ *
+ * To deal with this complexity, the recursive bridge chain bus format selection
+ * logic starts with the last bridge in the chain, usually the connector, and
+ * then recursively walks the chain of bridges backwards to the first bridge,
+ * trying to find a path.
+ *
+ * For a display driver to work in such a scenario, it should read the first
+ * bridge's bridge state to figure out which bus format the chain resolved to.
+ * If the first bridge's input format resolved to %MEDIA_BUS_FMT_FIXED, then its
+ * output format should be used.
+ *
+ * Special handling is done for HDMI as it relates to format selection. Instead
+ * of directly using the "color format" DRM property for bridge chains that end
+ * in HDMI bridges, the bridge chain format selection logic will trust the logic
+ * that set the HDMI output format. For the common HDMI state helper
+ * functionality, this means that %DRM_CONNECTOR_COLOR_FORMAT_AUTO will allow
+ * fallbacks to YCBCr 4:2:0 if the bandwidth requirements would otherwise be too
+ * high but the mode and connector allow it.
+ *
+ * For bridge chains that do not end in an HDMI bridge,
+ * %DRM_CONNECTOR_COLOR_FORMAT_AUTO will be satisfied with the first output
+ * format on the last bridge for which it can find a path back to the first
+ * bridge.
+ */
+
/* Protect bridge_list and bridge_lingering_list */
static DEFINE_MUTEX(bridge_lock);
static LIST_HEAD(bridge_list);
--
2.53.0
^ permalink raw reply related
* [PATCH v12 25/25] drm/connector: Update docs of "colorspace" for color format prop
From: Nicolas Frattaroli @ 2026-04-09 15:45 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260409-color-format-v12-0-ce84e1817a27@collabora.com>
The colorspace property's documentation states that BT2020_RGB and
BT2020_YCC are equivalent, and the output format depends on the driver.
Now that there is a "color format" property that userspace can use to
explicitly set a format, update the colorspace docs to mention this.
The behaviour here is not changed for userspace that doesn't know about
the color format property yet, as the color format property defaults to
"AUTO", where the choice of output format is left up to drivers.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0da136a93dd6..71c58fa15aa0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2573,7 +2573,8 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* conversion matrix and convert to the appropriate quantization
* range.
* The variants BT2020_RGB and BT2020_YCC are equivalent and the
- * driver chooses between RGB and YCbCr on its own.
+ * driver chooses between RGB and YCbCr based on the color format
+ * property.
*
* SMPTE_170M_YCC:
* BT709_YCC:
--
2.53.0
^ permalink raw reply related
* [PATCH v12 21/25] drm/tests: hdmi: Add tests for HDMI helper's mode_valid
From: Nicolas Frattaroli @ 2026-04-09 15:45 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260409-color-format-v12-0-ce84e1817a27@collabora.com>
Add some KUnit tests to verify that the HDMI state helper's mode_valid
implementation does not improperly reject chroma subsampled modes on the
basis of their clock rate not being satisfiable in RGB.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 109 +++++++++++++++++++++
1 file changed, 109 insertions(+)
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 3444c93c615f..74c9933eabfc 100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -77,6 +77,23 @@ static struct drm_display_mode *find_420_only_mode(struct drm_connector *connect
return NULL;
}
+static struct drm_display_mode *find_420_also_mode(struct drm_connector *connector)
+{
+ struct drm_device *drm = connector->dev;
+ struct drm_display_mode *mode;
+
+ mutex_lock(&drm->mode_config.mutex);
+ list_for_each_entry(mode, &connector->modes, head) {
+ if (drm_mode_is_420_also(&connector->display_info, mode)) {
+ mutex_unlock(&drm->mode_config.mutex);
+ return mode;
+ }
+ }
+ mutex_unlock(&drm->mode_config.mutex);
+
+ return NULL;
+}
+
static int set_connector_edid(struct kunit *test, struct drm_connector *connector,
const void *edid, size_t edid_len)
{
@@ -2745,11 +2762,103 @@ static void drm_test_check_mode_valid_reject_max_clock(struct kunit *test)
KUNIT_EXPECT_EQ(test, preferred->clock, 25200);
}
+/*
+ * Test that drm_hdmi_connector_mode_valid() will accept modes that require a
+ * 4:2:0 chroma subsampling, even if said mode would violate maximum clock
+ * constraints if it used RGB 4:4:4.
+ */
+static void drm_test_check_mode_valid_yuv420_only_max_clock(struct kunit *test)
+{
+ struct drm_atomic_helper_connector_hdmi_priv *priv;
+ struct drm_display_mode *dank;
+ struct drm_connector *conn;
+
+ priv = drm_kunit_helper_connector_hdmi_init_with_edid_funcs(test,
+ BIT(HDMI_COLORSPACE_RGB) |
+ BIT(HDMI_COLORSPACE_YUV420),
+ 8,
+ &dummy_connector_hdmi_funcs,
+ test_edid_hdmi_1080p_rgb_yuv_4k_yuv420_dc_max_200mhz);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ conn = &priv->connector;
+ KUNIT_ASSERT_EQ(test, conn->display_info.max_tmds_clock, 200 * 1000);
+
+ dank = find_420_only_mode(conn);
+ KUNIT_ASSERT_NOT_NULL(test, dank);
+ KUNIT_EXPECT_EQ(test, dank->hdisplay, 3840);
+ KUNIT_EXPECT_EQ(test, dank->vdisplay, 2160);
+
+ /*
+ * Note: The mode's "clock" here is not accurate to the actual TMDS
+ * clock that HDMI will use for a subsampled mode. Hence, why the mode's
+ * clock is above the .max_tmds_clock of 200MHz.
+ */
+ KUNIT_EXPECT_EQ(test, dank->clock, 297000);
+}
+
+/*
+ * Test that drm_hdmi_connector_mode_valid() will reject modes that require
+ * 4:2:0 chroma subsampling, if the connector does not support 4:2:0.
+ */
+static void
+drm_test_check_mode_valid_reject_yuv420_only_connector(struct kunit *test)
+{
+ struct drm_atomic_helper_connector_hdmi_priv *priv;
+ struct drm_display_mode *dank;
+ struct drm_connector *conn;
+
+ priv = drm_kunit_helper_connector_hdmi_init_with_edid_funcs(test,
+ BIT(HDMI_COLORSPACE_RGB),
+ 8,
+ &dummy_connector_hdmi_funcs,
+ test_edid_hdmi_1080p_rgb_yuv_4k_yuv420_dc_max_200mhz);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ conn = &priv->connector;
+ KUNIT_ASSERT_EQ(test, conn->display_info.max_tmds_clock, 200 * 1000);
+
+ dank = find_420_only_mode(conn);
+ KUNIT_EXPECT_NULL(test, dank);
+}
+
+/*
+ * Test that drm_hdmi_connector_mode_valid() will accept modes that allow (among
+ * other color formats) 4:2:0 chroma subsampling, even if the connector does not
+ * support 4:2:0, but the mode's clock works for RGB 4:4:4.
+ */
+static void
+drm_test_check_mode_valid_accept_yuv420_also_connector_rgb(struct kunit *test)
+{
+ struct drm_atomic_helper_connector_hdmi_priv *priv;
+ struct drm_display_mode *mode;
+ struct drm_connector *conn;
+
+ priv = drm_kunit_helper_connector_hdmi_init_with_edid_funcs(test,
+ BIT(HDMI_COLORSPACE_RGB),
+ 8,
+ &dummy_connector_hdmi_funcs,
+ test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ conn = &priv->connector;
+ KUNIT_ASSERT_EQ(test, conn->display_info.max_tmds_clock, 340 * 1000);
+
+ mode = find_420_also_mode(conn);
+ KUNIT_ASSERT_NOT_NULL(test, mode);
+ KUNIT_EXPECT_EQ(test, mode->hdisplay, 3840);
+ KUNIT_EXPECT_EQ(test, mode->vdisplay, 2160);
+ KUNIT_EXPECT_EQ(test, mode->clock, 297000);
+}
+
static struct kunit_case drm_atomic_helper_connector_hdmi_mode_valid_tests[] = {
KUNIT_CASE(drm_test_check_mode_valid),
KUNIT_CASE(drm_test_check_mode_valid_reject),
KUNIT_CASE(drm_test_check_mode_valid_reject_rate),
KUNIT_CASE(drm_test_check_mode_valid_reject_max_clock),
+ KUNIT_CASE(drm_test_check_mode_valid_yuv420_only_max_clock),
+ KUNIT_CASE(drm_test_check_mode_valid_reject_yuv420_only_connector),
+ KUNIT_CASE(drm_test_check_mode_valid_accept_yuv420_also_connector_rgb),
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v12 23/25] drm/tests: bridge: Add test for HDMI output bus formats helper
From: Nicolas Frattaroli @ 2026-04-09 15:45 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260409-color-format-v12-0-ce84e1817a27@collabora.com>
The common atomic_get_output_bus_fmts helper for HDMI bridge connectors,
called drm_atomic_helper_bridge_get_hdmi_output_bus_fmts, should return
an array of output bus formats depending on the supported formats of the
connector, and the current output BPC.
Add a test to exercise some of this helper.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/tests/drm_bridge_test.c | 184 ++++++++++++++++++++++++++++++++
1 file changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_bridge_test.c b/drivers/gpu/drm/tests/drm_bridge_test.c
index cb821c606070..d9bd930b1197 100644
--- a/drivers/gpu/drm/tests/drm_bridge_test.c
+++ b/drivers/gpu/drm/tests/drm_bridge_test.c
@@ -5,6 +5,7 @@
#include <linux/cleanup.h>
#include <linux/media-bus-format.h>
+#include <drm/drm_atomic_helper.h>
#include <drm/drm_atomic_state_helper.h>
#include <drm/drm_atomic_uapi.h>
#include <drm/drm_bridge.h>
@@ -118,6 +119,28 @@ static const struct drm_bridge_funcs drm_test_bridge_atomic_funcs = {
.atomic_reset = drm_atomic_helper_bridge_reset,
};
+static int dummy_clear_infoframe(struct drm_bridge *bridge)
+{
+ return 0;
+}
+
+static int dummy_write_infoframe(struct drm_bridge *bridge, const u8 *buffer,
+ size_t len)
+{
+ return 0;
+}
+
+static const struct drm_bridge_funcs drm_test_bridge_bus_fmts_funcs = {
+ .atomic_get_output_bus_fmts = drm_atomic_helper_bridge_get_hdmi_output_bus_fmts,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .hdmi_write_avi_infoframe = dummy_write_infoframe,
+ .hdmi_write_hdmi_infoframe = dummy_write_infoframe,
+ .hdmi_clear_avi_infoframe = dummy_clear_infoframe,
+ .hdmi_clear_hdmi_infoframe = dummy_clear_infoframe,
+};
+
/**
* struct fmt_tuple - a tuple of input/output MEDIA_BUS_FMT_*
*/
@@ -539,6 +562,83 @@ drm_test_bridge_chain_init(struct kunit *test, unsigned int num_bridges,
return priv;
}
+static struct drm_bridge_init_priv *
+drm_test_bridge_hdmi_init(struct kunit *test, const struct drm_bridge_funcs *funcs,
+ unsigned int supported_formats, int max_bpc)
+{
+ struct drm_bridge_init_priv *priv;
+ struct drm_encoder *enc;
+ struct drm_bridge *bridge;
+ struct drm_device *drm;
+ struct device *dev;
+ int ret;
+
+ dev = drm_kunit_helper_alloc_device(test);
+ if (IS_ERR(dev))
+ return ERR_CAST(dev);
+
+ priv = drm_kunit_helper_alloc_drm_device(test, dev,
+ struct drm_bridge_init_priv, drm,
+ DRIVER_MODESET | DRIVER_ATOMIC);
+ if (IS_ERR(priv))
+ return ERR_CAST(priv);
+
+ priv->test_bridge = devm_drm_bridge_alloc(dev, struct drm_bridge_priv, bridge, funcs);
+ if (IS_ERR(priv->test_bridge))
+ return ERR_CAST(priv->test_bridge);
+
+ priv->test_bridge->data = priv;
+
+ drm = &priv->drm;
+ priv->plane = drm_kunit_helper_create_primary_plane(test, drm,
+ NULL,
+ NULL,
+ NULL, 0,
+ NULL);
+ if (IS_ERR(priv->plane))
+ return ERR_CAST(priv->plane);
+
+ priv->crtc = drm_kunit_helper_create_crtc(test, drm,
+ priv->plane, NULL,
+ NULL,
+ NULL);
+ if (IS_ERR(priv->crtc))
+ return ERR_CAST(priv->crtc);
+
+ enc = &priv->encoder;
+ ret = drmm_encoder_init(drm, enc, NULL, DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret)
+ return ERR_PTR(ret);
+
+ enc->possible_crtcs = drm_crtc_mask(priv->crtc);
+
+ bridge = &priv->test_bridge->bridge;
+ bridge->type = DRM_MODE_CONNECTOR_HDMIA;
+ bridge->supported_formats = supported_formats;
+ bridge->max_bpc = max_bpc;
+ bridge->ops |= DRM_BRIDGE_OP_HDMI;
+ bridge->vendor = "LNX";
+ bridge->product = "KUnit";
+
+ ret = drm_kunit_bridge_add(test, bridge);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = drm_bridge_attach(enc, bridge, NULL, 0);
+ if (ret)
+ return ERR_PTR(ret);
+
+ priv->connector = drm_bridge_connector_init(drm, enc);
+ if (IS_ERR(priv->connector))
+ return ERR_CAST(priv->connector);
+
+ drm_connector_attach_encoder(priv->connector, enc);
+
+ drm_mode_config_reset(drm);
+
+ return priv;
+}
+
/*
* Test that drm_bridge_get_current_state() returns the last committed
* state for an atomic bridge.
@@ -786,10 +886,94 @@ static void drm_test_drm_bridge_helper_reset_crtc_legacy(struct kunit *test)
KUNIT_EXPECT_EQ(test, bridge_priv->disable_count, 1);
}
+/*
+ * Test that a bridge using the drm_atomic_helper_bridge_get_hdmi_output_bus_fmts()
+ * function for &drm_bridge_funcs.atomic_get_output_bus_fmts behaves as expected
+ * for an HDMI connector bridge. Does so by creating an HDMI bridge connector
+ * with RGB444, YCBCR444, and YCBCR420 (but not YCBCR422) as supported formats,
+ * sets the output depth to 8 bits per component, and then validates the returned
+ * list of bus formats.
+ */
+static void drm_test_drm_bridge_helper_hdmi_output_bus_fmts(struct kunit *test)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_bridge_state *bridge_state;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_bridge_init_priv *priv;
+ struct drm_crtc_state *crtc_state;
+ struct drm_atomic_state *state;
+ struct drm_display_mode *mode;
+ unsigned int num_output_fmts;
+ struct drm_bridge *bridge;
+ u32 *out_bus_fmts;
+ int ret;
+
+ priv = drm_test_bridge_hdmi_init(test, &drm_test_bridge_bus_fmts_funcs,
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420),
+ 12);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+
+ bridge = &priv->test_bridge->bridge;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+ state = drm_kunit_helper_atomic_state_alloc(test, &priv->drm, &ctx);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, state);
+
+retry_commit:
+ conn_state = drm_atomic_get_connector_state(state, priv->connector);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, conn_state);
+
+ conn_state->hdmi.output_bpc = 8;
+
+ mode = drm_kunit_display_mode_from_cea_vic(test, &priv->drm, 16);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, mode);
+
+ ret = drm_atomic_set_crtc_for_connector(conn_state, priv->crtc);
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(&ctx);
+ goto retry_commit;
+ }
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ crtc_state = drm_atomic_get_crtc_state(state, priv->crtc);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, crtc_state);
+
+ ret = drm_atomic_set_mode_for_crtc(crtc_state, mode);
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(&ctx);
+ goto retry_commit;
+ }
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ crtc_state->enable = true;
+ crtc_state->active = true;
+
+ bridge_state = drm_atomic_get_bridge_state(state, bridge);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, bridge_state);
+
+ out_bus_fmts = bridge->funcs->atomic_get_output_bus_fmts(
+ bridge, bridge_state, crtc_state, conn_state, &num_output_fmts);
+ KUNIT_EXPECT_NOT_NULL(test, out_bus_fmts);
+ KUNIT_EXPECT_EQ(test, num_output_fmts, 3);
+
+ KUNIT_EXPECT_EQ(test, out_bus_fmts[0], MEDIA_BUS_FMT_RGB888_1X24);
+ KUNIT_EXPECT_EQ(test, out_bus_fmts[1], MEDIA_BUS_FMT_YUV8_1X24);
+ KUNIT_EXPECT_EQ(test, out_bus_fmts[2], MEDIA_BUS_FMT_UYYVYY8_0_5X24);
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
+ kfree(out_bus_fmts);
+}
+
static struct kunit_case drm_bridge_helper_reset_crtc_tests[] = {
KUNIT_CASE(drm_test_drm_bridge_helper_reset_crtc_atomic),
KUNIT_CASE(drm_test_drm_bridge_helper_reset_crtc_atomic_disabled),
KUNIT_CASE(drm_test_drm_bridge_helper_reset_crtc_legacy),
+ KUNIT_CASE(drm_test_drm_bridge_helper_hdmi_output_bus_fmts),
{ }
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] tracing: Documentation: Update histogram-design.rst for fn() handling
From: Steven Rostedt @ 2026-04-09 15:52 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, LKML, Linux Trace Kernel, Masami Hiramatsu,
Mathieu Desnoyers, Tom Zanussi
In-Reply-To: <87bjfsb37x.fsf@trenco.lwn.net>
On Thu, 09 Apr 2026 08:47:14 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
>
> > Hi Jon,
> >
> > Can you take this through your tree?
>
> Somehow it fell through a crack in my inbox, but I have, finally, done
> that. Sorry for the delay.
Thanks, it has happened to me too often but not as much when I started
using patchwork. Is there a patchwork monitoring linux-doc? If not, I
highly recommend it. I stopped missing almost all patches when I started
managing patches with patchwork. The few times I missed patches was when I
accidentally incorrectly changed the status of a patch. But that's usually
due to my own negligence and not simply because it was lost in my INBOX.
-- Steve
^ permalink raw reply
* Re: [PATCH v7 1/6] dt-bindings: iio: adc: add AD4691 family
From: Conor Dooley @ 2026-04-09 15:57 UTC (permalink / raw)
To: radu.sabau
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan, linux-iio, devicetree,
linux-kernel, linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260409-ad4692-multichannel-sar-adc-driver-v7-1-be375d4df2c5@analog.com>
[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]
On Thu, Apr 09, 2026 at 06:28:22PM +0300, Radu Sabau via B4 Relay wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add DT bindings for the Analog Devices AD4691 family of multichannel
> SAR ADCs (AD4691, AD4692, AD4693, AD4694).
>
> The binding describes the hardware connections:
>
> - Power domains: avdd-supply (required), vio-supply, ref-supply or
> refin-supply (external reference; the REFIN path enables the
> internal reference buffer), and an optional ldo-in-supply, that if
> absent, means the on-chip internal LDO will be used.
>
> - Optional PWM on the CNV pin selects CNV Burst Mode; when absent,
> Manual Mode is assumed with CNV tied to SPI CS.
>
> - An optional reset GPIO (reset-gpios) for hardware reset.
>
> - Up to four GP pins (gp0..gp3) usable as interrupt sources,
> identified in firmware via interrupt-names "gp0".."gp3".
>
> - gpio-controller with #gpio-cells = <2> for GP pin GPIO usage.
>
> - #trigger-source-cells = <1>: one cell selecting the GP pin number
> (0-3) used as the SPI offload trigger source.
>
> Two binding examples are provided: CNV Burst Mode with SPI offload
> (DMA data acquisition driven by DATA_READY on a GP pin), and Manual
> Mode for CPU-driven triggered-buffer or single-shot capture.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> ---
> .../devicetree/bindings/iio/adc/adi,ad4691.yaml | 162 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 169 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4691.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4691.yaml
> new file mode 100644
> index 000000000000..81d2ca4e0e22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4691.yaml
> @@ -0,0 +1,162 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad4691.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices AD4691 Family Multichannel SAR ADCs
> +
> +maintainers:
> + - Radu Sabau <radu.sabau@analog.com>
> +
> +description: |
> + The AD4691 family are high-speed, low-power, multichannel successive
> + approximation register (SAR) analog-to-digital converters (ADCs) with
> + an SPI-compatible serial interface. The ADC supports CNV Burst Mode,
> + where an external PWM drives the CNV pin, and Manual Mode, where CNV
> + is directly tied to the SPI chip-select.
> +
> + Datasheets:
> + * https://www.analog.com/en/products/ad4691.html
> + * https://www.analog.com/en/products/ad4692.html
> + * https://www.analog.com/en/products/ad4693.html
> + * https://www.analog.com/en/products/ad4694.html
> +
> +$ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - adi,ad4691
> + - adi,ad4692
> + - adi,ad4693
> + - adi,ad4694
Please add a note to the commit message about why these devices are not
compatible. With that,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] tracing: Documentation: Update histogram-design.rst for fn() handling
From: Jonathan Corbet @ 2026-04-09 15:59 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-doc, LKML, Linux Trace Kernel, Masami Hiramatsu,
Mathieu Desnoyers, Tom Zanussi
In-Reply-To: <20260409115200.45883a07@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Thu, 09 Apr 2026 08:47:14 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
>> Steven Rostedt <rostedt@goodmis.org> writes:
>>
>> > Hi Jon,
>> >
>> > Can you take this through your tree?
>>
>> Somehow it fell through a crack in my inbox, but I have, finally, done
>> that. Sorry for the delay.
>
> Thanks, it has happened to me too often but not as much when I started
> using patchwork. Is there a patchwork monitoring linux-doc? If not, I
> highly recommend it. I stopped missing almost all patches when I started
> managing patches with patchwork. The few times I missed patches was when I
> accidentally incorrectly changed the status of a patch. But that's usually
> due to my own negligence and not simply because it was lost in my INBOX.
No patchwork ... but there is a *massive* pile of stuff that lands on
linux-doc that I'm not meant to touch. I think that "b4 review" might
be my way forward here.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Conor Dooley @ 2026-04-09 16:02 UTC (permalink / raw)
To: Jingyuan Liang
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, tfiga, Dmitry Antipov,
Jarrett Schultz
In-Reply-To: <20260402-send-upstream-v3-9-6091c458d357@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 5441 bytes --]
On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> Documentation describes the required and optional properties for
> implementing Device Tree for a Microsoft G6 Touch Digitizer that
> supports HID over SPI Protocol 1.0 specification.
>
> The properties are common to HID over SPI.
>
> Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> ---
> .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> new file mode 100644
> index 000000000000..d1b0a2e26c32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> @@ -0,0 +1,126 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HID over SPI Devices
> +
> +maintainers:
> + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> + - Jiri Kosina <jkosina@suse.cz>
Why them and not you, the developers of the series?
> +
> +description: |+
> + HID over SPI provides support for various Human Interface Devices over the
> + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> + or sensors.
> +
> + The specification has been written by Microsoft and is currently available
> + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> +
> + If this binding is used, the kernel module spi-hid will handle the
> + communication with the device and the generic hid core layer will handle the
> + protocol.
This is not relevant to the binding, please remove it.
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - microsoft,g6-touch-digitizer
> + - const: hid-over-spi
> + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> + const: hid-over-spi
Why is it allowed but not recommended? Seems to me like we should
require device-specific compatibles.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + GPIO specifier for the digitizer's reset pin (active low). The line must
> + be flagged with GPIO_ACTIVE_LOW.
> +
> + vdd-supply:
> + description:
> + Regulator for the VDD supply voltage.
> +
> + input-report-header-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report header to be put on the SPI bus. This address has 24
> + bits.
> +
> + input-report-body-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Read Approval packet, listing an address of
> + the input report body to be put on the SPI bus. This address has 24 bits.
> +
> + output-report-address:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 0xffffff
> + description:
> + A value to be included in the Output Report sent by the host, listing an
> + address where the output report on the SPI bus is to be written to. This
> + address has 24 bits.
> +
> + read-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Read Approval packets. 1 byte.
> +
> + write-opcode:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + Value to be used in Write Approval packets. 1 byte.
Why can none of these things be determined from the device's compatible?
On the surface, they like the kinds of things that could/should be.
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - interrupts
> + - reset-gpios
> + - vdd-supply
> + - input-report-header-address
> + - input-report-body-address
> + - output-report-address
> + - read-opcode
> + - write-opcode
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hid@0 {
> + compatible = "microsoft,g6-touch-digitizer", "hid-over-spi";
> + reg = <0x0>;
> + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> + vdd-supply = <&pm8350c_l3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_d6_int_bias>;
> + input-report-header-address = <0x1000>;
> + input-report-body-address = <0x1004>;
> + output-report-address = <0x2000>;
> + read-opcode = /bits/ 8 <0x0b>;
> + write-opcode = /bits/ 8 <0x02>;
> + };
> + };
>
> --
> 2.53.0.1185.g05d4b7b318-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH mm-unstable v15 03/13] mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
From: Nico Pache @ 2026-04-09 16:17 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, lorenzo.stoakes, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, peterx, pfalcato, rakie.kim,
raquini, rdunlap, richard.weiyang, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <2e3f7c8c-c443-4e71-ad60-36c5203de09b@kernel.org>
On Thu, Apr 9, 2026 at 2:14 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> On 4/8/26 21:48, Nico Pache wrote:
> > On Thu, Mar 12, 2026 at 2:56 PM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 3/12/26 21:36, David Hildenbrand (Arm) wrote:
> >>>
> >>> Okay, now I am confused. Why are you not taking care of
> >>> collapse_scan_pmd() in the same context?
> >>>
> >>> Because if you make sure that we properly check against a max_ptes_swap
> >>> similar as in the style above, we'd rule out swapin right from the start?
> >>>
> >>> Also, I would expect that all other parameters in there are similarly
> >>> handled?
> >>>
> >>
> >> Okay, I think you should add the following:
> >
> > Hey! Thanks for all your reviews here.
> >
> > For multiple reasons, here is the solution I developed:
> >
> > Add a patch before the generalize __collapse.. patch that reworks the
> > max_ptes* handling and introduces the helpers (no functional changes).
>
> I assume that's roughly the patch I shared below? If so, sounds good to me.
Ok cool! Yeah very similar. I was just making sure you weren't dead
set on it being squashed into the other patch.
>
> --
> Cheers,
>
> David
>
^ permalink raw reply
* Re: [PATCH] tracing: Documentation: Update histogram-design.rst for fn() handling
From: Steven Rostedt @ 2026-04-09 16:20 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, LKML, Linux Trace Kernel, Masami Hiramatsu,
Mathieu Desnoyers, Tom Zanussi
In-Reply-To: <87tstk9lbe.fsf@trenco.lwn.net>
On Thu, 09 Apr 2026 09:59:17 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> No patchwork ... but there is a *massive* pile of stuff that lands on
> linux-doc that I'm not meant to touch. I think that "b4 review" might
> be my way forward here.
There's quite a bit that lands in tracing that isn't mine too. It's mostly
for my review or (FYI), after I look at it I'll set the status to "Handled
Elsewhere" or "Not Applicable".
-- Steve
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Dmitry Torokhov @ 2026-04-09 17:16 UTC (permalink / raw)
To: Conor Dooley
Cc: Jingyuan Liang, Jiri Kosina, Benjamin Tissoires, Jonathan Corbet,
Mark Brown, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-input,
linux-doc, linux-kernel, linux-spi, linux-trace-kernel,
devicetree, hbarnor, tfiga, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260409-defuse-thank-4b038128fac5@spud>
On Thu, Apr 09, 2026 at 05:02:11PM +0100, Conor Dooley wrote:
> On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> > Documentation describes the required and optional properties for
> > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > supports HID over SPI Protocol 1.0 specification.
> >
> > The properties are common to HID over SPI.
> >
> > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > ---
> > .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> > 1 file changed, 126 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > new file mode 100644
> > index 000000000000..d1b0a2e26c32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > @@ -0,0 +1,126 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HID over SPI Devices
> > +
> > +maintainers:
> > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > + - Jiri Kosina <jkosina@suse.cz>
>
> Why them and not you, the developers of the series?
>
> > +
> > +description: |+
> > + HID over SPI provides support for various Human Interface Devices over the
> > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > + or sensors.
> > +
> > + The specification has been written by Microsoft and is currently available
> > + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > +
> > + If this binding is used, the kernel module spi-hid will handle the
> > + communication with the device and the generic hid core layer will handle the
> > + protocol.
>
> This is not relevant to the binding, please remove it.
>
> > +
> > +allOf:
> > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - microsoft,g6-touch-digitizer
> > + - const: hid-over-spi
> > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > + const: hid-over-spi
>
> Why is it allowed but not recommended? Seems to me like we should
> require device-specific compatibles.
Why would we want to change the driver code to add a new compatible each
time a vendor decides to create a chip that is fully hid-spi-protocol
compliant? Or is the plan to still allow "hid-over-spi" fallback but
require device-specific compatible that will be ignored unless there is
device-specific quirk needed?
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + reset-gpios:
> > + maxItems: 1
> > + description:
> > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > + be flagged with GPIO_ACTIVE_LOW.
> > +
> > + vdd-supply:
> > + description:
> > + Regulator for the VDD supply voltage.
> > +
> > + input-report-header-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report header to be put on the SPI bus. This address has 24
> > + bits.
> > +
> > + input-report-body-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Read Approval packet, listing an address of
> > + the input report body to be put on the SPI bus. This address has 24 bits.
> > +
> > + output-report-address:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + minimum: 0
> > + maximum: 0xffffff
> > + description:
> > + A value to be included in the Output Report sent by the host, listing an
> > + address where the output report on the SPI bus is to be written to. This
> > + address has 24 bits.
> > +
> > + read-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Read Approval packets. 1 byte.
> > +
> > + write-opcode:
> > + $ref: /schemas/types.yaml#/definitions/uint8
> > + description:
> > + Value to be used in Write Approval packets. 1 byte.
>
> Why can none of these things be determined from the device's compatible?
> On the surface, they like the kinds of things that could/should be.
Why would we want to keep tables of these values in the kernel and again
have to update the driver for each new chip? It also probably
firmware-dependent.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Moger, Babu @ 2026-04-09 17:19 UTC (permalink / raw)
To: Reinette Chatre, Babu Moger, corbet@lwn.net, tony.luck@intel.com,
Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <43880b7b-b390-4e7f-8c2a-46cde9e3b051@intel.com>
Hi Reinette,
On 4/8/2026 6:41 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 4/8/26 4:07 PM, Moger, Babu wrote:
>> On 4/8/2026 4:24 PM, Reinette Chatre wrote:
>>> On 4/8/26 1:45 PM, Babu Moger wrote:
> ...
>
>>>> The modes "global_assign_ctrl_inherit_mon_per_cpu" and "global_assign_ctrl_assign_mon_per_cpu" represent the actual PLZA modes.
>>>>
>>>> Both of these modes introduce new files kernel_mode_cpus/ and kernel_mode_cpus_list in the resctrl group.
>>>
>>> Right. To be specific when the user changes the mode to either "global_assign_ctrl_inherit_mon_per_cpu" or
>>> "global_assign_ctrl_assign_mon_per_cpu" the new files will be created in the default resource group with
>>> associated setting applied globally at that time.
>>
>> If, at that point, "info/kernel_mode_assignment" points to // (the default group), is that correct?
>
> I see "info/kernel_mode_assignment" pointing to default group as the only
> option right after a mode switch away from "inherit_ctrl_and_mon".
>
> To elaborate, the current idea is that the mode within info/kernel_mode determines
> which, if any, control files are presented to user space.
> Assuming that the system boots up with:
> # cat info/kernel_mode
> [inherit_ctrl_and_mon]
> global_assign_ctrl_inherit_mon_per_cpu
> global_assign_ctrl_assign_mon_per_cpu
>
> In above scenario "info/kernel_mode_assignment" does not exist (is not visible to
> user space).
>
> When the user switches to either "global_assign_ctrl_inherit_mon_per_cpu" or
> 'global_assign_ctrl_assign_mon_per_cpu" then "info/kernel_mode_assignment" is created
> (or made visible to user space) and is expected to point to default group.
> User can change the group using "info/kernel_mode_assignment" at this point.
>
> If the current scenario is below ...
> # cat info/kernel_mode
> [global_assign_ctrl_inherit_mon_per_cpu]
> inherit_ctrl_and_mon
> global_assign_ctrl_assign_mon_per_cpu
>
> ... then "info/kernel_mode_assignment" will exist but what it should contain if
> user switches mode at this point may be up for discussion.
>
> option 1)
> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
> the resource group in "info/kernel_mode_assignment" is reset to the
> default group and all CPUs PLZA state reset to match. The kernel_mode_cpus
> and kernel_mode_cpuslist files become visible in default resource group
> and they contain "all online CPUs".
>
> option 2)
> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
> the resource group in "info/kernel_mode_assignment" is kept and all
> CPUs PLZA state set to match it while also keeping the current
> values of that resource group's kernel_mode_cpus and kernel_mode_cpuslist
> files.
>
> I am leaning towards "option 1" to keep it consistent with a switch from
> "inherit_ctrl_and_mon" and being deterministic about how a mode is started with
Yes. The "option 1" seems appropriate.
> a clean slate. What are your thoughts? What would be use case where a user would
> want to switch between "global_assign_ctrl_inherit_mon_per_cpu" and
> "global_assign_ctrl_assign_mon_per_cpu" to just switch rmid_en on and off?
This is a bit tricky.
Currently, our requirement is to have a CTRL_MON group for
global_assign_ctrl_inherit_mon_per_cpu. In this scenario, we use the
group’s CLOSID for PLZA configuration, and RMID is not used (rmid_en =
0) when setting up PLZA.
Our requirement is also to have a CTRL_MON/MON group for
global_assign_ctrl_assign_mon_per_cpu. In this case as well, the group’s
CLOSID and RMID (rmid_en = 1) both are used configure PLZA.
Actually, we should not allow these changes from
global_assign_ctrl_inherit_mon_per_cpu to
global_assign_ctrl_assign_mon_per_cpu or visa versa.
This seems restrictive.
>
>
>> And if "info/kernel_mode_assignment" points to a different group
>> (for example, test//), then the kernel_mode_cpus/ and
>> kernel_mode_cpus_list files will be created only under the test//
>> group. Is that correct?
>
> I expect that if "info/kernel_mode_assignment" exists then the group
> listed within contains kernel_mode_cpus and kernel_mode_cpuslist.
> How the group ends up in "info/kernel_mode_assignment" could result
> from mode change or from write by user space.
>
Ack.
Thanks
Babu>
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Reinette Chatre @ 2026-04-09 17:26 UTC (permalink / raw)
To: Moger, Babu, Babu Moger, corbet@lwn.net, tony.luck@intel.com,
Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <bb9f62f1-0c79-4d29-9866-c39d08c3a774@amd.com>
Hi Babu,
On 4/9/26 10:19 AM, Moger, Babu wrote:
> On 4/8/2026 6:41 PM, Reinette Chatre wrote:
>> When the user switches to either "global_assign_ctrl_inherit_mon_per_cpu" or
>> 'global_assign_ctrl_assign_mon_per_cpu" then "info/kernel_mode_assignment" is created
>> (or made visible to user space) and is expected to point to default group.
>> User can change the group using "info/kernel_mode_assignment" at this point.
>>
>> If the current scenario is below ...
>> # cat info/kernel_mode
>> [global_assign_ctrl_inherit_mon_per_cpu]
>> inherit_ctrl_and_mon
>> global_assign_ctrl_assign_mon_per_cpu
>>
>> ... then "info/kernel_mode_assignment" will exist but what it should contain if
>> user switches mode at this point may be up for discussion.
>>
>> option 1)
>> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
>> the resource group in "info/kernel_mode_assignment" is reset to the
>> default group and all CPUs PLZA state reset to match. The kernel_mode_cpus
>> and kernel_mode_cpuslist files become visible in default resource group
>> and they contain "all online CPUs".
>>
>> option 2)
>> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
>> the resource group in "info/kernel_mode_assignment" is kept and all
>> CPUs PLZA state set to match it while also keeping the current
>> values of that resource group's kernel_mode_cpus and kernel_mode_cpuslist
>> files.
>>
>> I am leaning towards "option 1" to keep it consistent with a switch from
>> "inherit_ctrl_and_mon" and being deterministic about how a mode is started with
>
> Yes. The "option 1" seems appropriate.
>
>> a clean slate. What are your thoughts? What would be use case where a user would
>> want to switch between "global_assign_ctrl_inherit_mon_per_cpu" and
>> "global_assign_ctrl_assign_mon_per_cpu" to just switch rmid_en on and off?
>
>
> This is a bit tricky.
>
> Currently, our requirement is to have a CTRL_MON group for
> global_assign_ctrl_inherit_mon_per_cpu. In this scenario, we use the
> group’s CLOSID for PLZA configuration, and RMID is not used (rmid_en
> = 0) when setting up PLZA.
>
> Our requirement is also to have a CTRL_MON/MON group for
> global_assign_ctrl_assign_mon_per_cpu. In this case as well, the
> group’s CLOSID and RMID (rmid_en = 1) both are used configure PLZA.
ah, right. Good catch.
>
> Actually, we should not allow these changes from
> global_assign_ctrl_inherit_mon_per_cpu to
> global_assign_ctrl_assign_mon_per_cpu or visa versa.
resctrl could allow it but as part of the switch it resets the "kernel mode group" to
be the default group every time? This would be the "option 1" above.
Reinette
^ permalink raw reply
* [PATCH v2] Documentation: sysctl: document net core sysctls
From: Shubham Chakraborty @ 2026-04-09 17:48 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, kuniyu, corbet, skhan,
linux-doc, linux-kernel, Shubham Chakraborty
In-Reply-To: <20260407083213.27045-1-chakrabortyshubham66@gmail.com>
Document missing net.core and net.unix sysctl entries in
admin-guide/sysctl/net.rst, and correct wording for defaults
that are derived from PAGE_SIZE, HZ, or CONFIG_MAX_SKB_FRAGS.
Also clarify that the RFS and flow-limit controls are only present
when CONFIG_RPS or CONFIG_NET_FLOW_LIMIT is enabled, and describe
rps_sock_flow_entries the way the handler implements it: non-zero
values are rounded up to the nearest power of two.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
Documentation/admin-guide/sysctl/net.rst | 66 +++++++++++++++++++++++-
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index 3b2ad61995d4..05d301b8752c 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -210,7 +210,9 @@ Default: 0 (off)
mem_pcpu_rsv
------------
-Per-cpu reserved forward alloc cache size in page units. Default 1MB per CPU.
+Per-cpu reserved forward alloc cache size in page units.
+
+Default: 1MB per CPU, expressed in page units
bypass_prot_mem
---------------
@@ -238,6 +240,37 @@ rps_default_mask
The default RPS CPU mask used on newly created network devices. An empty
mask means RPS disabled by default.
+rps_sock_flow_entries
+---------------------
+
+The total number of entries in the RPS flow table. This is used by
+RFS (Receive Flow Steering) to track which CPU is currently processing
+a flow in userspace. Non-zero values are rounded up to the nearest
+power of two.
+Available only when ``CONFIG_RPS`` is enabled.
+
+Default: 0
+
+flow_limit_cpu_bitmap
+---------------------
+
+Bitmap of CPUs for which RPS flow limiting is enabled. Flow limiting
+prioritizes small flows during CPU contention by dropping packets
+from large flows slightly ahead of those from small flows.
+Available only when ``CONFIG_NET_FLOW_LIMIT`` is enabled.
+
+Default: 0 (disabled)
+
+flow_limit_table_len
+--------------------
+
+The number of buckets in the flow limit hashtable. This value is
+only consulted when a new table is allocated. Modifying it does
+not update active tables. This value should be a power of two.
+Available only when ``CONFIG_NET_FLOW_LIMIT`` is enabled.
+
+Default: 4096
+
tstamp_allow_data
-----------------
Allow processes to receive tx timestamps looped together with the original
@@ -290,6 +323,8 @@ probed in a round-robin manner. Also, a polling cycle may not exceed
netdev_budget_usecs microseconds, even if netdev_budget has not been
exhausted.
+Default: 300
+
netdev_budget_usecs
---------------------
@@ -297,12 +332,16 @@ Maximum number of microseconds in one NAPI polling cycle. Polling
will exit when either netdev_budget_usecs have elapsed during the
poll cycle or the number of packets processed reaches netdev_budget.
+Default: ``2 * USEC_PER_SEC / HZ`` (2000 when ``HZ`` is 1000)
+
netdev_max_backlog
------------------
Maximum number of packets, queued on the INPUT side, when the interface
receives packets faster than kernel can process them.
+Default: 1000
+
qdisc_max_burst
------------------
@@ -368,6 +407,15 @@ by the cpu which allocated them.
Default: 128
+max_skb_frags
+-------------
+
+The maximum number of fragments allowed per skb (socket buffer).
+This is mostly used for performance tuning of GSO (Generic
+Segmentation Offload).
+
+Default: ``CONFIG_MAX_SKB_FRAGS`` (17 if not overridden)
+
optmem_max
----------
@@ -377,6 +425,16 @@ optmem_max as a limit for its internal structures.
Default : 128 KB
+somaxconn
+---------
+
+Limit of the socket listen() backlog, known in userspace as SOMAXCONN.
+The maximum number of established sockets waiting to be accepted by
+accept(). If the backlog is greater than this value, it will be
+silently truncated to this value.
+
+Default: 4096
+
fb_tunnels_only_for_init_net
----------------------------
@@ -449,6 +507,8 @@ GRO has decided not to coalesce, it is placed on a per-NAPI list. This
list is then passed to the stack when the number of segments reaches the
gro_normal_batch limit.
+Default: 8
+
high_order_alloc_disable
------------------------
@@ -465,9 +525,11 @@ Default: 0
----------------------------------------------------------
There is only one file in this directory.
-unix_dgram_qlen limits the max number of datagrams queued in Unix domain
+max_dgram_qlen limits the max number of datagrams queued in Unix domain
socket's buffer. It will not take effect unless PF_UNIX flag is specified.
+Default: 10
+
3. /proc/sys/net/ipv4 - IPV4 settings
-------------------------------------
--
2.53.0
^ permalink raw reply related
* [PATCH] Documentation: Refactored watchdog old doc
From: Sunny Patel @ 2026-04-09 17:53 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Wim Van Sebroeck, Guenter Roeck, Shuah Khan, linux-watchdog,
linux-doc, linux-kernel, Sunny Patel
Revisited old doc of watchdog and did some cleanup.
Also added support for new api in doc.
Signed-off-by: Sunny Patel <nueralspacetech@gmail.com>
---
Documentation/watchdog/watchdog-api.rst | 49 +++++++++++++++++++++----
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/Documentation/watchdog/watchdog-api.rst b/Documentation/watchdog/watchdog-api.rst
index 78e228c272cf..446f961852ec 100644
--- a/Documentation/watchdog/watchdog-api.rst
+++ b/Documentation/watchdog/watchdog-api.rst
@@ -2,7 +2,7 @@
The Linux Watchdog driver API
=============================
-Last reviewed: 10/05/2007
+Last reviewed: 04/08/2026
@@ -106,11 +106,10 @@ the requested one due to limitation of the hardware::
This example might actually print "The timeout was set to 60 seconds"
if the device has a granularity of minutes for its timeout.
-Starting with the Linux 2.4.18 kernel, it is possible to query the
-current timeout using the GETTIMEOUT ioctl::
+It is also possible to get the current timeout with the GETTIMEOUT ioctl::
ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
- printf("The timeout was is %d seconds\n", timeout);
+ printf("The timeout is %d seconds\n", timeout);
Pretimeouts
===========
@@ -133,7 +132,7 @@ seconds. Setting a pretimeout to zero disables it.
There is also a get function for getting the pretimeout::
ioctl(fd, WDIOC_GETPRETIMEOUT, &timeout);
- printf("The pretimeout was is %d seconds\n", timeout);
+ printf("The pretimeout is %d seconds\n", timeout);
Not all watchdog drivers will support a pretimeout.
@@ -145,7 +144,7 @@ before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl
that returns the number of seconds before reboot::
ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);
- printf("The timeout was is %d seconds\n", timeleft);
+ printf("The timeout is %d seconds\n", timeleft);
Environmental monitoring
========================
@@ -227,12 +226,33 @@ The watchdog saw a keepalive ping since it was last queried.
WDIOF_SETTIMEOUT Can set/get the timeout
================ =======================
-The watchdog can do pretimeouts.
+The watchdog supports timeout set/get via the WDIOC_SETTIMEOUT and
+WDIOC_GETTIMEOUT ioctls.
================ ================================
WDIOF_PRETIMEOUT Pretimeout (in seconds), get/set
================ ================================
+The watchdog supports a pretimeout, a warning interrupt that fires before
+the actual reboot tiemout. USE WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
+to set/get the pretimeout.
+
+ ================ ================================
+ WDIOF_MAGICCLOSE Supports magic close char
+ ================ ================================
+
+The driver supports the Magic Close feature, The watchdog is only disabled
+if the characted 'V' is written to /dev/watchdog before the file descriptor
+is closed. Without this, closing the device disables the watchdog
+unconditionally.
+
+ ================ ================================
+ WDIOF_ALARMONLY Not a reboot watchdog
+ ================ ================================
+
+The watchdog will not reboot the system when it expires. Instead it
+triggers a management or other external alarm. Userspace should not
+rely on a system reboot occurring.
For those drivers that return any bits set in the option field, the
GETSTATUS and GETBOOTSTATUS ioctls can be used to ask for the current
@@ -268,4 +288,17 @@ The following options are available:
WDIOS_TEMPPANIC Kernel panic on temperature trip
================= ================================
-[FIXME -- better explanations]
+``WDIOS_DISABLECARD`` stops the watchdog timer. The driver will cease
+pinging the hardware watchdog, allowing a controlled shutdown without
+a forced reboot. This is equivalent to the watchdog being disarmed.
+
+``WDIOS_ENABLECARD`` starts the watchdog timer. if the watchdog was
+previously stopped via ``WDIOS_DISABLECARD``,this will re-enable it. The
+hardware watchdog will begin counting down from the configured timeout.
+
+``WDIOS_TEMPPANIC`` enables temperature-based kernel panic. When set,
+the driver will call ``panic()`` (or ``kernel_power_off()`` on some
+drivers) if the hardware temperature sensor exceeds its threshold,
+rather than only setting the ``WDIOF_OVERHEAT`` status bit. Support
+for this option is driver-specific, not all watchdog drivers implement
+temperature monitoring.
\ No newline at end of file
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: John Hubbard @ 2026-04-09 18:02 UTC (permalink / raw)
To: Joel Fernandes
Cc: Eliot Courtney, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Bjorn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Dave Airlie, Daniel Almeida,
Koen Koning, dri-devel, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher, Christian Koenig,
Jani Nikula, Joonas Lahtinen, Vivi Rodrigo, Tvrtko Ursulin,
Rui Huang, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellstrom, Helge Deller, Alex Gaynor, Boqun Feng,
Alistair Popple, Timur Tabi, Edwin Peer, Alexandre Courbot,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, Elle Rhumsaa, Alexey Ivanov, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <1775730646.3752.4760@nvidia.com>
On 4/9/26 3:33 AM, Joel Fernandes wrote:
...
> Since it is 3 against 1 here, I rest my case :-). I am still in
As Danilo points out, we want to foster healthy debate and land
on whatever comes out of that. Not just by counting noses. :)
> disagreement since I do not see much benefit (that is why I said
> pointless above). Actually it is not even about readability, that is
> subjective (and I haven’t heard most people say parametrizing code for
> the sake of it makes it more readable anyway). It is that the code gen
> is worse, and the complexity is just moved to a higher level in the
> code, not removed. So what are we getting out of this really, other than
> more boiler plate in higher layers of the code that did not exist
> before? Not performance, not better generated code. Really nothing. See
> all the data points in my previous reply.
Alex's latest response[1] does a *much* better job than mine, in
explicitly highlighting what we get out of this. (It arrived a bit after
your response here.) Please take a very close look at that response and
see what you think.
The patterns in these page tables are not a new thing, and Rust has
language features to help express them.
[1] https://lore.kernel.org/DHOKJ3MJNO5P.SXKOAYKX13JL@nvidia.com
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Moger, Babu @ 2026-04-09 18:05 UTC (permalink / raw)
To: Reinette Chatre, Babu Moger, corbet@lwn.net, tony.luck@intel.com,
Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <5a273b0f-8225-4e9e-924e-884183734659@intel.com>
Hi Reinette,
On 4/9/2026 12:26 PM, Reinette Chatre wrote:
>
> Hi Babu,
>
> On 4/9/26 10:19 AM, Moger, Babu wrote:
>> On 4/8/2026 6:41 PM, Reinette Chatre wrote:
>
>>> When the user switches to either "global_assign_ctrl_inherit_mon_per_cpu" or
>>> 'global_assign_ctrl_assign_mon_per_cpu" then "info/kernel_mode_assignment" is created
>>> (or made visible to user space) and is expected to point to default group.
>>> User can change the group using "info/kernel_mode_assignment" at this point.
>>>
>>> If the current scenario is below ...
>>> # cat info/kernel_mode
>>> [global_assign_ctrl_inherit_mon_per_cpu]
>>> inherit_ctrl_and_mon
>>> global_assign_ctrl_assign_mon_per_cpu
>>>
>>> ... then "info/kernel_mode_assignment" will exist but what it should contain if
>>> user switches mode at this point may be up for discussion.
>>>
>>> option 1)
>>> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
>>> the resource group in "info/kernel_mode_assignment" is reset to the
>>> default group and all CPUs PLZA state reset to match. The kernel_mode_cpus
>>> and kernel_mode_cpuslist files become visible in default resource group
>>> and they contain "all online CPUs".
>>>
>>> option 2)
>>> When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
>>> the resource group in "info/kernel_mode_assignment" is kept and all
>>> CPUs PLZA state set to match it while also keeping the current
>>> values of that resource group's kernel_mode_cpus and kernel_mode_cpuslist
>>> files.
>>>
>>> I am leaning towards "option 1" to keep it consistent with a switch from
>>> "inherit_ctrl_and_mon" and being deterministic about how a mode is started with
>>
>> Yes. The "option 1" seems appropriate.
>>
>>> a clean slate. What are your thoughts? What would be use case where a user would
>>> want to switch between "global_assign_ctrl_inherit_mon_per_cpu" and
>>> "global_assign_ctrl_assign_mon_per_cpu" to just switch rmid_en on and off?
>>
>>
>> This is a bit tricky.
>>
>> Currently, our requirement is to have a CTRL_MON group for
>> global_assign_ctrl_inherit_mon_per_cpu. In this scenario, we use the
>> group’s CLOSID for PLZA configuration, and RMID is not used (rmid_en
>> = 0) when setting up PLZA.
>>
>> Our requirement is also to have a CTRL_MON/MON group for
>> global_assign_ctrl_assign_mon_per_cpu. In this case as well, the
>> group’s CLOSID and RMID (rmid_en = 1) both are used configure PLZA.
>
> ah, right. Good catch.
>
>>
>> Actually, we should not allow these changes from
>> global_assign_ctrl_inherit_mon_per_cpu to
>> global_assign_ctrl_assign_mon_per_cpu or visa versa.
>
> resctrl could allow it but as part of the switch it resets the "kernel mode group" to
> be the default group every time? This would be the "option 1" above.
Other options.
Allow global_assign_ctrl_inherit_mon_per_cpu ->
global_assign_ctrl_assign_mon_per_cpu. As part of the switch, reset the
"kernel mode group" to the default group.
Allow global_assign_ctrl_assign_mon_per_cpu ->
global_assign_ctrl_inherit_mon_per_cpu. In this case switch
to CTRL_MON/MON -> CTRL_MON.
Thanks
Babu
>
> Reinette
>
>
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] libie: add bookkeeping support for control queue messages
From: Tony Nguyen @ 2026-04-09 18:11 UTC (permalink / raw)
To: Paolo Abeni, davem, kuba, edumazet, andrew+netdev, netdev
Cc: Phani R Burra, larysa.zaremba, 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, Bharath R, Samuel Salin, Aleksandr Loktionov
In-Reply-To: <b559c877-7712-4ed7-adb4-d2b667e16e74@redhat.com>
On 4/9/2026 2:07 AM, Paolo Abeni wrote:
> On 4/3/26 9:49 PM, Tony Nguyen wrote:
...
> There are more remarks on the following patch, please have a look.
>
> Also, it would be very helpful if you could help triaging such
> (overwhelming amount of) feedback on future submissions, explicitly
> commenting on the ML. Sashiko tends to be quite noise on device driver code.
I recently started looking at Sashiko. Yea, it's very chatty. I'll try
to help out in bringing feedback over.
Thanks,
Tony
> Thanks,
>
> Paolo
>
^ permalink raw reply
* Re: [PATCH mm-unstable v15 03/13] mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
From: David Hildenbrand (Arm) @ 2026-04-09 18:35 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, lorenzo.stoakes, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, peterx, pfalcato, rakie.kim,
raquini, rdunlap, richard.weiyang, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <CAA1CXcCNLkdjMt=WXgJ1QYSn9WTgN8FVZDQk8E9P=S54sFDSDA@mail.gmail.com>
On 4/9/26 18:17, Nico Pache wrote:
> On Thu, Apr 9, 2026 at 2:14 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> On 4/8/26 21:48, Nico Pache wrote:
>>> On Thu, Mar 12, 2026 at 2:56 PM David Hildenbrand (Arm)
>>> <david@kernel.org> wrote:
>>>
>>> Hey! Thanks for all your reviews here.
>>>
>>> For multiple reasons, here is the solution I developed:
>>>
>>> Add a patch before the generalize __collapse.. patch that reworks the
>>> max_ptes* handling and introduces the helpers (no functional changes).
>>
>> I assume that's roughly the patch I shared below? If so, sounds good to me.
>
> Ok cool! Yeah very similar. I was just making sure you weren't dead
> set on it being squashed into the other patch.
Oh no, it should be a separate cleanup without functional changes!
--
Cheers,
David
^ permalink raw reply
* Re: (subset) [PATCH 0/8] arm64: Implement support for 2025 dpISA extensions
From: Catalin Marinas @ 2026-04-09 18:35 UTC (permalink / raw)
To: Will Deacon, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260302-arm64-dpisa-2025-v1-0-0855e7f41689@kernel.org>
On Mon, 02 Mar 2026 22:53:15 +0000, Mark Brown wrote:
> The 2025 dpISA extensions introduce a number of architecture features
> all of which are fairly straightforward from a kernel point of view
> since they only introduce new instructions, not any architecture state.
>
> All the relevant newly added ID registers are already exported by KVM,
> all non-RES0 bits in ID_AA64ZFR0_EL1 and ID_AA64FPFR0_EL1 are writable
> and the updates to ID_AA64ISARx_EL1 are all additional values in already
> exported bitfields.
>
> [...]
Applied to arm64 (for-next/sysreg), thanks! That's only the sysreg
definitions as these are stable. I also applied the KERNEL_HWCAP_*
generation on a different branch.
[2/8] arm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12
https://git.kernel.org/arm64/c/b964aa8d68f7
[3/8] arm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12
https://git.kernel.org/arm64/c/bb5e1e540501
[4/8] arm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12
https://git.kernel.org/arm64/c/d74576b51ba6
[5/8] arm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12
https://git.kernel.org/arm64/c/bf56250f34a4
[6/8] arm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12
https://git.kernel.org/arm64/c/306736fd5155
^ permalink raw reply
* Re: (subset) [PATCH 0/8] arm64: Implement support for 2025 dpISA extensions
From: Catalin Marinas @ 2026-04-09 18:39 UTC (permalink / raw)
To: Will Deacon, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <177575970227.3883927.939712260390088306.b4-ty@arm.com>
On Thu, Apr 09, 2026 at 07:35:02PM +0100, Catalin Marinas wrote:
> On Mon, 02 Mar 2026 22:53:15 +0000, Mark Brown wrote:
> > The 2025 dpISA extensions introduce a number of architecture features
> > all of which are fairly straightforward from a kernel point of view
> > since they only introduce new instructions, not any architecture state.
> >
> > All the relevant newly added ID registers are already exported by KVM,
> > all non-RES0 bits in ID_AA64ZFR0_EL1 and ID_AA64FPFR0_EL1 are writable
> > and the updates to ID_AA64ISARx_EL1 are all additional values in already
> > exported bitfields.
> >
> > [...]
>
> Applied to arm64 (for-next/sysreg), thanks! That's only the sysreg
> definitions as these are stable. I also applied the KERNEL_HWCAP_*
> generation on a different branch.
>
> [2/8] arm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/b964aa8d68f7
> [3/8] arm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/bb5e1e540501
> [4/8] arm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/d74576b51ba6
> [5/8] arm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/bf56250f34a4
> [6/8] arm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12
> https://git.kernel.org/arm64/c/306736fd5155
b4 ty got confused with two emails for the same series, so only one went
out. The first patch is on for-next/misc:
[1/8] arm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps
https://git.kernel.org/arm64/c/abed23c3c44f
--
Catalin
^ permalink raw reply
* [PATCH] docs: fix duplicated word in real-time differences doc
From: Gleb Golovko @ 2026-04-09 19:19 UTC (permalink / raw)
To: linux-doc; +Cc: corbet, Gleb Golovko
Remove duplicated "the" in
Documentation/core-api/real-time/differences.rst.
Signed-off-by: Gleb Golovko <gaben123001@gmail.com>
---
Documentation/core-api/real-time/differences.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
index 83ec9aa1c61a..a129570dab5a 100644
--- a/Documentation/core-api/real-time/differences.rst
+++ b/Documentation/core-api/real-time/differences.rst
@@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without
risking livelock.
In order to solve the problem at the API level, the sequence locks were extended
-to allow a proper handover between the the spinning reader and the maybe
+to allow a proper handover between the spinning reader and the maybe
blocked writer.
Sequence locks
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 1/9] Add documentation for Sahara protocol.
From: Jeff Hugo @ 2026-04-09 19:47 UTC (permalink / raw)
To: Kishore Batta, Jonathan Corbet, Shuah Khan, Carl Vanderlip,
Oded Gabbay, Manivannan Sadhasivam, andersson
Cc: linux-doc, linux-kernel, linux-arm-msm, dri-devel, mhi
In-Reply-To: <20260319-sahara_protocol_new_v2-v4-1-47ad79308762@oss.qualcomm.com>
$SUBJECT is not a complete sentence. You should drop the full stop ".".
On 3/19/2026 12:31 AM, Kishore Batta wrote:
> Introduce documentation for the Sahara protocol, describing its
> operational modes and their respective functions. The image transfer mode
> enables firmware transfer from host to device. The memory debug mode
> allows extraction of device memory contents to host. The command mode
> facilitates retrieval of DDR training data from the device and also
> to restore the training data back to device in subsequent boot of device
> to save boot time.
Thank you for the documentation.
>
> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
> ---
> Documentation/sahara/index.rst | 14 +
> Documentation/sahara/sahara_protocol.rst | 1241 ++++++++++++++++++++++++++++++
I see from the cover letter that the sahara implementation is moving
under MHI. I expect to have more about that move later in the series,
but MHI already has a documentation directory. I don't see why Sahara
should be at the top level if it is considered to be coupled to MHI.
> 2 files changed, 1255 insertions(+)
>
> diff --git a/Documentation/sahara/index.rst b/Documentation/sahara/index.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..073002c15a203344524e258b2aa0a6ce839e064b
> --- /dev/null
> +++ b/Documentation/sahara/index.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +========================
> +Qualcomm Sahara protocol
> +========================
> +
> +The Sahara protocol transfers data to and from memory and describes packet
> +structures, packet flows, and their usage.
> +
> +.. toctree::
> + :maxdepth: 2
> + :caption: Contents
> +
> + sahara_protocol
> diff --git a/Documentation/sahara/sahara_protocol.rst b/Documentation/sahara/sahara_protocol.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..91204bb7d170be4fc4c85f142b8f0b93d3c421a0
> --- /dev/null
> +++ b/Documentation/sahara/sahara_protocol.rst
> @@ -0,0 +1,1241 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +
> +=============================
> +Sahara protocol Specification
> +=============================
> +
> +The Qualcomm Sahara protocol driver is primarily designed for transferring
> +software images from a host device to a target device using a simplified data
> +transfer mechanism over a link. However, the sahara protocol does not support
"Sahara" should be capital "S" everywhere in this patch.
^ permalink raw reply
* Re: [PATCH v2 1/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Jacek Anaszewski @ 2026-04-09 20:04 UTC (permalink / raw)
To: Armin Wolf, lee, pavel
Cc: linux-kernel, corbet, skhan, linux-leds, linux-doc, wse, pobrn,
m.tretter
In-Reply-To: <20260331191619.3729-2-W_Armin@gmx.de>
Hi Armin,
On 3/31/26 9:16 PM, Armin Wolf wrote:
> Some multicolor LEDs support global brightness control in hardware,
> meaning that the maximum intensity of the color components is not
> connected to the maximum global brightness. Such LEDs cannot be
> described properly by the current multicolor LED class interface,
> because it assumes that the maximum intensity of each color component
> is described by the maximum global brightness of the LED.
>
> Fix this by introducing a new sysfs attribute called
> "multi_max_intensity" holding the maximum intensity values for the
> color components of a multicolor LED class device. Drivers can use
> the new max_intensity field inside struct mc_subled to tell the
> multicolor LED class code about those values. Intensity values written
> by userspace applications will be limited to this maximum value.
>
> Drivers for multicolor LEDs that do not support global brightness
> control in hardware might still want to use the maximum global LED
> brightness supplied via devicetree as the maximum intensity of each
> individual color component. Such drivers should set max_intensity
> to 0 so that the multicolor LED core can act accordingly.
>
> The lp50xx and ncp5623 LED drivers already use hardware-based control
> for the global LED brightness. Modify those drivers to correctly
> initalize .max_intensity to avoid being limited to the maximum global
> brightness supplied via devicetree.
>
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> ---
> .../ABI/testing/sysfs-class-led-multicolor | 19 ++++++--
> Documentation/leds/leds-class-multicolor.rst | 21 ++++++++-
> drivers/leds/led-class-multicolor.c | 47 ++++++++++++++++++-
> drivers/leds/leds-lp50xx.c | 1 +
> drivers/leds/rgb/leds-ncp5623.c | 4 +-
> include/linux/led-class-multicolor.h | 30 +++++++++++-
> 6 files changed, 113 insertions(+), 9 deletions(-)
[...]
> diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
> index db9f34c6736e..6f89d92566b2 100644
> --- a/include/linux/led-class-multicolor.h
> +++ b/include/linux/led-class-multicolor.h
> @@ -9,10 +9,31 @@
> #include <linux/leds.h>
> #include <dt-bindings/leds/common.h>
>
> +/**
> + * struct mc_subled - Color component description.
> + * @color_index: Color ID.
> + * @brightness: Scaled intensity.
> + * @intensity: Current intensity.
> + * @max_intensity: Maximum supported intensity value.
> + * @channel: Channel index.
> + *
> + * Describes a color component of a multicolor LED. Many multicolor LEDs
> + * do no support gobal brightness control in hardware, so they use
s/gobal/global/
> + * the brightness field in connection with led_mc_calc_color_components()
> + * to perform the intensity scaling in software.
> + * Such drivers should set max_intensity to 0 to signal the multicolor LED core
> + * that the maximum global brightness of the LED class device should be used for
> + * limiting incoming intensity values.
> + *
> + * Multicolor LEDs that do support global brightness control in hardware
> + * should instead set max_intensity to the maximum intensity value supported
> + * by the hardware for a given color component.
> + */
> struct mc_subled {
> unsigned int color_index;
> unsigned int brightness;
> unsigned int intensity;
> + unsigned int max_intensity;
> unsigned int channel;
> };
>
> @@ -53,7 +74,14 @@ int led_classdev_multicolor_register_ext(struct device *parent,
> */
> void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
>
> -/* Calculate brightness for the monochrome LED cluster */
> +/**
> + * led_mc_calc_color_components() - Calculates component brightness values of a LED cluster.
> + * @mcled_cdev - Multicolor LED class device of the LED cluster.
> + * @brightness - Global brightness of the LED cluster.
> + *
> + * Calculates the brightness values for each color component of a monochrome LED cluster,
> + * see Documentation/leds/leds-class-multicolor.rst for details.
> + */
> int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
> enum led_brightness brightness);
>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v4 2/9] bus: mhi: Move sahara protocol driver under drivers/bus/mhi
From: Jeff Hugo @ 2026-04-09 20:20 UTC (permalink / raw)
To: Kishore Batta, Jonathan Corbet, Shuah Khan, Carl Vanderlip,
Oded Gabbay, Manivannan Sadhasivam, andersson
Cc: linux-doc, linux-kernel, linux-arm-msm, dri-devel, mhi
In-Reply-To: <20260319-sahara_protocol_new_v2-v4-2-47ad79308762@oss.qualcomm.com>
On 3/19/2026 12:31 AM, Kishore Batta wrote:
> The Sahara protocol driver is currently located under the QAIC
> accelerator subsystem even though protocol itself is transported over the
> MHI bus and is used by multiple Qualcomm flashless devices.
>
> Relocate the Sahara protocol driver to drivers/bus/mhi and register it as
> an independent MHI protocol driver. This avoids treating Sahara as QAIC
> specific and makes it available for reuse by other MHI based devices.
>
> As part of this move, introduce a dedicated Kconfig and Makefile under the
> MHI subsystem and expose the sahara interface via a common header.
I don't think this belongs under MHI. Mani needs to confirm that he
agrees with the concept of moving this there.
The Sahara protocol as defined by the spec does not require MHI. We know
that there are Sahara implementations over USB. I don't see a dependency
or relationship to MHI other than the current in-kernel implementation
uses MHI, but there are plenty of things that use MHI (qaic, mhi-net,
ath12k, etc) which are not a part of the MHI bus.
The implementation presented in this series is not well integrated into
MHI, which also suggests to me that it doesn't belong there. The
Documentation is not integrated with MHI (which I mentioned over on that
patch) and I see the header file (sahara.h) is also not integrated.
> diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c
> index 63fb8c7b4abcbe4f1b76c32106f4e8b9ea5e2c8e..76cc8086825e7949ed756d51fcb56a08f392d228 100644
> --- a/drivers/accel/qaic/qaic_drv.c
> +++ b/drivers/accel/qaic/qaic_drv.c
> @@ -15,6 +15,7 @@
> #include <linux/msi.h>
> #include <linux/mutex.h>
> #include <linux/pci.h>
> +#include <linux/sahara.h>
What do we need this for? register()/unregister() get removed.
> #include <linux/spinlock.h>
> #include <linux/workqueue.h>
> #include <linux/wait.h>
> @@ -32,7 +33,6 @@
> #include "qaic_ras.h"
> #include "qaic_ssr.h"
> #include "qaic_timesync.h"
> -#include "sahara.h"
>
> MODULE_IMPORT_NS("DMA_BUF");
>
> @@ -782,18 +782,12 @@ static int __init qaic_init(void)
> ret = pci_register_driver(&qaic_pci_driver);
> if (ret) {
> pr_debug("qaic: pci_register_driver failed %d\n", ret);
> - return ret;
> + goto free_pci;
This is wrong, and there should not be a change here.
>
> ret = mhi_driver_register(&qaic_mhi_driver);
> if (ret) {
> pr_debug("qaic: mhi_driver_register failed %d\n", ret);
> - goto free_pci;
> - }
> -
> - ret = sahara_register();
> - if (ret) {
> - pr_debug("qaic: sahara_register failed %d\n", ret);
> goto free_mhi;
This is also wrong
>
> @@ -847,7 +841,6 @@ static void __exit qaic_exit(void)
> qaic_ras_unregister();
> qaic_bootlog_unregister();
> qaic_timesync_deinit();
> - sahara_unregister();
> mhi_driver_unregister(&qaic_mhi_driver);
> pci_unregister_driver(&qaic_pci_driver);
> }
> diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
> index b39a11e6c624ba00349cca22d74bd876020590ab..4acedb886adccc6f76f69c241d53106da59b491f 100644
> --- a/drivers/bus/mhi/Kconfig
> +++ b/drivers/bus/mhi/Kconfig
> @@ -7,3 +7,4 @@
>
> source "drivers/bus/mhi/host/Kconfig"
> source "drivers/bus/mhi/ep/Kconfig"
> +source "drivers/bus/mhi/sahara/Kconfig"
> diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
> index 354204b0ef3ae4030469a24a659f32429d592aef..e4af535e1bb1bc9481fae60d7eb347700d2e874c 100644
> --- a/drivers/bus/mhi/Makefile
> +++ b/drivers/bus/mhi/Makefile
> @@ -3,3 +3,6 @@ obj-$(CONFIG_MHI_BUS) += host/
>
> # Endpoint MHI stack
> obj-$(CONFIG_MHI_BUS_EP) += ep/
> +
> +# Sahara MHI protocol
> +obj-$(CONFIG_MHI_SAHARA) += sahara/
> diff --git a/drivers/bus/mhi/sahara/Kconfig b/drivers/bus/mhi/sahara/Kconfig
> new file mode 100644
> index 0000000000000000000000000000000000000000..3f1caf6acd979a4af68aaf0e250aa54762e8cda5
> --- /dev/null
> +++ b/drivers/bus/mhi/sahara/Kconfig
> @@ -0,0 +1,18 @@
> +config MHI_SAHARA
> + tristate
> + depends on MHI_BUS
> + select FW_LOADER_COMPRESS
Why are we selecting this? I don't see anyone else doing this. Sahara
should work with and without firmware compression.
> + select FW_LOADER_COMPRESS_XZ
> + select FW_LOADER_COMPRESS_ZSTD
> + help
> + Enable support for the Sahara protocol transported over the MHI bus.
> +
> + The Sahara protocol is used to transfer firmware images, retrieve
> + memory dumps and exchange command mode DDR calibration data between
> + host and device. This driver is not tied to a specific SoC and may be
> + used by multiple MHI based devices.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called mhi_sahara.
> diff --git a/drivers/bus/mhi/sahara/Makefile b/drivers/bus/mhi/sahara/Makefile
> new file mode 100644
> index 0000000000000000000000000000000000000000..fc02a25935011cbd7138ea8f24b88cf5b032a4ce
> --- /dev/null
> +++ b/drivers/bus/mhi/sahara/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_MHI_SAHARA) += mhi_sahara.o
> +mhi_sahara-y := sahara.o
> diff --git a/drivers/accel/qaic/sahara.c b/drivers/bus/mhi/sahara/sahara.c
> similarity index 99%
> rename from drivers/accel/qaic/sahara.c
> rename to drivers/bus/mhi/sahara/sahara.c
> index fd3c3b2d1fd3bb698809e6ca669128e2dce06613..8ff7b6425ac5423ef8f32117151dca10397686a8 100644
> --- a/drivers/accel/qaic/sahara.c
> +++ b/drivers/bus/mhi/sahara/sahara.c
> @@ -1,6 +1,8 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -
> -/* Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. */
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.
> + *
> + */
What makes you think that changing the copyright markings is appropiate
when moving a file?
Furthermore, I wrote this code from scratch based on the spec document
and therefore know beyond a doubt that this file did not exist prior to
2024, so what you are changing the markings to is completely invalid.
Also the SPDX marking you are using is long deprecated and should not be
used.
> #include <linux/devcoredump.h>
> #include <linux/firmware.h>
> @@ -9,12 +11,11 @@
> #include <linux/minmax.h>
> #include <linux/mod_devicetable.h>
> #include <linux/overflow.h>
> +#include <linux/sahara.h>
> #include <linux/types.h>
> #include <linux/vmalloc.h>
> #include <linux/workqueue.h>
>
> -#include "sahara.h"
> -
> #define SAHARA_HELLO_CMD 0x1 /* Min protocol version 1.0 */
> #define SAHARA_HELLO_RESP_CMD 0x2 /* Min protocol version 1.0 */
> #define SAHARA_READ_DATA_CMD 0x3 /* Min protocol version 1.0 */
> @@ -928,8 +929,13 @@ int sahara_register(void)
> {
> return mhi_driver_register(&sahara_mhi_driver);
> }
> +module_init(sahara_register);
>
> void sahara_unregister(void)
> {
> mhi_driver_unregister(&sahara_mhi_driver);
> }
> +module_exit(sahara_unregister);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Qualcomm Sahara MHI protocol driver");
> diff --git a/drivers/accel/qaic/sahara.h b/include/linux/sahara.h
> similarity index 100%
> rename from drivers/accel/qaic/sahara.h
> rename to include/linux/sahara.h
>
^ 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