* Re: [PATCH v8 3/4] drm: Suppress intentional warning backtraces in scaling unit tests
From: David Gow @ 2026-05-06 9:38 UTC (permalink / raw)
To: Albert Esteve, Arnd Bergmann, Brendan Higgins, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Simona Vetter
In-Reply-To: <20260504-kunit_add_support-v8-3-3e5957cdd235@redhat.com>
Le 04/05/2026 à 3:41 PM, Albert Esteve a écrit :
> From: Guenter Roeck <linux@roeck-us.net>
>
> The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
> intentionally trigger warning backtraces by providing bad parameters to
> the tested functions. What is tested is the return value, not the existence
> of a warning backtrace. Suppress the backtraces to avoid clogging the
> kernel log and distraction from real problems.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Acked-by: Maíra Canal <mcanal@igalia.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Acked-by: David Gow <david@davidgow.net>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
I'm happy with this either with or without the extra check for the
warning count.
Acked-by: David Gow <david@davidgow.net>
We'll take this patch in the kunit tree along with the rest of the
series once everyone's happy.
Cheers,
-- David
> drivers/gpu/drm/tests/drm_rect_test.c | 23 +++++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
> index 17e1f34b76101..818e16e80c8f9 100644
> --- a/drivers/gpu/drm/tests/drm_rect_test.c
> +++ b/drivers/gpu/drm/tests/drm_rect_test.c
> @@ -409,8 +409,16 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
> const struct drm_rect_scale_case *params = test->param_value;
> int scaling_factor;
>
> - scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> - params->min_range, params->max_range);
> + /*
> + * drm_rect_calc_hscale() generates a warning backtrace whenever bad
> + * parameters are passed to it. This affects all unit tests with an
> + * error code in expected_scaling_factor.
> + */
> + kunit_warning_suppress(test) {
> + scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> + params->min_range,
> + params->max_range);
> + }
>
> KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
> }
> @@ -420,8 +428,15 @@ static void drm_test_rect_calc_vscale(struct kunit *test)
> const struct drm_rect_scale_case *params = test->param_value;
> int scaling_factor;
>
> - scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
> - params->min_range, params->max_range);
> + /*
> + * drm_rect_calc_vscale() generates a warning backtrace whenever bad
> + * parameters are passed to it. This affects all unit tests with an
> + * error code in expected_scaling_factor.
> + */
> + kunit_warning_suppress(test) {
> + scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
> + params->min_range, params->max_range);
> + }
>
> KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
> }
>
^ permalink raw reply
* Re: [PATCH v8 2/4] kunit: Add backtrace suppression self-tests
From: David Gow @ 2026-05-06 9:38 UTC (permalink / raw)
To: Albert Esteve, Arnd Bergmann, Brendan Higgins, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati, Kees Cook
In-Reply-To: <20260504-kunit_add_support-v8-2-3e5957cdd235@redhat.com>
Le 04/05/2026 à 3:41 PM, Albert Esteve a écrit :
> From: Guenter Roeck <linux@roeck-us.net>
>
> Add unit tests to verify that warning backtrace suppression works.
>
> Tests cover all three API forms:
> - Scoped: kunit_warning_suppress() with in-block count verification
> and post-block inactivity check.
> - Manual macros: KUNIT_START/END_SUPPRESSED_WARNING() with WARN()
> and WARN_ON(), both direct and through helper functions, as well
> as multiple warnings in a single block.
> - Direct functions: kunit_start/end_suppress_warning() with
> sequential independent suppression blocks and per-block counts.
>
> Furthermore, tests verify incremental warning counting, that
> kunit_has_active_suppress_warning() transitions correctly around
> suppression boundaries, and that suppression active in the test
> kthread does not leak to a separate kthread.
>
> If backtrace suppression does _not_ work, the unit tests will likely
> trigger unsuppressed backtraces, which should actually help to get
> the affected architectures / platforms fixed.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Reviewed-by: David Gow <david@davidgow.net>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
Looks good to me, thanks!
This is still:
Reviewed-by: David Gow <david@davidgow.net>
Cheers,
-- David
> lib/kunit/Makefile | 1 +
> lib/kunit/backtrace-suppression-test.c | 184 +++++++++++++++++++++++++++++++++
> 2 files changed, 185 insertions(+)
>
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index 4592f9d0aa8dd..2e8a6b71a2ab0 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -22,6 +22,7 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o
>
> obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
> obj-$(CONFIG_KUNIT_TEST) += platform-test.o
> +obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
>
> # string-stream-test compiles built-in only.
> ifeq ($(CONFIG_KUNIT_TEST),y)
> diff --git a/lib/kunit/backtrace-suppression-test.c b/lib/kunit/backtrace-suppression-test.c
> new file mode 100644
> index 0000000000000..0e6fb685d2cbb
> --- /dev/null
> +++ b/lib/kunit/backtrace-suppression-test.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for suppressing warning tracebacks.
> + *
> + * Copyright (C) 2024, Guenter Roeck
> + * Author: Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/bug.h>
> +#include <linux/completion.h>
> +#include <linux/kthread.h>
> +
> +static void backtrace_suppression_test_warn_direct(struct kunit *test)
> +{
> + kunit_warning_suppress(test) {
> + WARN(1, "This backtrace should be suppressed");
> + /*
> + * Count must be checked inside the scope; the handle
> + * is not accessible after the block exits.
> + */
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + }
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +}
> +
> +static void trigger_backtrace_warn(void)
> +{
> + WARN(1, "This backtrace should be suppressed");
> +}
> +
> +static void backtrace_suppression_test_warn_indirect(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + trigger_backtrace_warn();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> +}
> +
> +static void backtrace_suppression_test_warn_multi(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + WARN(1, "This backtrace should be suppressed");
> + trigger_backtrace_warn();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
> +}
> +
> +static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE) && !IS_ENABLED(CONFIG_KALLSYMS))
> + kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE or CONFIG_KALLSYMS");
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + WARN_ON(1);
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> +}
> +
> +static void trigger_backtrace_warn_on(void)
> +{
> + WARN_ON(1);
> +}
> +
> +static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
> +{
> + if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
> + kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + trigger_backtrace_warn_on();
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> +}
> +
> +static void backtrace_suppression_test_count(struct kunit *test)
> +{
> + KUNIT_START_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 0);
> +
> + WARN(1, "suppressed");
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> +
> + WARN(1, "suppressed again");
> + KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 2);
> +
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +}
> +
> +static void backtrace_suppression_test_active_state(struct kunit *test)
> +{
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> + KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +
> + kunit_warning_suppress(test) {
> + KUNIT_EXPECT_TRUE(test, kunit_has_active_suppress_warning());
> + }
> +
> + KUNIT_EXPECT_FALSE(test, kunit_has_active_suppress_warning());
> +}
> +
> +static void backtrace_suppression_test_multi_scope(struct kunit *test)
> +{
> + struct kunit_suppressed_warning *sw1, *sw2;
> +
> + if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
> + kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
> +
> + sw1 = kunit_start_suppress_warning(test);
> + trigger_backtrace_warn_on();
> + WARN(1, "suppressed by sw1");
> + kunit_end_suppress_warning(test, sw1);
> +
> + sw2 = kunit_start_suppress_warning(test);
> + WARN(1, "suppressed by sw2");
> + kunit_end_suppress_warning(test, sw2);
> +
> + KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw1), 2);
> + KUNIT_EXPECT_EQ(test, kunit_suppressed_warning_count(sw2), 1);
> +}
> +
> +struct cross_kthread_data {
> + bool was_active;
> + struct completion done;
> +};
> +
> +static int cross_kthread_fn(void *data)
> +{
> + struct cross_kthread_data *d = data;
> +
> + d->was_active = kunit_has_active_suppress_warning();
> + complete(&d->done);
> + return 0;
> +}
> +
> +static void backtrace_suppression_test_cross_kthread(struct kunit *test)
> +{
> + struct cross_kthread_data data;
> + struct task_struct *task;
> +
> + init_completion(&data.done);
> +
> + KUNIT_START_SUPPRESSED_WARNING(test);
> +
> + task = kthread_run(cross_kthread_fn, &data, "kunit-cross-test");
> + KUNIT_ASSERT_FALSE(test, IS_ERR(task));
> + wait_for_completion(&data.done);
> +
> + KUNIT_END_SUPPRESSED_WARNING(test);
> +
> + KUNIT_EXPECT_FALSE(test, data.was_active);
> +}
> +
> +static struct kunit_case backtrace_suppression_test_cases[] = {
> + KUNIT_CASE(backtrace_suppression_test_warn_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_indirect),
> + KUNIT_CASE(backtrace_suppression_test_warn_multi),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_direct),
> + KUNIT_CASE(backtrace_suppression_test_warn_on_indirect),
> + KUNIT_CASE(backtrace_suppression_test_count),
> + KUNIT_CASE(backtrace_suppression_test_active_state),
> + KUNIT_CASE(backtrace_suppression_test_multi_scope),
> + KUNIT_CASE(backtrace_suppression_test_cross_kthread),
> + {}
> +};
> +
> +static struct kunit_suite backtrace_suppression_test_suite = {
> + .name = "backtrace-suppression-test",
> + .test_cases = backtrace_suppression_test_cases,
> +};
> +kunit_test_suites(&backtrace_suppression_test_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit test to verify warning backtrace suppression");
>
^ permalink raw reply
* Re: [PATCH v8 1/4] bug/kunit: Core support for suppressing warning backtraces
From: David Gow @ 2026-05-06 9:38 UTC (permalink / raw)
To: Albert Esteve, Arnd Bergmann, Brendan Higgins, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-riscv, linux-doc, peterz, Alessandro Carminati,
Guenter Roeck, Kees Cook
In-Reply-To: <20260504-kunit_add_support-v8-1-3e5957cdd235@redhat.com>
Le 04/05/2026 à 3:41 PM, Albert Esteve a écrit :
> From: Alessandro Carminati <acarmina@redhat.com>
>
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such intentionally generated warning backtraces are neither desirable
> nor useful for a number of reasons:
> - They can result in overlooked real problems.
> - A warning that suddenly starts to show up in unit tests needs to be
> investigated and has to be marked to be ignored, for example by
> adjusting filter scripts. Such filters are ad hoc because there is
> no real standard format for warnings. On top of that, such filter
> scripts would require constant maintenance.
>
> Solve the problem by providing a means to suppress warning backtraces
> originating from the current kthread while executing test code. Since
> each KUnit test runs in its own kthread, this effectively scopes
> suppression to the test that enabled it. Limit changes to generic code
> to the absolute minimum.
>
> Implementation details:
> Suppression is integrated into the existing KUnit hooks infrastructure
> in test-bug.h, reusing the kunit_running static branch for zero
> overhead when no tests are running.
>
> Suppression is checked at three points in the warning path:
> - In warn_slowpath_fmt(), the check runs before any output, fully
> suppressing both message and backtrace. This covers architectures
> without __WARN_FLAGS.
> - In __warn_printk(), the check suppresses the warning message text.
> This covers architectures that define __WARN_FLAGS but not their own
> __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where
> the message is printed before the trap enters __report_bug().
> - In __report_bug(), the check runs before __warn() is called,
> suppressing the backtrace and stack dump.
>
> To avoid double-counting on architectures where both __warn_printk()
> and __report_bug() run for the same warning, kunit_is_suppressed_warning()
> takes a bool parameter: true to increment the suppression counter
> (used in warn_slowpath_fmt and __report_bug), false to check only
> (used in __warn_printk).
>
> The suppression state is dynamically allocated via kunit_kzalloc() and
> tied to the KUnit test lifecycle via kunit_add_action(), ensuring
> automatic cleanup at test exit. Writer-side access to the global
> suppression list is serialized with a spinlock; readers use RCU.
>
> Three API forms are provided:
> - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for
> automatic teardown on scope exit, kunit_add_action() as safety net
> for abnormal exits (e.g. kthread_exit from failed assertions).
> Suppression handle is only accessible inside the block.
> - KUNIT_START/END_SUPPRESSED_WARNING(test): manual macros for larger
> blocks or when warning counts need to be checked after suppression
> ends. Limited to one pair per scope.
> - kunit_start/end_suppress_warning(test): direct functions returning
> an explicit handle, for retaining the handle within the test,
> or for cross-function usage.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
This looks pretty good to me, thanks.
Reviewed-by: David Gow <david@davidgow.net>
It's maybe slightly over-the-top to now have three different ways of
enabling warning suppression: I'd probably personally get rid of
KUNIT_START/END_SUPPRESSED_WARNING() if we had to lose one. But if
there's a real reason to prefer keeping all three, it's not actually a
problem to do so.
Regardless, this series is looking pretty ready to me. Let me know if
you're planning a v9, otherwise we'll take this when you're ready.
Cheers,
-- David
> include/kunit/test-bug.h | 25 +++++++++
> include/kunit/test.h | 138 +++++++++++++++++++++++++++++++++++++++++++++++
> kernel/panic.c | 15 +++++-
> lib/bug.c | 10 ++++
> lib/kunit/Makefile | 3 +-
> lib/kunit/bug.c | 115 +++++++++++++++++++++++++++++++++++++++
> lib/kunit/hooks-impl.h | 2 +
> 7 files changed, 305 insertions(+), 3 deletions(-)
>
> diff --git a/include/kunit/test-bug.h b/include/kunit/test-bug.h
> index 47aa8f21ccce8..6237e48ceadfd 100644
> --- a/include/kunit/test-bug.h
> +++ b/include/kunit/test-bug.h
> @@ -23,6 +23,7 @@ DECLARE_STATIC_KEY_FALSE(kunit_running);
> extern struct kunit_hooks_table {
> __printf(3, 4) void (*fail_current_test)(const char*, int, const char*, ...);
> void *(*get_static_stub_address)(struct kunit *test, void *real_fn_addr);
> + bool (*is_suppressed_warning)(bool count);
> } kunit_hooks;
>
> /**
> @@ -60,9 +61,33 @@ static inline struct kunit *kunit_get_current_test(void)
> } \
> } while (0)
>
> +/**
> + * kunit_is_suppressed_warning() - Check if warnings are being suppressed
> + * by the current KUnit test.
> + * @count: if true, increment the suppression counter on match.
> + *
> + * Returns true if the current task has active warning suppression.
> + * Uses the kunit_running static branch for zero overhead when no tests run.
> + *
> + * A single WARN*() may traverse multiple call sites in the warning path
> + * (e.g., __warn_printk() and __report_bug()). Pass @count = true at the
> + * primary suppression point to count each warning exactly once, and
> + * @count = false at secondary points to suppress output without
> + * inflating the count.
> + */
> +static inline bool kunit_is_suppressed_warning(bool count)
> +{
> + if (!static_branch_unlikely(&kunit_running))
> + return false;
> +
> + return kunit_hooks.is_suppressed_warning &&
> + kunit_hooks.is_suppressed_warning(count);
> +}
> +
> #else
>
> static inline struct kunit *kunit_get_current_test(void) { return NULL; }
> +static inline bool kunit_is_suppressed_warning(bool count) { return false; }
>
> #define kunit_fail_current_test(fmt, ...) do {} while (0)
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 9cd1594ab697d..f278ec028019c 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -1795,4 +1795,142 @@ do { \
> // include resource.h themselves if they need it.
> #include <kunit/resource.h>
>
> +/*
> + * Warning backtrace suppression API.
> + *
> + * Suppresses WARN*() backtraces on the current task while active. Three forms
> + * are provided, in order of convenience:
> + *
> + * - Scoped: kunit_warning_suppress(test) { ... }
> + * Suppression is active for the duration of the block. On normal exit,
> + * the for-loop increment deactivates suppression. On early exit (break,
> + * return, goto), the __cleanup attribute fires. On kthread_exit() (e.g.,
> + * a failed KUnit assertion), kunit_add_action() cleans up at test
> + * teardown. The suppression handle is only accessible inside the block,
> + * so warning counts must be checked before the block exits.
> + *
> + * - Manual macros: KUNIT_[START|END]_SUPPRESSED_WARNING(test)
> + * Suppression spans an explicit range in the same scope. kunit_add_action()
> + * guarantees cleanup even if KUNIT_END_SUPPRESSED_WARNING() is not reached.
> + * Prefer this form when suppressing warnings across a large block where
> + * extra indentation is undesirable, or when the warning count needs to be
> + * checked after suppression ends. Limited to one pair per scope.
> + *
> + * - Direct: kunit_start_suppress_warning() / kunit_end_suppress_warning()
> + * The underlying functions, returning an explicit handle pointer. Use
> + * when the handle needs to be retained (e.g., for post-suppression
> + * count checks) or passed across helper functions.
> + */
> +struct kunit_suppressed_warning;
> +
> +struct kunit_suppressed_warning *
> +kunit_start_suppress_warning(struct kunit *test);
> +void kunit_end_suppress_warning(struct kunit *test,
> + struct kunit_suppressed_warning *w);
> +int kunit_suppressed_warning_count(struct kunit_suppressed_warning *w);
> +void __kunit_suppress_auto_cleanup(struct kunit_suppressed_warning **wp);
> +bool kunit_has_active_suppress_warning(void);
> +
> +/**
> + * kunit_warning_suppress() - Suppress WARN*() backtraces for the duration
> + * of a block.
> + * @test: The test context object.
> + *
> + * Scoped form of the suppression API. Suppression starts when the block is
> + * entered and ends automatically when the block exits through any path. See
> + * the section comment above for the cleanup guarantees on each exit path.
> + * Fails the test if suppression is already active; nesting is not supported.
> + *
> + * The warning count can be checked inside the block via
> + * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(). The handle is not accessible
> + * after the block exits.
> + *
> + * Example::
> + *
> + * kunit_warning_suppress(test) {
> + * trigger_warning();
> + * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + * }
> + */
> +#define kunit_warning_suppress(test) \
> + for (struct kunit_suppressed_warning *__kunit_suppress \
> + __cleanup(__kunit_suppress_auto_cleanup) = \
> + kunit_start_suppress_warning(test); \
> + __kunit_suppress; \
> + kunit_end_suppress_warning(test, __kunit_suppress), \
> + __kunit_suppress = NULL)
> +
> +/**
> + * KUNIT_START_SUPPRESSED_WARNING() - Begin suppressing WARN*() backtraces.
> + * @test: The test context object.
> + *
> + * Manual form of the suppression API. Must be paired with
> + * KUNIT_END_SUPPRESSED_WARNING() in the same scope. See the section comment
> + * above for cleanup guarantees. Fails the test if suppression is already
> + * active; nesting is not supported. Limited to one pair per scope; use
> + * sequential kunit_warning_suppress() blocks or the direct function API
> + * when more than one suppression region is needed.
> + *
> + * Example::
> + *
> + * KUNIT_START_SUPPRESSED_WARNING(test);
> + * trigger_code_that_should_warn_once();
> + * KUNIT_END_SUPPRESSED_WARNING(test);
> + * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1);
> + */
> +#define KUNIT_START_SUPPRESSED_WARNING(test) \
> + struct kunit_suppressed_warning *__kunit_suppress = \
> + kunit_start_suppress_warning(test)
> +
> +/**
> + * KUNIT_END_SUPPRESSED_WARNING() - End suppressing WARN*() backtraces.
> + * @test: The test context object.
> + *
> + * Deactivates suppression started by KUNIT_START_SUPPRESSED_WARNING().
> + * The warning count remains readable via KUNIT_SUPPRESSED_WARNING_COUNT()
> + * after this call.
> + */
> +#define KUNIT_END_SUPPRESSED_WARNING(test) \
> + kunit_end_suppress_warning(test, __kunit_suppress)
> +
> +/**
> + * KUNIT_SUPPRESSED_WARNING_COUNT() - Returns the suppressed warning count.
> + *
> + * Returns the number of WARN*() calls suppressed since the current
> + * suppression block started, or 0 if the handle is NULL. Usable inside a
> + * kunit_warning_suppress() block or after KUNIT_END_SUPPRESSED_WARNING().
> + */
> +#define KUNIT_SUPPRESSED_WARNING_COUNT() \
> + kunit_suppressed_warning_count(__kunit_suppress)
> +
> +/**
> + * KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT() - Sets an expectation that the
> + * suppressed warning count equals
> + * @expected.
> + * @test: The test context object.
> + * @expected: an expression that evaluates to the expected warning count.
> + *
> + * Sets an expectation that the number of suppressed WARN*() calls equals
> + * @expected. This is semantically equivalent to
> + * KUNIT_EXPECT_EQ(@test, KUNIT_SUPPRESSED_WARNING_COUNT(), @expected).
> + * See KUNIT_EXPECT_EQ() for more information.
> + */
> +#define KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, expected) \
> + KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), expected)
> +
> +/**
> + * KUNIT_ASSERT_SUPPRESSED_WARNING_COUNT() - Sets an assertion that the
> + * suppressed warning count equals
> + * @expected.
> + * @test: The test context object.
> + * @expected: an expression that evaluates to the expected warning count.
> + *
> + * Sets an assertion that the number of suppressed WARN*() calls equals
> + * @expected. This is the same as KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(),
> + * except it causes an assertion failure (see KUNIT_ASSERT_TRUE()) when the
> + * assertion is not met.
> + */
> +#define KUNIT_ASSERT_SUPPRESSED_WARNING_COUNT(test, expected) \
> + KUNIT_ASSERT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), expected)
> +
> #endif /* _KUNIT_TEST_H */
> diff --git a/kernel/panic.c b/kernel/panic.c
> index c78600212b6c1..697d8ca054bef 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -39,6 +39,7 @@
> #include <linux/sys_info.h>
> #include <trace/events/error_report.h>
> #include <asm/sections.h>
> +#include <kunit/test-bug.h>
>
> #define PANIC_TIMER_STEP 100
> #define PANIC_BLINK_SPD 18
> @@ -1080,9 +1081,14 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
> void warn_slowpath_fmt(const char *file, int line, unsigned taint,
> const char *fmt, ...)
> {
> - bool rcu = warn_rcu_enter();
> + bool rcu;
> struct warn_args args;
>
> + if (kunit_is_suppressed_warning(true))
> + return;
> +
> + rcu = warn_rcu_enter();
> +
> pr_warn(CUT_HERE);
>
> if (!fmt) {
> @@ -1102,9 +1108,14 @@ EXPORT_SYMBOL(warn_slowpath_fmt);
> #else
> void __warn_printk(const char *fmt, ...)
> {
> - bool rcu = warn_rcu_enter();
> + bool rcu;
> va_list args;
>
> + if (kunit_is_suppressed_warning(false))
> + return;
> +
> + rcu = warn_rcu_enter();
> +
> pr_warn(CUT_HERE);
>
> va_start(args, fmt);
> diff --git a/lib/bug.c b/lib/bug.c
> index 623c467a8b76c..a5cebde554ed8 100644
> --- a/lib/bug.c
> +++ b/lib/bug.c
> @@ -48,6 +48,7 @@
> #include <linux/rculist.h>
> #include <linux/ftrace.h>
> #include <linux/context_tracking.h>
> +#include <kunit/test-bug.h>
>
> extern struct bug_entry __start___bug_table[], __stop___bug_table[];
>
> @@ -223,6 +224,15 @@ static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long buga
> no_cut = bug->flags & BUGFLAG_NO_CUT_HERE;
> has_args = bug->flags & BUGFLAG_ARGS;
>
> +#ifdef CONFIG_KUNIT
> + /*
> + * Before the once logic so suppressed warnings do not consume
> + * the single-fire budget of WARN_ON_ONCE().
> + */
> + if (warning && kunit_is_suppressed_warning(true))
> + return BUG_TRAP_TYPE_WARN;
> +#endif
> +
> if (warning && once) {
> if (done)
> return BUG_TRAP_TYPE_WARN;
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index 656f1fa35abcc..4592f9d0aa8dd 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -10,7 +10,8 @@ kunit-objs += test.o \
> executor.o \
> attributes.o \
> device.o \
> - platform.o
> + platform.o \
> + bug.o
>
> ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
> kunit-objs += debugfs.o
> diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
> new file mode 100644
> index 0000000000000..b0b6778d7399a
> --- /dev/null
> +++ b/lib/kunit/bug.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit helpers for backtrace suppression
> + *
> + * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
> + * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#include <kunit/resource.h>
> +#include <linux/export.h>
> +#include <linux/rculist.h>
> +#include <linux/sched.h>
> +#include <linux/spinlock.h>
> +
> +#include "hooks-impl.h"
> +
> +struct kunit_suppressed_warning {
> + struct list_head node;
> + struct task_struct *task;
> + struct kunit *test;
> + int counter;
> +};
> +
> +static LIST_HEAD(suppressed_warnings);
> +static DEFINE_SPINLOCK(suppressed_warnings_lock);
> +
> +static void kunit_suppress_warning_remove(struct kunit_suppressed_warning *w)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&suppressed_warnings_lock, flags);
> + list_del_rcu(&w->node);
> + spin_unlock_irqrestore(&suppressed_warnings_lock, flags);
> + synchronize_rcu(); /* Wait for readers to finish */
> +}
> +
> +KUNIT_DEFINE_ACTION_WRAPPER(kunit_suppress_warning_cleanup,
> + kunit_suppress_warning_remove,
> + struct kunit_suppressed_warning *);
> +
> +bool kunit_has_active_suppress_warning(void)
> +{
> + return __kunit_is_suppressed_warning_impl(false);
> +}
> +EXPORT_SYMBOL_GPL(kunit_has_active_suppress_warning);
> +
> +struct kunit_suppressed_warning *
> +kunit_start_suppress_warning(struct kunit *test)
> +{
> + struct kunit_suppressed_warning *w;
> + unsigned long flags;
> + int ret;
> +
> + if (kunit_has_active_suppress_warning()) {
> + KUNIT_FAIL(test, "Another suppression block is already active");
> + return NULL;
> + }
> +
> + w = kunit_kzalloc(test, sizeof(*w), GFP_KERNEL);
> + if (!w)
> + return NULL;
> +
> + w->task = current;
> + w->test = test;
> +
> + spin_lock_irqsave(&suppressed_warnings_lock, flags);
> + list_add_rcu(&w->node, &suppressed_warnings);
> + spin_unlock_irqrestore(&suppressed_warnings_lock, flags);
> +
> + ret = kunit_add_action_or_reset(test,
> + kunit_suppress_warning_cleanup, w);
> + if (ret)
> + return NULL;
> +
> + return w;
> +}
> +EXPORT_SYMBOL_GPL(kunit_start_suppress_warning);
> +
> +void kunit_end_suppress_warning(struct kunit *test,
> + struct kunit_suppressed_warning *w)
> +{
> + if (!w)
> + return;
> + kunit_release_action(test, kunit_suppress_warning_cleanup, w);
> +}
> +EXPORT_SYMBOL_GPL(kunit_end_suppress_warning);
> +
> +void __kunit_suppress_auto_cleanup(struct kunit_suppressed_warning **wp)
> +{
> + if (*wp)
> + kunit_end_suppress_warning((*wp)->test, *wp);
> +}
> +EXPORT_SYMBOL_GPL(__kunit_suppress_auto_cleanup);
> +
> +int kunit_suppressed_warning_count(struct kunit_suppressed_warning *w)
> +{
> + return w ? w->counter : 0;
> +}
> +EXPORT_SYMBOL_GPL(kunit_suppressed_warning_count);
> +
> +bool __kunit_is_suppressed_warning_impl(bool count)
> +{
> + struct kunit_suppressed_warning *w;
> +
> + guard(rcu)();
> + list_for_each_entry_rcu(w, &suppressed_warnings, node) {
> + if (w->task == current) {
> + if (count)
> + w->counter++;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> diff --git a/lib/kunit/hooks-impl.h b/lib/kunit/hooks-impl.h
> index 4e71b2d0143ba..d8720f2616925 100644
> --- a/lib/kunit/hooks-impl.h
> +++ b/lib/kunit/hooks-impl.h
> @@ -19,6 +19,7 @@ void __printf(3, 4) __kunit_fail_current_test_impl(const char *file,
> int line,
> const char *fmt, ...);
> void *__kunit_get_static_stub_address_impl(struct kunit *test, void *real_fn_addr);
> +bool __kunit_is_suppressed_warning_impl(bool count);
>
> /* Code to set all of the function pointers. */
> static inline void kunit_install_hooks(void)
> @@ -26,6 +27,7 @@ static inline void kunit_install_hooks(void)
> /* Install the KUnit hook functions. */
> kunit_hooks.fail_current_test = __kunit_fail_current_test_impl;
> kunit_hooks.get_static_stub_address = __kunit_get_static_stub_address_impl;
> + kunit_hooks.is_suppressed_warning = __kunit_is_suppressed_warning_impl;
> }
>
> #endif /* _KUNIT_HOOKS_IMPL_H */
>
^ permalink raw reply
* RE: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-05-06 9:17 UTC (permalink / raw)
To: Jonathan Cameron, Radu Sabau via B4 Relay
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
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@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260505152828.61f40411@jic23-huawei>
> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Tuesday, May 5, 2026 5:28 PM
> To: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> Cc: Sabau, Radu bogdan <Radu.Sabau@analog.com>; Lars-Peter Clausen
> <lars@metafoo.de>; Hennerich, Michael <Michael.Hennerich@analog.com>;
> David Lechner <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>;
> Andy Shevchenko <andy@kernel.org>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Uwe Kleine-König <ukleinek@kernel.org>; Liam
> Girdwood <lgirdwood@gmail.com>; Mark Brown <broonie@kernel.org>; Linus
> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Philipp
> Zabel <p.zabel@pengutronix.de>; Jonathan Corbet <corbet@lwn.net>; Shuah
> Khan <skhan@linuxfoundation.org>; linux-iio@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> pwm@vger.kernel.org; linux-gpio@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCH v9 4/6] iio: adc: ad4691: add SPI offload support
>
> [External]
>
> On Thu, 30 Apr 2026 13:16:46 +0300
> Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> wrote:
>
> > From: Radu Sabau <radu.sabau@analog.com>
> >
> > Add SPI offload support to enable DMA-based, CPU-independent data
> > acquisition using the SPI Engine offload framework.
> >
> > When an SPI offload is available (devm_spi_offload_get() succeeds),
> > the driver registers a DMA engine IIO buffer and uses dedicated buffer
> > setup operations. If no offload is available the existing software
> > triggered buffer path is used unchanged.
> >
> > Both CNV Burst Mode and Manual Mode support offload, but use different
> > trigger mechanisms:
> >
> > CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY
> > signal on the GP pin specified by the trigger-source consumer reference
> > in the device tree (one cell = GP pin number 0-3). For this mode the
> > driver acts as both an SPI offload consumer (DMA RX stream, message
> > optimization) and a trigger source provider: it registers the
> > GP/DATA_READY output via devm_spi_offload_trigger_register() so the
> > offload framework can match the '#trigger-source-cells' phandle and
> > automatically fire the SPI Engine DMA transfer at end-of-conversion.
> >
> > Manual Mode: the SPI Engine is triggered by a periodic trigger at
> > the configured sampling frequency. The pre-built SPI message uses
> > the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued
> > for N active channels (the first result is discarded as garbage from
> > the pipeline flush) and the remaining N results are captured by DMA.
> >
> > All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> > The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared
> > between the software triggered-buffer and offload paths; no separate
> > scan_type or channel array is needed for the offload case. The
> > ad4691_manual_channels[] array introduced in the triggered-buffer
> > commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> > attribute, which is not applicable in Manual Mode.
> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> In general have a read through Sashiko reviews once they come in and
> if you agree with them reply to your own patches to say what you are
> changing.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260430-
> ad4692-multichannel-sar-adc-driver-v9-0-
> 33e439e4fb87*40analog.com__;IyU!!A3Ni8CS0y2Y!-
> G5xU6m5PVXdQJCRVp_OOtLEM0gRiLsoZigLcBOrGi00oHLlyYgtxQAtx7azQuyZ
> Bkv8I3Cgy2WoEg$
> No perfect but another one in here is something I missed completely.
>
> A few of them called out here but please make sure you've addressed them
> all or established them to be false (which happens!)
>
Will have a look at Sashiko review in order to address everything in the next
version.
I will also reply to each patch and mention the change, argue to why I think the
raised concern could be false and perhaps have a follow-up discussion here.
^ permalink raw reply
* Re: [PATCH 8/8] drm/panthor: Expose protected rendering features
From: Boris Brezillon @ 2026-05-06 9:14 UTC (permalink / raw)
To: Ketil Johnsen
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Liviu Dudau, 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
In-Reply-To: <20260505140516.1372388-9-ketil.johnsen@arm.com>
On Tue, 5 May 2026 16:05:14 +0200
Ketil Johnsen <ketil.johnsen@arm.com> wrote:
> Add query for protected rendering capability.
> Add flag to group creation to specify need for protected rendering.
> Bump panthor version number.
>
> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 21 +++++++++++-
> drivers/gpu/drm/panthor/panthor_sched.c | 21 +++++++-----
> include/uapi/drm/panthor_drm.h | 45 +++++++++++++++++++++++--
> 3 files changed, 76 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c
> index 73fc983dc9b44..817df17f31f15 100644
> --- a/drivers/gpu/drm/panthor/panthor_drv.c
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -177,6 +177,7 @@ panthor_get_uobj_array(const struct drm_panthor_obj_array *in, u32 min_stride,
> PANTHOR_UOBJ_DECL(struct drm_panthor_csif_info, pad), \
> PANTHOR_UOBJ_DECL(struct drm_panthor_timestamp_info, current_timestamp), \
> PANTHOR_UOBJ_DECL(struct drm_panthor_group_priorities_info, pad), \
> + PANTHOR_UOBJ_DECL(struct drm_panthor_protected_info, features), \
> PANTHOR_UOBJ_DECL(struct drm_panthor_sync_op, timeline_value), \
> PANTHOR_UOBJ_DECL(struct drm_panthor_queue_submit, syncs), \
> PANTHOR_UOBJ_DECL(struct drm_panthor_queue_create, ringbuf_size), \
> @@ -928,12 +929,20 @@ static void panthor_query_group_priorities_info(struct drm_file *file,
> }
> }
>
> +static void panthor_query_protected_info(struct panthor_device *ptdev,
> + struct drm_panthor_protected_info *arg)
> +{
> + arg->features =
> + ptdev->protm.heap ? DRM_PANTHOR_PROTECTED_FEATURE_BASIC : 0;
> +}
> +
> static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct drm_file *file)
> {
> struct panthor_device *ptdev = container_of(ddev, struct panthor_device, base);
> struct drm_panthor_dev_query *args = data;
> struct drm_panthor_timestamp_info timestamp_info;
> struct drm_panthor_group_priorities_info priorities_info;
> + struct drm_panthor_protected_info protected_info;
> int ret;
>
> if (!args->pointer) {
> @@ -954,6 +963,10 @@ static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct d
> args->size = sizeof(priorities_info);
> return 0;
>
> + case DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO:
> + args->size = sizeof(protected_info);
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -984,6 +997,11 @@ static int panthor_ioctl_dev_query(struct drm_device *ddev, void *data, struct d
> panthor_query_group_priorities_info(file, &priorities_info);
> return PANTHOR_UOBJ_SET(args->pointer, args->size, priorities_info);
>
> + case DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO:
> + panthor_query_protected_info(ptdev, &protected_info);
> + return PANTHOR_UOBJ_SET(args->pointer, args->size,
> + protected_info);
> +
> default:
> return -EINVAL;
> }
> @@ -1779,6 +1797,7 @@ static void panthor_debugfs_init(struct drm_minor *minor)
> * - adds DRM_IOCTL_PANTHOR_BO_QUERY_INFO ioctl
> * - adds drm_panthor_gpu_info::selected_coherency
> * - 1.8 - extends DEV_QUERY_TIMESTAMP_INFO with flags
> + * - 1.9 - adds DEV_QUERY_PROTECTED_INFO query
It's adding more than just DEV_QUERY_PROTECTED_INFO (it also adds a new
flags field to group_create and a flag that tells that the group intends
to use protected mode).
> */
> static const struct drm_driver panthor_drm_driver = {
> .driver_features = DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
> @@ -1792,7 +1811,7 @@ static const struct drm_driver panthor_drm_driver = {
> .name = "panthor",
> .desc = "Panthor DRM driver",
> .major = 1,
> - .minor = 8,
> + .minor = 9,
>
> .gem_prime_import_sg_table = panthor_gem_prime_import_sg_table,
> .gem_prime_import = panthor_gem_prime_import,
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index acb04250c7def..0e8a1059de589 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -3868,6 +3868,7 @@ static void add_group_kbo_sizes(struct panthor_device *ptdev,
> }
>
> #define MAX_GROUPS_PER_POOL 128
> +#define GROUP_CREATE_FLAGS DRM_PANTHOR_GROUP_CREATE_PROTECTED
>
> int panthor_group_create(struct panthor_file *pfile,
> const struct drm_panthor_group_create *group_args,
> @@ -3882,10 +3883,10 @@ int panthor_group_create(struct panthor_file *pfile,
> u32 gid, i, suspend_size;
> int ret;
>
> - if (group_args->pad)
> + if (group_args->priority >= PANTHOR_CSG_PRIORITY_COUNT)
> return -EINVAL;
>
> - if (group_args->priority >= PANTHOR_CSG_PRIORITY_COUNT)
> + if (group_args->flags & ~GROUP_CREATE_FLAGS)
> return -EINVAL;
>
> if ((group_args->compute_core_mask & ~ptdev->gpu_info.shader_present) ||
> @@ -3937,12 +3938,16 @@ int panthor_group_create(struct panthor_file *pfile,
> goto err_put_group;
> }
>
> - suspend_size = csg_iface->control->protm_suspend_size;
> - group->protm_suspend_buf = panthor_fw_alloc_protm_suspend_buf_mem(ptdev, suspend_size);
> - if (IS_ERR(group->protm_suspend_buf)) {
> - ret = PTR_ERR(group->protm_suspend_buf);
> - group->protm_suspend_buf = NULL;
> - goto err_put_group;
> + if (group_args->flags & DRM_PANTHOR_GROUP_CREATE_PROTECTED) {
> + suspend_size = csg_iface->control->protm_suspend_size;
> + group->protm_suspend_buf =
> + panthor_fw_alloc_protm_suspend_buf_mem(ptdev,
> + suspend_size);
> + if (IS_ERR(group->protm_suspend_buf)) {
> + ret = PTR_ERR(group->protm_suspend_buf);
> + group->protm_suspend_buf = NULL;
> + goto err_put_group;
> + }
> }
>
> group->syncobjs = panthor_kernel_bo_create(ptdev, group->vm,
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 0e455d91e77d4..914110003bcd1 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -253,6 +253,11 @@ enum drm_panthor_dev_query_type {
> * @DRM_PANTHOR_DEV_QUERY_GROUP_PRIORITIES_INFO: Query allowed group priorities information.
> */
> DRM_PANTHOR_DEV_QUERY_GROUP_PRIORITIES_INFO,
> +
> + /**
> + * @DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO: Query supported protected rendering information.
> + */
> + DRM_PANTHOR_DEV_QUERY_PROTECTED_INFO,
> };
>
> /**
> @@ -504,6 +509,28 @@ struct drm_panthor_group_priorities_info {
> __u8 pad[3];
> };
>
> +/**
> + * enum drm_panthor_protected_feature_flags - Supported protected rendering features
Protected rendering is a bit vague, especially since it's usually
referred as protected memory/content in graphics APIs. Maybe we should
have a short paragraph explaining what we mean by that (access of
protected memory from the GPU).
> + *
> + * Place new types at the end, don't re-order, don't remove or replace.
> + */
> +enum drm_panthor_protected_feature_flags {
> + /** @DRM_PANTHOR_PROTECTED_FEATURE_BASIC: Protected rendering available */
> + DRM_PANTHOR_PROTECTED_FEATURE_BASIC = 1 << 0,
I'm not a huge fan of this _BASIC specifier, since it doesn't
tell much about the actual implementation, and what the UMD
has to do to access protected memory from the GPU. Given the
feature/CS-instruction is named _PROTM, I'd go for
/**
* @DRM_PANTHOR_PROTECTED_FEATURE_PROTM: Protected memory access
* based on PROTM CS instructions
*
* This is currently the only option to access protected
* memory from the GPU. Other modes or advanced features might
* be added at some point.
*/
DRM_PANTHOR_PROTECTED_FEATURE_PROTM = 1 << 0,
> +};
> +
> +/**
> + * struct drm_panthor_protected_info - protected support information
> + *
> + * Structure grouping all queryable information relating to the allowed group priorities.
> + */
> +struct drm_panthor_protected_info {
> + /**
> + * @features: Combination of enum drm_panthor_protected_feature_flags flags.
> + */
> + __u32 features;
> +};
> +
> /**
> * struct drm_panthor_dev_query - Arguments passed to DRM_PANTHOR_IOCTL_DEV_QUERY
> */
> @@ -843,6 +870,18 @@ enum drm_panthor_group_priority {
> PANTHOR_GROUP_PRIORITY_REALTIME,
> };
>
> +/**
> + * enum drm_panthor_group_create_flags - Group create flags
> + */
> +enum drm_panthor_group_create_flags {
s/drm_panthor_group_create_flags/drm_panthor_group_feature_flags/
> + /**
> + * @DRM_PANTHOR_GROUP_CREATE_PROTECTED: Support protected mode
> + *
> + * Enable protected rendering work to be executed on this group.
> + */
> + DRM_PANTHOR_GROUP_CREATE_PROTECTED = 1 << 0,
I'd go directly DRM_PANTHOR_GROUP_FEATURE_PROTM, since this is the
instruction the group will use to enter protected mode. If we ever have
multiple ways to do protected rendering, I guess it would materialize
as a different flag, allowing the KMD to know exactly the way
protected rendering is going to be done.
> +};
> +
> /**
> * struct drm_panthor_group_create - Arguments passed to DRM_IOCTL_PANTHOR_GROUP_CREATE
> */
> @@ -877,8 +916,10 @@ struct drm_panthor_group_create {
> /** @priority: Group priority (see enum drm_panthor_group_priority). */
> __u8 priority;
>
> - /** @pad: Padding field, MBZ. */
> - __u32 pad;
> + /**
> + * @flags: Flags. Must be a combination of drm_panthor_group_create_flags flags.
> + */
> + __u32 flags;
>
> /**
> * @compute_core_mask: Mask encoding cores that can be used for compute jobs.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: maple_tree: Point out constraint when using xa_{mk, to}_value
From: Wei-Lin Chang @ 2026-05-06 9:07 UTC (permalink / raw)
To: Matthew Wilcox
Cc: maple-tree, linux-mm, linux-doc, linux-kernel, Liam R . Howlett,
Alice Ryhl, Andrew Ballance, Jonathan Corbet, Shuah Khan
In-Reply-To: <afkCZkHcn58S3GLD@casper.infradead.org>
On Mon, May 04, 2026 at 09:32:38PM +0100, Matthew Wilcox wrote:
> On Mon, May 04, 2026 at 05:57:45PM +0100, Wei-Lin Chang wrote:
> > Using xa_{mk, to}_value when storing values loses the information of
> > the top bit from the left shift, point that out in the doc.
>
> I don't know if that's necessary ... it's obvious when looking at the
> function:
>
> static inline void *xa_mk_value(unsigned long v)
> {
> WARN_ON((long)v < 0);
> return (void *)((v << 1) | 1);
> }
>
> and if you ignore it, you'll find out. But if this needs to be
> documented anywhere, it's in the kernel-doc for xa_mk_value()
> and not in the maple tree docs.
Yeah this makes sense, thanks for having a look.
Thanks,
Wei-Lin Chang
^ permalink raw reply
* Re: [PATCH v4 10/27] mtd: spi-nor: swp: Create a helper that writes SR, CR and checks
From: Michael Walle @ 2026-05-06 9:06 UTC (permalink / raw)
To: Pratyush Yadav, Miquel Raynal
Cc: Takahiro Kuwano, Richard Weinberger, Vignesh Raghavendra,
Jonathan Corbet, Sean Anderson, Thomas Petazzoni, Steam Lin,
linux-mtd, linux-kernel, linux-doc
In-Reply-To: <2vxzbjet266g.fsf@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Tue May 5, 2026 at 6:05 PM CEST, Pratyush Yadav wrote:
> On Fri, Apr 03 2026, Miquel Raynal wrote:
>
>> There are many helpers already to either read and/or write SR and/or CR,
>> as well as sometimes check the returned values. In order to be able to
>> switch from a 1 byte status register to a 2 bytes status register while
>> keeping the same level of verification, let's introduce a new helper
>> that writes them both (atomically) and then reads them back (separated)
>> to compare the values.
>>
>> In case 2 bytes registers are not supported, we still have the usual
>> fallback available in the helper being exported to the rest of the core.
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> I'm confused. Doesn't spi_nor_write_16bit_sr_and_check() do the same
> thing? How are these two different?
So I've never come around to finish reviewing this series due to
personal reasons, but here are my remarks. Personally, I really
don't like all these multiple helpers doing almost the same thing.
But it is what is is for now.
Back when reviewing this series, I've digged into this and it mostly
evolve around how to enable the QE bit, that is defined in the 15th
SFDP DWORD. One could see how we could consolidate all the status
register handling in one function which are then called by the
different (specified) quad_enable helpers.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* RE: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-05-06 9:01 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Cameron
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
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@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <afrs9ZN3moV157fR@ashevche-desk.local>
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
> Sent: Wednesday, May 6, 2026 10:26 AM
...
>
> > > > > > > + for (i = 0; i < ARRAY_SIZE(ad4691_gp_names); i++) {
> > > > > > > + irq = fwnode_irq_get_byname(dev_fwnode(dev),
> > > > > > > + ad4691_gp_names[i]);
> > > > > > > + if (irq > 0)
> > > > > > > + break;
> > > > > >
> > > > > > This is problematic in case the above returns EPROBE_DEFER. Can you
> confirm
> > > > > > it
> > > > > > may not ever happen? (Note, I don't know the answer.)
> > > > >
> > > > > You are right, thanks for this!
> > > > I'm missing something. Why is that a problem? Driver will return
> > > > the error and a dev_err_probe() is used so it won't print anything.
> > > > So probe will fail which is exactly what we want.
> > >
> > > If there are two IRQs and the first one is probe deferred and second returns
> > > an error, we return that error instead of the deferral probe.
> > >
> > > May be I missed something, but I have no idea how in this case it may
> return
> > > the first error code in such a case.
> > Ah. Indeed. I completely misread the code. if (irq) would do the job to fix
> this.
>
> Not really, as we are only concerned about deferred probe.
>
> if (irq > 0 || irq == -EPROBE_DEFER)
> break;
>
> will do the job. But again, please double check that the
> fwnode_irq_get_byname() is even capable of returning deferral probe
> (probably yes as my weak memory tells me).
>
> --
Hi everyone,
I checked and fwnode_irq_get_byname() can indeed return deferral probe
and the fix I had in mind is like the above.
Thank you all for looking into this,
Radu
^ permalink raw reply
* Re: [PATCH v4 16/27] mtd: spi-nor: Create a local SR cache
From: Miquel Raynal @ 2026-05-06 8:59 UTC (permalink / raw)
To: Michael Walle
Cc: Pratyush Yadav, Takahiro Kuwano, Richard Weinberger,
Vignesh Raghavendra, Jonathan Corbet, Sean Anderson,
Thomas Petazzoni, Steam Lin, linux-mtd, linux-kernel, linux-doc
In-Reply-To: <DIBGRTZ3BUEE.1GIAWVBNNXUY5@kernel.org>
>>> In order to be able to generate debugfs output without having to
>>> actually reach the flash, create a SPI NOR local cache of the status
>>> registers. What matters in our case are all the bits related to sector
>>> locking. As such, in order to make it clear that this cache is not
>>> intended to be used anywhere else, we zero the irrelevant bits.
>>>
>>> The cache is initialized once during the early init, and then maintained
>>> every time the write protection scheme is updated.
>>
>> What is the reason for doing so? Do the reads have side effects?
>
> I don't like that a debugfs read will issue a SPI transaction, at
> least not these informational files.
>
> If we ever want to access the registers in the flash, we should have
> a separate debugfs file/interface.
Indeed, the intent was to be able to generate complete debugfs output
without any physical access.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH v4 10/27] mtd: spi-nor: swp: Create a helper that writes SR, CR and checks
From: Miquel Raynal @ 2026-05-06 8:57 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Michael Walle, Takahiro Kuwano, Richard Weinberger,
Vignesh Raghavendra, Jonathan Corbet, Sean Anderson,
Thomas Petazzoni, Steam Lin, linux-mtd, linux-kernel, linux-doc
In-Reply-To: <2vxzbjet266g.fsf@kernel.org>
Hi Pratyush,
On 05/05/2026 at 18:05:11 +02, Pratyush Yadav <pratyush@kernel.org> wrote:
> On Fri, Apr 03 2026, Miquel Raynal wrote:
>
>> There are many helpers already to either read and/or write SR and/or CR,
>> as well as sometimes check the returned values. In order to be able to
>> switch from a 1 byte status register to a 2 bytes status register while
>> keeping the same level of verification, let's introduce a new helper
>> that writes them both (atomically) and then reads them back (separated)
>> to compare the values.
>>
>> In case 2 bytes registers are not supported, we still have the usual
>> fallback available in the helper being exported to the rest of the core.
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> I'm confused. Doesn't spi_nor_write_16bit_sr_and_check() do the same
> thing? How are these two different?
The prototype says it all:
static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8 sr1)
It writes sr1, and you can give only sr1. But because it is a 16bit
write, it also writes cr/sr2 on which the caller has no control. This
helper is actually very chip specific, because that is one way among the
different SFDP QER field possibilities to write the QE bit.
Giving more control to the caller, including the position of the QE bit
as well as the possibility to set other bits in cr/sr2 is what is
intended in this helper. This is an internal helper btw, only the core
uses it.
Note: I will send a v5 with an update of the naming convention because
it is not super satisfying. I already have that patch, and I was waiting
for this series to get in for sending the follow-up improvements, but if
we go for a new iteration I can include these patches in. There will be
a fix of the QE bit handling in the swp.c core I am touching as well (I
forgot to handle a case).
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH 7/8] drm/panthor: Add support for entering and exiting protected mode
From: Boris Brezillon @ 2026-05-06 8:51 UTC (permalink / raw)
To: Ketil Johnsen
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Liviu Dudau, 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, Paul Toadere,
Samuel Percival
In-Reply-To: <20260505140516.1372388-8-ketil.johnsen@arm.com>
On Tue, 5 May 2026 16:05:13 +0200
Ketil Johnsen <ketil.johnsen@arm.com> wrote:
Here comes the second part of the review :-).
> diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
> index 2ab444ee8c710..e93042eaf3fc8 100644
> --- a/drivers/gpu/drm/panthor/panthor_gpu.c
> +++ b/drivers/gpu/drm/panthor/panthor_gpu.c
> @@ -100,8 +100,11 @@ static void panthor_gpu_irq_handler(struct panthor_device *ptdev, u32 status)
> fault_status, panthor_exception_name(ptdev, fault_status & 0xFF),
> address);
> }
> - if (status & GPU_IRQ_PROTM_FAULT)
> + if (status & GPU_IRQ_PROTM_FAULT) {
> drm_warn(&ptdev->base, "GPU Fault in protected mode\n");
> + panthor_gpu_disable_protm_fault_interrupt(ptdev);
It's only used in a single place, so I'd just inline the content of
panthor_gpu_disable_protm_fault_interrupt() here. Also, I think
panthor_gpu_disable_protm_fault_interrupt() is not taking the right
lock (see below).
> + panthor_device_schedule_reset(ptdev);
> + }
>
> spin_lock(&ptdev->gpu->reqs_lock);
> if (status & ptdev->gpu->pending_reqs) {
> @@ -367,6 +370,10 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev)
> unsigned long flags;
>
> spin_lock_irqsave(&ptdev->gpu->reqs_lock, flags);
> +
> + /** Re-enable the protm_irq_fault when reset is complete */
> + ptdev->gpu->irq.mask |= GPU_IRQ_PROTM_FAULT;
panthor_irq::mask should only be modified with the
panthor_irq::mask_lock held. Besides, we have a helper for
that:
panthor_gpu_irq_enable_events(&ptdev->gpu->irq, GPU_IRQ_PROTM_FAULT);
> +
> if (!drm_WARN_ON(&ptdev->base,
> ptdev->gpu->pending_reqs & GPU_IRQ_RESET_COMPLETED)) {
> ptdev->gpu->pending_reqs |= GPU_IRQ_RESET_COMPLETED;
> @@ -427,3 +434,8 @@ void panthor_gpu_resume(struct panthor_device *ptdev)
> panthor_hw_l2_power_on(ptdev);
> }
>
> +void panthor_gpu_disable_protm_fault_interrupt(struct panthor_device *ptdev)
> +{
> + scoped_guard(spinlock_irqsave, &ptdev->gpu->reqs_lock)
> + ptdev->gpu->irq.mask &= ~GPU_IRQ_PROTM_FAULT;
Same problem with wrong lock being taken to modify the mask, and
panthor_gpu_irq_disable_events() probably being a better option?
> +}
> diff --git a/drivers/gpu/drm/panthor/panthor_gpu.h b/drivers/gpu/drm/panthor/panthor_gpu.h
> index 12c263a399281..ca66c73f543e6 100644
> --- a/drivers/gpu/drm/panthor/panthor_gpu.h
> +++ b/drivers/gpu/drm/panthor/panthor_gpu.h
> @@ -54,4 +54,10 @@ int panthor_gpu_soft_reset(struct panthor_device *ptdev);
> void panthor_gpu_power_changed_off(struct panthor_device *ptdev);
> int panthor_gpu_power_changed_on(struct panthor_device *ptdev);
>
> +/**
> + * panthor_gpu_disable_protm_fault_interrupt() - Disable GPU_PROTECTED_FAULT interrupt
> + * @ptdev: Device.
> + */
> +void panthor_gpu_disable_protm_fault_interrupt(struct panthor_device *ptdev);
> +
> #endif
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index 07f54176ec1bf..702f537905b56 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -31,6 +31,7 @@
> #include <linux/sizes.h>
>
> #include "panthor_device.h"
> +#include "panthor_fw.h"
> #include "panthor_gem.h"
> #include "panthor_gpu.h"
> #include "panthor_heap.h"
> @@ -1704,8 +1705,12 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
> if (drm_WARN_ON(&ptdev->base, vm->locked_region.size))
> return -EINVAL;
>
> + down_read(&ptdev->protm.lock);
> +
> mutex_lock(&ptdev->mmu->as.slots_lock);
> if (vm->as.id >= 0 && size) {
> + panthor_fw_protm_exit_sync(ptdev);
> +
> /* Lock the region that needs to be updated */
> gpu_write64(ptdev, AS_LOCKADDR(vm->as.id),
> pack_region_range(ptdev, &start, &size));
> @@ -1720,6 +1725,9 @@ static int panthor_vm_lock_region(struct panthor_vm *vm, u64 start, u64 size)
> }
> mutex_unlock(&ptdev->mmu->as.slots_lock);
>
> + if (ret)
> + up_read(&ptdev->protm.lock);
Let's try to keep the locked section local to a function: the protm.lock
should, IMHO, be taken/released in panthor_vm_exec_op(). If we go for
that, this also makes the panthor_vm_lock_region() vs
panthor_vm_expand_locked_region() distinction useless, though it's
probably fine to keep it for clarity.
> +
> return ret;
> }
>
> @@ -1805,6 +1813,8 @@ static void panthor_vm_unlock_region(struct panthor_vm *vm)
> vm->locked_region.start = 0;
> vm->locked_region.size = 0;
> mutex_unlock(&ptdev->mmu->as.slots_lock);
> +
> + up_read(&ptdev->protm.lock);
> }
>
> static void panthor_mmu_irq_handler(struct panthor_device *ptdev, u32 status)
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index 987072bd867c4..acb04250c7def 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -308,6 +308,15 @@ struct panthor_scheduler {
> */
> struct list_head stopped_groups;
> } reset;
> +
> + /** @protm: Protected mode related fields. */
> + struct {
> + /** @protected_mode: True if GPU is in protected mode. */
> + bool protected_mode;
nit: s/protected_mode/enabled/s. But do we even need that boolean?
Isn't active_group != NULL providing the same info?
> +
> + /** @active_group: The active protected group. */
> + struct panthor_group *active_group;
> + } protm;
> };
>
> /**
> @@ -570,6 +579,16 @@ struct panthor_group {
> /** @fatal_queues: Bitmask reflecting the queues that hit a fatal exception. */
> u32 fatal_queues;
>
> + /**
> + * @protm_pending_queues: Bitmask reflecting the queues that are waiting
> + * on a CS_PROTM_PENDING.
> + *
> + * The GPU will set the bit associated to the queue pending protected mode
> + * when a PROT_REGION command is executing or when trying to resume previously
> + * suspended protected mode jobs.
> + */
> + u32 protm_pending_queues;
> +
> /** @tiler_oom: Mask of queues that have a tiler OOM event to process. */
> atomic_t tiler_oom;
>
> @@ -1176,6 +1195,7 @@ queue_resume_timeout(struct panthor_queue *queue)
> * @ptdev: Device.
> * @csg_id: Group slot ID.
> * @cs_id: Queue slot ID.
> + * @protm_ack: Acknowledge pending protected mode queues
> *
> * Program a queue slot with the queue information so things can start being
> * executed on this queue.
> @@ -1472,6 +1492,34 @@ csg_slot_prog_locked(struct panthor_device *ptdev, u32 csg_id, u32 priority)
> return 0;
> }
>
> +static void
> +cs_slot_process_protm_pending_event_locked(struct panthor_device *ptdev,
> + u32 csg_id, u32 cs_id)
> +{
> + struct panthor_scheduler *sched = ptdev->scheduler;
> + struct panthor_csg_slot *csg_slot = &sched->csg_slots[csg_id];
> + struct panthor_group *group = csg_slot->group;
> +
> + lockdep_assert_held(&sched->lock);
> +
> + if (!group)
> + return;
> +
> + /* No protected memory heap, a user space program tried to
> + * submit a protected mode jobs resulting in the GPU raising
> + * a CS_PROTM_PENDING request.
> + *
> + * This scenario is invalid and the protected mode jobs must
> + * not be allowed to progress.
> + */
> + if (!ptdev->protm.heap)
> + return;
Should we flag the group unusable when that happens and schedule it out
as soon as possible?
if (!ptdev->protm.heap)
group->fatal_queues |= BIT(cs_id);
else
group->protm_pending_queues |= BIT(cs_id);
sched_queue_delayed_work(sched, tick, 0);
> +
> + group->protm_pending_queues |= BIT(cs_id);
> +
> + sched_queue_delayed_work(sched, tick, 0);
> +}
> +
> static void
> cs_slot_process_fatal_event_locked(struct panthor_device *ptdev,
> u32 csg_id, u32 cs_id)
> @@ -1718,6 +1766,9 @@ static bool cs_slot_process_irq_locked(struct panthor_device *ptdev,
> if (events & CS_TILER_OOM)
> cs_slot_process_tiler_oom_event_locked(ptdev, csg_id, cs_id);
>
> + if (events & CS_PROTM_PENDING)
> + cs_slot_process_protm_pending_event_locked(ptdev, csg_id, cs_id);
> +
> /* We don't acknowledge the TILER_OOM event since its handling is
> * deferred to a separate work.
> */
> @@ -1848,6 +1899,17 @@ static void sched_process_idle_event_locked(struct panthor_device *ptdev)
> sched_queue_delayed_work(ptdev->scheduler, tick, 0);
> }
>
> +static void sched_process_protm_exit_event_locked(struct panthor_device *ptdev)
> +{
> + lockdep_assert_held(&ptdev->scheduler->lock);
> +
> + /* Acknowledge the protm exit and schedule a tick. */
> + panthor_fw_protm_exit(ptdev);
Let's just inline the content of panthor_fw_protm_exit() here.*
It doesn't make sense to have all these indirections, especially
since PROTM and scheduling are intertwined anyway, so I consider
it part of the scheduler responsibility (just like the scheduler
deals with other GLB events).
The same goes for the other panthor_fw_protm_ helpers defined in
panthor_fw.c, I think panthor_sched.c would be a better fit for
those, or even inlining their content if they are only used in
a single place.
> + sched_queue_delayed_work(ptdev->scheduler, tick, 0);
> + ptdev->scheduler->protm.protected_mode = false;
> + ptdev->scheduler->protm.active_group = NULL;
> +}
> +
> /**
> * sched_process_global_irq_locked() - Process the scheduling part of a global IRQ
> * @ptdev: Device.
> @@ -1863,6 +1925,9 @@ static void sched_process_global_irq_locked(struct panthor_device *ptdev)
> ack = READ_ONCE(glb_iface->output->ack);
> evts = (req ^ ack) & GLB_EVT_MASK;
>
> + if (evts & GLB_PROTM_EXIT)
> + sched_process_protm_exit_event_locked(ptdev);
> +
> if (evts & GLB_IDLE)
> sched_process_idle_event_locked(ptdev);
> }
> @@ -1872,23 +1937,71 @@ static void process_fw_events_work(struct work_struct *work)
> struct panthor_scheduler *sched = container_of(work, struct panthor_scheduler,
> fw_events_work);
> u32 events = atomic_xchg(&sched->fw_events, 0);
> + u32 csg_events = events & ~JOB_INT_GLOBAL_IF;
> struct panthor_device *ptdev = sched->ptdev;
>
> mutex_lock(&sched->lock);
>
> + while (csg_events) {
> + u32 csg_id = ffs(csg_events) - 1;
> +
> + sched_process_csg_irq_locked(ptdev, csg_id);
> + csg_events &= ~BIT(csg_id);
> + }
I'm sure you have a good reason to re-order the processing
of CSG and GLB events, and it'd be good to have it documented
in a comment.
> +
> if (events & JOB_INT_GLOBAL_IF) {
> sched_process_global_irq_locked(ptdev);
> events &= ~JOB_INT_GLOBAL_IF;
> }
>
> - while (events) {
> - u32 csg_id = ffs(events) - 1;
> + mutex_unlock(&sched->lock);
> +}
>
> - sched_process_csg_irq_locked(ptdev, csg_id);
> - events &= ~BIT(csg_id);
> +static void handle_protm_fault(struct panthor_device *ptdev)
This is a bit of a misnomer, I think. It doesn't seem to be triggered
by a FAULT event, it's more a timeout on a PROTM section that would
lead to a reset being scheduled, and this "blocked-in-protm" situation
being detected as part of the reset.
> +{
> + struct panthor_scheduler *sched = ptdev->scheduler;
> + u32 csg_id;
> + struct panthor_group *protm_group;
> +
> + guard(mutex)(&sched->lock);
> +
> + if (!sched->protm.protected_mode)
> + return;
> +
> + protm_group = sched->protm.active_group;
> +
> + if (drm_WARN_ON(&ptdev->base, !protm_group))
> + return;
See, that's a perfect example of sched->protm.protected_mode being redundant.
Now you're left with a potential protected_mode=true,active_group=NULL
inconsistency you don't expect.
> +
> + /* Group will be terminated by the device reset */
> + protm_group->fatal_queues |= GENMASK(protm_group->queue_count - 1, 0);
> +
> + if (!panthor_fw_protm_exit_wait_event_timeout(ptdev))
> + goto cleanup_protm;
> +
> + /**
> + * GPU failed to exit protected mode. Mark all non-protected mode CSGs
/* GPU failed to exit protected mode. Mark all non-protected mode CSGs
> + * as suspended so that they are unaffected by the GPU reset.
> + */
> +
> + for (csg_id = 0; csg_id < sched->csg_slot_count; csg_id++) {
> + struct panthor_group *group = sched->csg_slots[csg_id].group;
> +
> + if (!group || group == protm_group)
> + continue;
> +
> + group->state = PANTHOR_CS_GROUP_SUSPENDED;
> +
> + group_unbind_locked(group);
> +
> + list_move(&group->run_node, group_is_idle(group) ?
> + &sched->groups.idle[group->priority] :
> + &sched->groups.runnable[group->priority]);
nit: Let's use a local struct list_head * variable to select the right list.
> }
>
> - mutex_unlock(&sched->lock);
> +cleanup_protm:
> + sched->protm.protected_mode = false;
> + sched->protm.active_group = NULL;
> }
>
> /**
> @@ -2029,6 +2142,7 @@ struct panthor_sched_tick_ctx {
> bool immediate_tick;
> bool stop_tick;
> u32 csg_upd_failed_mask;
> + struct panthor_group *protm_group;
> };
>
> static bool
> @@ -2299,6 +2413,7 @@ tick_ctx_evict_group(struct panthor_scheduler *sched,
>
> static void
> tick_ctx_reschedule_group(struct panthor_scheduler *sched,
> + struct panthor_sched_tick_ctx *ctx,
> struct panthor_csg_slots_upd_ctx *upd_ctx,
> struct panthor_group *group,
> int new_csg_prio)
> @@ -2321,6 +2436,30 @@ tick_ctx_reschedule_group(struct panthor_scheduler *sched,
> csg_iface->output->ack ^ CSG_ENDPOINT_CONFIG,
> CSG_ENDPOINT_CONFIG);
> }
> +
> + if (ctx->protm_group == group) {
> + for (u32 q = 0; q < group->queue_count; q++) {
> + struct panthor_fw_cs_iface *cs_iface;
> +
> + if (!(group->protm_pending_queues & BIT(q)))
> + continue;
> +
> + cs_iface = panthor_fw_get_cs_iface(ptdev, group->csg_id, q);
> + panthor_fw_update_reqs(cs_iface, req, cs_iface->output->ack,
> + CS_PROTM_PENDING);
> + }
> +
> + panthor_fw_toggle_reqs(csg_iface, doorbell_req, doorbell_ack,
> + group->protm_pending_queues);
> + csgs_upd_ctx_ring_doorbell(upd_ctx, group->csg_id);
> + group->protm_pending_queues = 0;
> +
> + /*
> + * We only allow one protected group to run at same time,
> + * as it makes it easier to handle faults in protected mode.
It's more something to document in the panthor_scheduler::protm::active_group
section.
> + */
> + sched->protm.active_group = group;
Would it make sense to move this logic to a tick_ctx_handle_protm_group()
helper that's called before/after tick_ctx_reschedule_group()? This way
there's no extra if (ctx->protm_group == group) conditional branch in here.
static void
tick_ctx_handle_protm_group(struct panthor_scheduler *sched,
struct panthor_sched_tick_ctx *ctx,
struct panthor_csg_slots_upd_ctx *upd_ctx)
{
struct panthor_device *ptdev = sched->ptdev;
struct panthor_group *group = ctx->protm_group;
struct panthor_fw_csg_iface *csg_iface;
if (!group || drm_WARN_ON(&ptdev->base, group->csg_id < 0))
return;
csg_iface = panthor_fw_get_csg_iface(ptdev, group->csg_id);
for (u32 q = 0; q < group->queue_count; q++) {
struct panthor_fw_cs_iface *cs_iface;
if (!(group->protm_pending_queues & BIT(q)))
continue;
cs_iface = panthor_fw_get_cs_iface(ptdev, group->csg_id, q);
panthor_fw_update_reqs(cs_iface, req, cs_iface->output->ack,
CS_PROTM_PENDING);
}
panthor_fw_toggle_reqs(csg_iface, doorbell_req, doorbell_ack,
group->protm_pending_queues);
csgs_upd_ctx_ring_doorbell(upd_ctx, group->csg_id);
group->protm_pending_queues = 0;
sched->protm.active_group = group;
}
> + }
> }
>
> static void
> @@ -2336,6 +2475,17 @@ tick_ctx_schedule_group(struct panthor_scheduler *sched,
> group_bind_locked(group, csg_id);
> csg_slot_prog_locked(ptdev, csg_id, csg_prio);
>
> + /* If the group was waiting for protected mode before suspension,
> + * and the tick context enters this mode, it should be serviced
> + * immediately because the slot reset should have set the
> + * CS_PROTM_PENDING bit to zero, and cs_prog_slot_locked() sets it to
> + * zero too.
> + * It's not clear if we will get a new CS_PROTM_PENDING event in that
> + * case, but it should be safe either way.
> + */
> + if (group->protm_pending_queues && ctx->protm_group)
> + group->protm_pending_queues = 0;
I'd move this to the path where we do the SUSPEND, or group_unbind(), even.
> +
> csgs_upd_ctx_queue_reqs(ptdev, upd_ctx, csg_id,
> group->state == PANTHOR_CS_GROUP_SUSPENDED ?
> CSG_STATE_RESUME : CSG_STATE_START,
> @@ -2365,7 +2515,7 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
>
> /* Update priorities on already running groups. */
> list_for_each_entry(group, &ctx->groups[prio], run_node) {
> - tick_ctx_reschedule_group(sched, &upd_ctx, group, new_csg_prio--);
> + tick_ctx_reschedule_group(sched, ctx, &upd_ctx, group, new_csg_prio--);
> }
> }
>
> @@ -2457,6 +2607,15 @@ tick_ctx_apply(struct panthor_scheduler *sched, struct panthor_sched_tick_ctx *c
>
> sched->used_csg_slot_count = ctx->group_count;
> sched->might_have_idle_groups = ctx->idle_group_count > 0;
> +
> + if (ctx->protm_group) {
> + ret = panthor_fw_protm_enter(ptdev);
> + if (ret) {
> + panthor_device_schedule_reset(ptdev);
> + ctx->csg_upd_failed_mask = U32_MAX;
It's weird to flag it as all CSGs update failed. Should we instead
have
/* If we failed to enter PROTM, consider the group who
* requested it as failed.
*/
ctx->csg_upd_failed_mask |= BIT(ctx->protm_group->csg_id);
> + }
> + sched->protm.protected_mode = true;
I'd move that to a tick_ctx_service_protm_req() helper that has the
panthor_fw_protm_enter() inlined, because again, it doesn't make
sense to have this defined in panthor_fw.c if the only user lives
in panthor_sched.c
> + }
> }
>
> static u64
> @@ -2490,7 +2649,7 @@ static void tick_work(struct work_struct *work)
> u64 resched_target = sched->resched_target;
> u64 remaining_jiffies = 0, resched_delay;
> u64 now = get_jiffies_64();
> - int prio, ret, cookie;
> + int prio, protm_prio, ret, cookie;
> bool full_tick;
>
> if (!drm_dev_enter(&ptdev->base, &cookie))
> @@ -2564,14 +2723,49 @@ static void tick_work(struct work_struct *work)
> }
> }
>
> + /* Check if the highest priority group want to switch to protected mode */
> + for (protm_prio = PANTHOR_CSG_PRIORITY_COUNT - 1; protm_prio >= 0; protm_prio--) {
> + struct panthor_group *group;
> +
> + group = list_first_entry_or_null(&ctx.groups[protm_prio],
> + struct panthor_group,
> + run_node);
> + if (group) {
> + ctx.protm_group = group;
> + break;
> + }
Should this be
if (group) {
if (group->protm_pending_queues)
ctx.protm_group = group;
break;
}
?
> + }
> +
> /* If we have free CSG slots left, pick idle groups */
> - for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1;
> - prio >= 0 && !tick_ctx_is_full(sched, &ctx);
> - prio--) {
How about we keep it a single indentation level and skip higher prios if
PROTM is requested:
/* Pick only idle groups with equal or lower priority than the
* group triggering protected mode. Do not bother picking
* unscheduled idle groups.
*/
if (ctx.protm_group && prio < protm_prio)
continue;
This saves us an indentation level and limits the code duplication.
> - /* Check the old_group queue first to avoid reprogramming the slots */
> - tick_ctx_pick_groups_from_list(sched, &ctx, &ctx.old_groups[prio], false, true);
> - tick_ctx_pick_groups_from_list(sched, &ctx, &sched->groups.idle[prio],
> - false, false);
> + if (ctx.protm_group) {
> + /* Pick only idle groups with equal or lower priority than the
> + * group triggering protected mode. Do not bother picking
> + * unscheduled idle groups.
> + */
> + for (prio = protm_prio;
> + prio >= 0 && !tick_ctx_is_full(sched, &ctx);
> + prio--)
> + tick_ctx_pick_groups_from_list(sched, &ctx,
> + &ctx.old_groups[prio],
> + false, true);
> + } else {
> + /* No switch to protected, just pick any idle group according
> + * to priority
> + */
> + for (prio = PANTHOR_CSG_PRIORITY_COUNT - 1;
> + prio >= 0 && !tick_ctx_is_full(sched, &ctx);
> + prio--) {
> + /* Check the old_group queue first to avoid
> + * reprogramming the slots
> + */
> + tick_ctx_pick_groups_from_list(sched, &ctx,
> + &ctx.old_groups[prio],
> + false, true);
> + tick_ctx_pick_groups_from_list(sched, &ctx,
> + &sched->groups.idle[prio],
> + false, false);
> + }
> +
> }
>
> tick_ctx_apply(sched, &ctx);
> @@ -2993,6 +3187,8 @@ void panthor_sched_pre_reset(struct panthor_device *ptdev)
> cancel_work_sync(&sched->sync_upd_work);
> cancel_delayed_work_sync(&sched->tick_work);
>
> + handle_protm_fault(ptdev);
I actually wonder if this should be part of the panthor_sched_suspend()
logic. That is, we would automatically flag all non-protm groups as
suspended if the GPU was in PROTM mode at the time the hang happened.
> +
> panthor_sched_suspend(ptdev);
>
> /* Stop all groups that might still accept jobs, so we don't get passed
Regards,
Boris
^ permalink raw reply
* Re: [PATCH v4 16/27] mtd: spi-nor: Create a local SR cache
From: Michael Walle @ 2026-05-06 8:51 UTC (permalink / raw)
To: Pratyush Yadav, Miquel Raynal
Cc: Takahiro Kuwano, Richard Weinberger, Vignesh Raghavendra,
Jonathan Corbet, Sean Anderson, Thomas Petazzoni, Steam Lin,
linux-mtd, linux-kernel, linux-doc
In-Reply-To: <2vxz7bph25qx.fsf@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Tue May 5, 2026 at 6:14 PM CEST, Pratyush Yadav wrote:
> On Fri, Apr 03 2026, Miquel Raynal wrote:
>
>> In order to be able to generate debugfs output without having to
>> actually reach the flash, create a SPI NOR local cache of the status
>> registers. What matters in our case are all the bits related to sector
>> locking. As such, in order to make it clear that this cache is not
>> intended to be used anywhere else, we zero the irrelevant bits.
>>
>> The cache is initialized once during the early init, and then maintained
>> every time the write protection scheme is updated.
>
> What is the reason for doing so? Do the reads have side effects?
I don't like that a debugfs read will issue a SPI transaction, at
least not these informational files.
If we ever want to access the registers in the flash, we should have
a separate debugfs file/interface.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] alloc_tag: introduce IOCTL-based filtering for MAP
From: Hao Ge @ 2026-05-06 8:44 UTC (permalink / raw)
To: Abhishek Bapat, Suren Baghdasaryan
Cc: Shuah Khan, Jonathan Corbet, linux-doc, linux-kernel, linux-mm,
Sourav Panda, Andrew Morton, Kent Overstreet
In-Reply-To: <cover.1777936301.git.abhishekbapat@google.com>
Hi Abhishek and Suren
On 2026/5/5 07:36, Abhishek Bapat wrote:
> Currently, memory allocation profiling data is primarily exposed through
> /proc/allocinfo. While useful for manual inspection, this text-based
> interface poses challenges for production monitoring and large-scale
> analysis:
>
> 1. Userspace must parse large amounts of text to extract specific
> fields.
> 2. To find specific tags, userspace must read the entire dataset,
> requiring many context switches and high data copying.
> 3. The kernel currently aggregates per-CPU counters for every allocation
> size, even those the user intends to filter out immediately.
>
> This series introduces a new IOCTL-based binary interface for allocinfo
> that supports kernel-side filtering. By allowing the user to specify a
> filter mask, we significantly reduce the work performed in-kernel and
> the amount of data transferred to userspace.
>
> Performance measurements were conducted on an Intel Xeon Platinum 8481C
> (224 CPUs) with caches dropped before each run.
>
> The IOCTL mechanism shows a ~20x performance improvement for
> filtered queries. The kernel avoids the expensive per-CPU counter
> aggregation (alloc_tag_read) for any tags that fail the initial string
> or location filters.
>
> Scenario 1: Specific File Filtering (arch/x86/events/rapl.c)
> 1. Traditional (cat /proc/allocinfo | grep): 22ms (sys)
> 2. IOCTL Interface: 1ms (sys)
>
> Scenario 2: Compound Filtering (Filename + Size)
> 1. Traditional: (cat ... | grep | awk): 21ms (sys)
> 2. IOCTL Interface: 1ms (sys)
>
> Scenario 3: Size-Based Filtering (min_size = 1MB)
> 1. Traditional: (cat ... | awk): 21ms (sys)
> 2. IOCTL Interface: 14ms (sys)
What a coincidence! I was just about to send an email to Suren
asking about plans for upstreaming a filtering tool for /proc/allocinfo,
and then I came across this patchset.
I have been following and using memory allocation profiling since
it was first introduced. It has been very helpful for our memory
analysis by providing clear visibility into allocation data. However,
we have always wanted a tool to efficiently filter this data to get
exactly what we need, so I previously developed a userspace tool [1]
to help with that.
[1] https://lore.kernel.org/all/20250106112103.25401-1-hao.ge@linux.dev/
So this patchset provides efficient filtering of allocinfo data via ioctl.
Would the next step be to develop a general-purpose tool under
tools/mm that leverages these ioctls instead of parsing /proc/allocinfo
text output?
Thanks
Best Regards
Hao
> Abhishek Bapat (5):
> alloc_tag: add ioctl filters to /proc/allocinfo
> alloc_tag: add size-based filtering to ioctl
> alloc_tag: add accuracy based filtering to ioctl
> kselftest: alloc_tag: add kselftest for ioctl interface
> kselftest: alloc_tag: extend the allocinfo ioctl kselftest
>
> Suren Baghdasaryan (1):
> alloc_tag: add ioctl to /proc/allocinfo
>
> .../userspace-api/ioctl/ioctl-number.rst | 2 +
> include/linux/codetag.h | 1 +
> include/uapi/linux/alloc_tag.h | 87 +++
> lib/alloc_tag.c | 249 ++++++++-
> lib/codetag.c | 11 +
> tools/testing/selftests/alloc_tag/Makefile | 9 +
> .../alloc_tag/allocinfo_ioctl_test.c | 508 ++++++++++++++++++
> 7 files changed, 865 insertions(+), 2 deletions(-)
> create mode 100644 include/uapi/linux/alloc_tag.h
> create mode 100644 tools/testing/selftests/alloc_tag/Makefile
> create mode 100644 tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c
>
^ permalink raw reply
* Re: [PATCH v4 07/27] mtd: spi-nor: swp: Explain the MEMLOCK ioctl implementation behaviour
From: Miquel Raynal @ 2026-05-06 8:42 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Michael Walle, Takahiro Kuwano, Richard Weinberger,
Vignesh Raghavendra, Jonathan Corbet, Sean Anderson,
Thomas Petazzoni, Steam Lin, linux-mtd, linux-kernel, linux-doc
In-Reply-To: <2vxzfr4527bx.fsf@kernel.org>
>> +/*
>> + * These ioctls behave according to the following rules:
>> + * ->lock(): Never locks more than what is requested, ie. may lock less
>> + * ->unlock(): Never unlocks more than what is requested, ie. may unlock less
>> + * -is_locked(): Checks if the region is *fully* locked, returns false otherwise.
>> + * This feeback may be misleading because users may get an "unlocked"
>> + * status even though a subpart of the region is effectively locked.
>> + */
>
> We already have some text where struct spi_nor_locking_ops is defined.
> Can we move this information there?
Ok, I will udpate the position of the comment.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH v2 11/11] MAINTAINERS: use a URL for pin-init maintainer's profile entry
From: Miguel Ojeda @ 2026-05-06 8:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Gary Guo, Benno Lossin, Jonathan Corbet, Linux Doc Mailing List,
linux-kernel, rust-for-linux, Björn Roy Baron, Alice Ryhl,
Andreas Hindborg, Boqun Feng, Danilo Krummrich, Miguel Ojeda,
Trevor Gross
In-Reply-To: <20260506084935.1cd4b794@foz.lan>
On Wed, May 6, 2026 at 8:49 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Maybe it is just me, but placing doc files in the crowd together with code
> on a project where documentation has its own directory sounds weird(*).
>
> (*) except for userspace tools and staging drivers where we want
> everything, including documentation, contained on a single place.
It is a similar case -- they are vendored libraries developed and used
elsewhere (e.g. in userspace too).
> As you're already using some scripting to do a bidirectional sync,
> you could add there some logic to convert rust pin-init documentation
> to rst and place it at Documentation/rust/.
Most of the pin-init documentation is elsewhere (embedded in the Rust
source code) and already rendered at rust.docs.kernel.org.
(Using Sphinx for Rust has been discussed in the list a few times in
the past too, and that has its own set of constraints).
> Btw, on a quick check, only Rust has markdown files:
>
> $ git ls-files|grep ".md$"|grep -v tools/
> rust/pin-init/CONTRIBUTING.md
> rust/pin-init/README.md
> rust/proc-macro2/README.md
> rust/quote/README.md
> rust/syn/README.md
>
> As one of the people who spent years helping improving the Kernel
> documentation and doing lots of conversions from markdown
> and other non-structured text formats to RST, I have to say that I'm
> concerned with any trends that would add doc files that aren't
> properly integrated with the Kernel documentation system like those.
All those are vendored libraries, and most of those `README.md` files
are about clarifying where they are taken from and their licensing,
e.g.
# `quote`
These source files come from the Rust `quote` crate, version 1.0.40
(released 2025-03-12), hosted in the <https://github.com/dtolnay/quote>
repository, licensed under "Apache-2.0 OR MIT" and only modified to add
the SPDX license identifiers.
For copyright details, please see:
https://github.com/dtolnay/quote/blob/1.0.40/README.md#license
https://github.com/dtolnay/quote/blob/1.0.40/LICENSE-APACHE
https://github.com/dtolnay/quote/blob/1.0.40/LICENSE-MIT
i.e. they are not intended to be kernel documentation, and moving them
away from the source files doesn't sound like an improvement,
especially since we were explicitly requested to make the provenance
very clear.
We could perhaps have a list of vendored libraries in
Documentation/rust/vendored-libraries.rst` -- that could perhaps be
useful for some folks.
In any case, I understand your desire to keep things integrated in the
kernel documentation, and I appreciate that (I also like to have
everything neatly integrated), but please do not assume we have been
randomly adding Markdown for no reason or that we are not trying to
keep things properly integrated... :(
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v8 3/4] drm: Suppress intentional warning backtraces in scaling unit tests
From: Albert Esteve @ 2026-05-06 8:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Andrew Morton, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-kernel,
linux-arch, linux-kselftest, kunit-dev, dri-devel, workflows,
linux-riscv, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Simona Vetter
In-Reply-To: <20260504-tentacled-free-lobster-38d8d9@houat>
On Mon, May 4, 2026 at 12:04 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi,
>
> On Mon, May 04, 2026 at 09:41:27AM +0200, Albert Esteve wrote:
> > From: Guenter Roeck <linux@roeck-us.net>
> >
> > The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
> > intentionally trigger warning backtraces by providing bad parameters to
> > the tested functions. What is tested is the return value, not the existence
> > of a warning backtrace. Suppress the backtraces to avoid clogging the
> > kernel log and distraction from real problems.
> >
> > Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Acked-by: Maíra Canal <mcanal@igalia.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: David Airlie <airlied@gmail.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> > Acked-by: David Gow <david@davidgow.net>
> > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > ---
> > drivers/gpu/drm/tests/drm_rect_test.c | 23 +++++++++++++++++++----
> > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
> > index 17e1f34b76101..818e16e80c8f9 100644
> > --- a/drivers/gpu/drm/tests/drm_rect_test.c
> > +++ b/drivers/gpu/drm/tests/drm_rect_test.c
> > @@ -409,8 +409,16 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
> > const struct drm_rect_scale_case *params = test->param_value;
> > int scaling_factor;
> >
> > - scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> > - params->min_range, params->max_range);
> > + /*
> > + * drm_rect_calc_hscale() generates a warning backtrace whenever bad
> > + * parameters are passed to it. This affects all unit tests with an
> > + * error code in expected_scaling_factor.
> > + */
> > + kunit_warning_suppress(test) {
> > + scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> > + params->min_range,
> > + params->max_range);
> > + }
> >
> > KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
> > }
> > @@ -420,8 +428,15 @@ static void drm_test_rect_calc_vscale(struct kunit *test)
> > const struct drm_rect_scale_case *params = test->param_value;
> > int scaling_factor;
> >
> > - scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
> > - params->min_range, params->max_range);
> > + /*
> > + * drm_rect_calc_vscale() generates a warning backtrace whenever bad
> > + * parameters are passed to it. This affects all unit tests with an
> > + * error code in expected_scaling_factor.
> > + */
> > + kunit_warning_suppress(test) {
> > + scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
> > + params->min_range, params->max_range);
> > + }
> >
> > KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
> > }
>
> For both I think we should add KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT calls, no?
Hi Maxime,
It may indeed add verification value by ensuring the call actually
generates the expected warning.
The original patch did not include count checks on the version I
inherited it from (i.e.,
https://lore.kernel.org/all/20250526132755.166150-5-acarmina@redhat.com/),
so I kept the same approach while adapting to the API changes. That
said, the check is simple to add, so I could include it in the next
version.
BR,
Albert
>
> Maxime
^ permalink raw reply
* Re: [PATCH net-next 5/5] dt-bindings: net: Add bindings for the ADIN1140
From: Krzysztof Kozlowski @ 2026-05-06 8:20 UTC (permalink / raw)
To: Ciprian Regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Andrew Lunn, Heiner Kallweit, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
linux-kernel, linux-doc, devicetree
In-Reply-To: <20260503-adin1140-driver-v1-5-dd043cdd88f0@analog.com>
On Sun, May 03, 2026 at 02:24:54AM +0300, Ciprian Regus wrote:
> Add DT bindings for the ADIN1140 10BASE-T1S MACPHY. Update the
> MAINTAINERS entry to include the bindings file as well.
Beside other review, two things since I expect a v2 anyway:
A nit, subject: drop second/last, redundant "bindings for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
> ---
> .../devicetree/bindings/net/adi,adin1140.yaml | 69 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 70 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/adi,adin1140.yaml b/Documentation/devicetree/bindings/net/adi,adin1140.yaml
> new file mode 100644
> index 000000000000..26cd40d36f9b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/adi,adin1140.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/adi,adin1140.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ADI ADIN1140 10BASE-T1S MAC-PHY
> +
> +maintainers:
> + - Ciprian Regus <ciprian.regus@analog.com>
> +
> +description: |
> + The ADIN1140 (also called AD3306) is a low power single port
> + 10BASE-T1S MAC-PHY. It integrates an Ethernet PHY with a MAC
> + and all the associated analog circuitry.
> + The device implements the Open Alliance TC6 10BASE-T1x MAC-PHY
> + Serial Interface specification and is compliant with the
> + IEEE 802.3cg-2019 Ethernet standard for 10 Mbps single pair
> + Ethernet (SPE). The device has a 4-wire SPI interface for
> + communication between the MAC and host processor.
> +
> +allOf:
> + - $ref: /schemas/net/ethernet-controller.yaml#
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adin1140
> + - adi,ad3306
I guess reversed order as numbers are before letters in most sorting.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v12 00/16] Direct Map Removal Support for guest_memfd
From: Takahiro Itazuri @ 2026-05-06 8:07 UTC (permalink / raw)
To: seanjc, ljs
Cc: Liam.Howlett, ackerleytng, agordeev, ajones, akpm, alex, andrii,
aou, ast, baolu.lu, borntraeger, bp, bpf, catalin.marinas,
chenhuacai, corbet, coxu, daniel, dave.hansen, david, derekmn,
dev.jain, eddyz87, gerald.schaefer, gor, haoluo, hca, hpa, itazur,
jackabt, jackmanb, jannh, jgg, jgross, jhubbard, jiayuan.chen,
jmattson, joey.gouly, john.fastabend, jolsa, jthoughton, kalyazin,
kas, kernel, kpsingh, kvm, kvmarm, lenb, linux-arm-kernel,
linux-doc, linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-pm, linux-riscv, linux-s390, loongarch, lorenzo.stoakes,
luto, maobibo, martin.lau, maz, mhocko, mingo, mlevitsk,
nikita.kalyazin, oupton, palmer, patrick.roy, pavel, pbonzini,
peterx, peterz, pfalcato, pjw, prsampat, rafael, riel, rppt,
ryan.roberts, sdf, shijie, skhan, song, surenb, suzuki.poulose,
svens, tabba, tglx, thuth, urezki, vannapurve, vbabka, will,
willy, wu.fei9, x86, yang, yangyicong, yonghong.song, yosry,
yu-cheng.yu, yuzenghui, zhengqi.arch
In-Reply-To: <aeennZlV60k81OBf@google.com>
Hi Lorenzo and Sean,
Apologies for the delayed reply — Nikita is leaving Amazon, and I'm
taking over this series going forward. Thanks for your patience.
On Tue, Apr 21, 2026 at 01:40:00PM +0000, Lorenzo Stoakes wrote:
> Hm, given this touches a fair bit of mm, I wonder if we shouldn't try to do this
> through the mm tree?
On Tue, Apr 21, 2026 at 04:36:00PM +0000, Sean Christopherson wrote:
> Yeah, when the time comes, the mm pieces definitely need to go through the mm
> tree. Ideally, I think this would be merged in two separate parts, with all mm
> changes going through the mm tree, and then the KVM changes through the KVM tree
> using a stable topic branch/tag from Andrew.
Thanks for the guidance. The split makes sense to me; I'm planning to
follow this approach with patches 1-6 (mm) going through the mm tree
and patches 7-16 (KVM) through the KVM tree on top of a stable
branch/tag from mm. I'll confirm the exact boundary and coordination
details as I prepare the repost.
On Tue, Apr 21, 2026 at 01:40:00PM +0000, Lorenzo Stoakes wrote:
> In any case, we definitely need a rebase on something not-next :) if not mm then
> Linus's tree at least maybe?
>
> I'm seeing a lot of conflicts against mm-unstable, it can't b4 shazam even patch
> 1 and in Linus's tree it's failing at an mm patch (mm: introduce
> AS_NO_DIRECT_MAP).
I'll rebase onto v7.1-rc1 and resolve the conflicts as part of the split.
Takahiro
^ permalink raw reply
* Re: [PATCH v9 3/6] iio: adc: ad4691: add triggered buffer support
From: Andy Shevchenko @ 2026-05-06 7:25 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
David Lechner, Sa, Nuno, 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@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260505171723.390feb20@jic23-huawei>
On Tue, May 05, 2026 at 05:17:23PM +0100, Jonathan Cameron wrote:
> On Tue, 5 May 2026 17:58:21 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, May 05, 2026 at 02:26:40PM +0100, Jonathan Cameron wrote:
...
> > > > > > + for (i = 0; i < ARRAY_SIZE(ad4691_gp_names); i++) {
> > > > > > + irq = fwnode_irq_get_byname(dev_fwnode(dev),
> > > > > > + ad4691_gp_names[i]);
> > > > > > + if (irq > 0)
> > > > > > + break;
> > > > >
> > > > > This is problematic in case the above returns EPROBE_DEFER. Can you confirm
> > > > > it
> > > > > may not ever happen? (Note, I don't know the answer.)
> > > >
> > > > You are right, thanks for this!
> > > I'm missing something. Why is that a problem? Driver will return
> > > the error and a dev_err_probe() is used so it won't print anything.
> > > So probe will fail which is exactly what we want.
> >
> > If there are two IRQs and the first one is probe deferred and second returns
> > an error, we return that error instead of the deferral probe.
> >
> > May be I missed something, but I have no idea how in this case it may return
> > the first error code in such a case.
> Ah. Indeed. I completely misread the code. if (irq) would do the job to fix this.
Not really, as we are only concerned about deferred probe.
if (irq > 0 || irq == -EPROBE_DEFER)
break;
will do the job. But again, please double check that the
fwnode_irq_get_byname() is even capable of returning deferral probe
(probably yes as my weak memory tells me).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 11/11] MAINTAINERS: use a URL for pin-init maintainer's profile entry
From: Mauro Carvalho Chehab @ 2026-05-06 6:49 UTC (permalink / raw)
To: Gary Guo
Cc: Benno Lossin, Jonathan Corbet, Linux Doc Mailing List,
linux-kernel, rust-for-linux, Björn Roy Baron, Alice Ryhl,
Andreas Hindborg, Boqun Feng, Danilo Krummrich, Miguel Ojeda,
Trevor Gross
In-Reply-To: <DIASHBBEIHQW.3EQSDUML6G3SB@garyguo.net>
On Tue, 05 May 2026 14:49:09 +0100
"Gary Guo" <gary@garyguo.net> wrote:
> On Tue May 5, 2026 at 2:25 PM BST, Mauro Carvalho Chehab wrote:
> > This maintainer's entry is not inside documentation nor is
> > ReST, preventing Sphinx to create a hyperlink to it.
> >
> > Change it to point to the already-formatted URL.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > MAINTAINERS | 2 +-
> > rust/pin-init/CONTRIBUTING.md | 72 -----------------------------------
> > 2 files changed, 1 insertion(+), 73 deletions(-)
> > delete mode 100644 rust/pin-init/CONTRIBUTING.md
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8700472b3ae3..b16c8f85d099 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -23402,7 +23402,7 @@ S: Maintained
> > W: https://rust-for-linux.com/pin-init
> > B: https://github.com/Rust-for-Linux/pin-init/issues
> > C: zulip://rust-for-linux.zulipchat.com
> > -P: rust/pin-init/CONTRIBUTING.md
> > +P: https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
> > T: git https://github.com/Rust-for-Linux/linux.git pin-init-next
> > F: rust/kernel/init.rs
> > F: rust/pin-init/
> > diff --git a/rust/pin-init/CONTRIBUTING.md b/rust/pin-init/CONTRIBUTING.md
> > deleted file mode 100644
> > index 16c899a7ae0b..000000000000
> > --- a/rust/pin-init/CONTRIBUTING.md
> > +++ /dev/null
>
> This file is part of the bidirectional source sync.
>
> I think this file is still meaningful in its present location even if not
> rendered, so people touching the code would be able to see it and be aware. The
> presence of file is more visible than a P entry in the MAINTAINERS file.
Maybe it is just me, but placing doc files in the crowd together with code
on a project where documentation has its own directory sounds weird(*).
(*) except for userspace tools and staging drivers where we want
everything, including documentation, contained on a single place.
What several subsystems do - for instance the media subsystem - is to
place the maintainer's profile at the driver api, like this:
Documentation/driver-api/media/maintainer-entry-profile.rst
And adding it to Documentation/driver-api/<subsystem>/index.rst.
This way, subsystem developers will see it together with all other
the developer-specific documentation.
As you're already using some scripting to do a bidirectional sync,
you could add there some logic to convert rust pin-init documentation
to rst and place it at Documentation/rust/.
This is just my 2 cents.
-
Btw, on a quick check, only Rust has markdown files:
$ git ls-files|grep ".md$"|grep -v tools/
rust/pin-init/CONTRIBUTING.md
rust/pin-init/README.md
rust/proc-macro2/README.md
rust/quote/README.md
rust/syn/README.md
As one of the people who spent years helping improving the Kernel
documentation and doing lots of conversions from markdown
and other non-structured text formats to RST, I have to say that I'm
concerned with any trends that would add doc files that aren't
properly integrated with the Kernel documentation system like those.
> That said, if Miguel and/or Benno think it's fine to not have this file, I'm
> also okay with it being removed.
>
> Best,
> Gary
>
> > @@ -1,72 +0,0 @@
> > -# Contributing to `pin-init`
> > -
> > -Thanks for showing interest in contributing to `pin-init`! This document outlines the guidelines for
> > -contributing to `pin-init`.
> > -
> > -All contributions are double-licensed under Apache 2.0 and MIT. You can find the respective licenses
> > -in the `LICENSE-APACHE` and `LICENSE-MIT` files.
> > -
> > -## Non-Code Contributions
> > -
> > -### Bug Reports
> > -
> > -For any type of bug report, please submit an issue using the bug report issue template.
> > -
> > -If the issue is a soundness issue, please privately report it as a security vulnerability via the
> > -GitHub web interface.
> > -
> > -### Feature Requests
> > -
> > -If you have any feature requests, please submit an issue using the feature request issue template.
> > -compare
> > -### Questions and Getting Help
> > -
> > -You can ask questions in the Discussions page of the GitHub repository. If you're encountering
> > -problems or just have questions related to `pin-init` in the Linux kernel, you can also ask your
> > -questions in the [Rust-for-Linux Zulip](https://rust-for-linux.zulipchat.com/) or see
> > -<https://rust-for-linux.com/contact>.
> > -
> > -## Contributing Code
> > -
> > -### Linux Kernel
> > -
> > -`pin-init` is used by the Linux kernel and all commits are synchronized to it. For this reason, the
> > -same requirements for commits apply to `pin-init`. See [the kernel's documentation] for details. The
> > -rest of this document will also cover some of the rules listed there and additional ones.
> > -
> > -[the kernel's documentation]: https://docs.kernel.org/process/submitting-patches.html
> > -
> > -Contributions to `pin-init` ideally go through the [GitHub repository], because that repository runs
> > -a CI with lots of tests not present in the kernel. However, patches are also accepted (though not
> > -preferred). Do note that there are some files that are only present in the GitHub repository such as
> > -tests, licenses and cargo related files. Making changes to them can only happen via GitHub.
> > -
> > -[GitHub repository]: https://github.com/Rust-for-Linux/pin-init
> > -
> > -### Commit Style
> > -
> > -Everything must compile without errors or warnings and all tests must pass after **every commit**.
> > -This is important for bisection and also required by the kernel.
> > -
> > -Each commit should be a single, logically cohesive change. Of course it's best to keep the changes
> > -small and digestible, but logically linked changes should be made in the same commit. For example,
> > -when fixing typos, create a single commit that fixes all of them instead of one commit per typo.
> > -
> > -Commits must have a meaningful commit title. Commits with changes to files in the `internal`
> > -directory should have a title prefixed with `internal:`. The commit message should explain the
> > -change and its rationale. You also have to add your `Signed-off-by` tag, see [Developer's
> > -Certificate of Origin]. This has to be done for both mailing list submissions as well as GitHub
> > -submissions.
> > -
> > -[Developer's Certificate of Origin]: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> > -
> > -Any changes made to public APIs must be documented not only in the commit message, but also in the
> > -`CHANGELOG.md` file. This is especially important for breaking changes, as those warrant a major
> > -version bump.
> > -
> > -If you make changes to the top-level crate documentation, you also need to update the `README.md`
> > -via `cargo rdme`.
> > -
> > -Some of these rules can be ignored if the change is done solely to files that are not present in the
> > -kernel version of this library. Those files are documented in the `sync-kernel.sh` script at the
> > -very bottom in the `--exclude` flag given to the `git am` command.
>
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] dept: update documentation function names to match implementation
From: Byungchul Park @ 2026-05-06 6:27 UTC (permalink / raw)
To: Yunseong Kim
Cc: bagasdotme, 2407018371, Dai.Ngo, Liam.Howlett, a.hindborg,
ada.coupriediaz, adilger.kernel, akpm, alex.gaynor,
alexander.shishkin, aliceryhl, amir73il, andi.shyti, andrii, anna,
arnd, ast, baolin.wang, bigeasy, bjorn3_gh, boqun.feng, bp,
brauner, broonie, bsegall, catalin.marinas, chenhuacai,
chris.p.wilson, christian.koenig, chuck.lever, cl, clrkwllms,
corbet, da.gomez, dakr, damien.lemoal, dan.j.williams,
daniel.vetter, dave.hansen, david, dennis, dietmar.eggemann,
djwong, dri-devel, duyuyang, dwmw, francesco, frederic, gary,
geert+renesas, geert, gregkh, guoweikang.kernel, gustavo,
gwan-gyeong.mun, hamohammed.sa, hannes, harry.yoo, hch,
her0gyugyu, hpa, jack, jglisse, jiangshanlai, jlayton,
joel.granados, joel, joelagnelf, johannes.berg, josef, josh,
jpoimboe, juri.lelli, kees, kernel-team, kernel_team,
kevin.brodsky, kristina.martsenko, lillian, linaro-mm-sig, link,
linux-arch, linux-arm-kernel, linux-block, linux-doc, linux-ext4,
linux-fsdevel, linux-i2c, linux-ide, linux-kernel, linux-media,
linux-mm, linux-modules, linux-nfs, linux-rt-devel, linux,
longman, lorenzo.stoakes, lossin, luto, mark.rutland, masahiroy,
mathieu.desnoyers, matthew.brost, max.byungchul.park, mcgrof,
melissa.srw, mgorman, mhocko, miguel.ojeda.sandonis, minchan,
mingo, mjguzik, neeraj.upadhyay, neil, neilb, netdev, ngupta,
ojeda, okorniev, oleg, paulmck, penberg, peterz, petr.pavlu,
qiang.zhang, rcu, richard.weiyang, rientjes, rodrigosiqueiramelo,
rostedt, rppt, rust-for-linux, samitolvanen, sashal, shakeel.butt,
sj, sumit.semwal, surenb, tglx, thomas.weissschuh, tim.c.chen, tj,
tmgross, tom, torvalds, trondmy, tytso, urezki, usamaarif642,
vbabka, vdavydov.dev, vincent.guittot, vschneid, wangfushuai,
wangkefeng.wang, will, willy, wsa+renesas, x86, yeoreum.yun, ysk,
yunseong.kim, yuzhao, ziy
In-Reply-To: <20260428162614.786365-2-yunseong.kim@est.tech>
On Tue, Apr 28, 2026 at 06:26:15PM +0200, Yunseong Kim wrote:
> Synchronize function names in the documentation with the actual
> implementation to fix naming inconsistencies.
Good catch! Thanks Yunseong. I will apply it on the top.
Byungchul
> Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
> ---
> Documentation/dev-tools/dept.rst | 2 +-
> Documentation/dev-tools/dept_api.rst | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst
> index 333166464543..31b2fe629fab 100644
> --- a/Documentation/dev-tools/dept.rst
> +++ b/Documentation/dev-tools/dept.rst
> @@ -97,7 +97,7 @@ No. What about the following?
>
> mutex_lock A
> mutex_lock A <- DEADLOCK
> - wait_for_complete B <- DEADLOCK
> + wait_for_completion B <- DEADLOCK
> complete B
> mutex_unlock A
> mutex_unlock A
> diff --git a/Documentation/dev-tools/dept_api.rst b/Documentation/dev-tools/dept_api.rst
> index 409116a62849..74e7b1424ad5 100644
> --- a/Documentation/dev-tools/dept_api.rst
> +++ b/Documentation/dev-tools/dept_api.rst
> @@ -113,7 +113,7 @@ Do not use these APIs directly. The raw APIs of dept are:
> dept_stage_wait(map, key, ip, wait_func, time);
> dept_request_event_wait_commit();
> dept_clean_stage();
> - dept_stage_event(task, ip);
> + dept_ttwu_stage_wait(task, ip);
> dept_ecxt_enter(map, evt_flags, ip, ecxt_func, evt_func, sub_local);
> dept_ecxt_holding(map, evt_flags);
> dept_request_event(map, ext_wgen);
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 01/14] kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1
From: Nathan Chancellor @ 2026-05-06 6:21 UTC (permalink / raw)
To: Daniel Pereira
Cc: Bill Wendling, Justin Stitt, Nick Desaulniers, linux-kernel, llvm,
linux-kbuild, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <CAMAsx6cPfPVDBpL6wwHeqzWLqPwQB15pKgvgVu-Ni3Sjjkdf4w@mail.gmail.com>
Hi Daniel,
On Tue, May 05, 2026 at 03:26:40PM -0300, Daniel Pereira wrote:
> On Tue, May 5, 2026 at 1:11 PM Nicolas Schier <nsc@kernel.org> wrote:
> >
> >> FTR: The translations
> >>Documentation/translations/{it\_IT,pt\_BR}/process/changes.rst become now
> >>even more outdated.
> >
> >>Acked-by: Nicolas Schier <nsc@kernel.org>
> >
>
> Hi Nicolas,
>
> Just confirming that I will make the necessary corrections to the
> changes.rst Portuguese translation (pt\_BR) in the next few days.
Thanks but I think I can just update the version number in this patch
when I send v2, as the update should happen atomically. If you patch it
separately, it might not be true depending on when my change is merged.
--
Cheers,
Nathan
^ permalink raw reply
* [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Mayank Gite @ 2026-05-06 5:49 UTC (permalink / raw)
To: Paul Moore
Cc: Mayank Gite, Serge Hallyn, Jonathan Corbet, Shuah Khan,
linux-security-module, linux-doc, linux-kernel
- Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
"keyring".
- Updates formatting of keyring types.
Signed-off-by: Mayank Gite <drapl0n@protonmail.com>
---
Documentation/security/credentials.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index d0191c8b8060..4996838491b1 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
be searched for the desired key. Each process may subscribe to a number
of keyrings:
- Per-thread keying
- Per-process keyring
- Per-session keyring
+ - Per-thread keyring
+ - Per-process keyring
+ - Per-session keyring
When a process accesses a key, if not already present, it will normally be
cached on one of these keyrings for future accesses to find.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] lib/gcd: Convert to Rust
From: Greg KH @ 2026-05-06 5:18 UTC (permalink / raw)
To: Raymond Newman
Cc: linux-kernel, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, dakr, corbet, skhan, rust-for-linux,
linux-doc
In-Reply-To: <CAC5penpL_yet9HHqC=BNV_EP2wDe3zpsjFw77T8356veNV0rsw@mail.gmail.com>
On Tue, May 05, 2026 at 09:37:26PM -0400, Raymond Newman wrote:
> >From 96902ad2caf167ca0377e0b2063973e2183465b4 Mon Sep 17 00:00:00 2001
> From: Raymond Newman <raymondcharlesnewman@gmail.com>
> Date: Tue, 5 May 2026 21:29:29 -0400
> Subject: [PATCH] lib/gcd: Convert to Rust
>
> Convert lib/math/gcd.c to Rust. The binary GCD algorithm is preserved
> exactly, including both the efficient-ffs fast path and the even/odd
> fallback for CONFIG_CPU_NO_EFFICIENT_FFS targets.
This says what you are doing, but not why. Why make this change?
> -static unsigned long binary_gcd(unsigned long a, unsigned long b)
> -{
> - unsigned long r = a | b;
> -
<snip>
whitespace is damaged and this does not apply.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] watchdog: remove driver for integrated WDT of ZFx86 486-based SoC
From: Ethan Nelson-Moore @ 2026-05-06 4:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-watchdog, Wim Van Sebroeck, linux-doc, Jonathan Corbet,
Shuah Khan
In-Reply-To: <81a90b2d-8dc3-4466-92d6-936679e210d5@roeck-us.net>
On Tue, May 5, 2026 at 9:53 PM Guenter Roeck <linux@roeck-us.net> wrote:
> Already done.
Excellent. Thank you!
Ethan
^ 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