* Re: [PATCH v2 1/8] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
From: Arnaldo Carvalho de Melo @ 2026-03-31 20:42 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-2-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:20PM -0800, Ian Rogers wrote:
> Currently, both libdw and libunwind define 'unwind__get_entries'. This
> causes a duplicate symbol build failure when both are compiled into
> perf.
>
> This commit refactors the DWARF unwind post-processing to be
> configurable at runtime via the .perfconfig file option
> 'unwind.style', or using the argument '--unwind-style' in the commands
> 'perf report', 'perf script' and 'perf inject', in a similar manner to
> the addr2line or the disassembler style.
>
> The file 'tools/perf/util/unwind.c' adds the top-level dispatch
> function 'unwind__get_entries'. The backend implementations are
> renamed to 'libdw__get_entries' and 'libunwind__get_entries'. Both are
> attempted as fallbacks if not configured, or if the primary backend
> fails.
>
> Fixes: 2e9191573a69 ("perf build: Remove NO_LIBDW_DWARF_UNWIND option")
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/builtin-inject.c | 4 ++
> tools/perf/builtin-report.c | 4 ++
> tools/perf/builtin-script.c | 4 ++
> tools/perf/util/Build | 1 +
> tools/perf/util/symbol_conf.h | 15 +++++
> tools/perf/util/unwind-libdw.c | 2 +-
> tools/perf/util/unwind-libunwind.c | 2 +-
> tools/perf/util/unwind.c | 102 +++++++++++++++++++++++++++++
> tools/perf/util/unwind.h | 40 +++++------
> 9 files changed, 149 insertions(+), 25 deletions(-)
> create mode 100644 tools/perf/util/unwind.c
>
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 5b29f4296861..9ad681b3c0dc 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -26,6 +26,7 @@
> #include "util/synthetic-events.h"
> #include "util/thread.h"
> #include "util/namespaces.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/tsc.h"
>
> @@ -2539,6 +2540,9 @@ int cmd_inject(int argc, const char **argv)
> OPT_STRING(0, "guestmount", &symbol_conf.guestmount, "directory",
> "guest mount directory under which every guest os"
> " instance has a subdir"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "convert-callchain", &inject.convert_callchain,
> "Generate callchains using DWARF and drop register/stack data"),
> OPT_END()
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 3b81f4b3dc49..ae20c0679990 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -48,6 +48,7 @@
> #include "util/time-utils.h"
> #include "util/auxtrace.h"
> #include "util/units.h"
> +#include "util/unwind.h"
> #include "util/util.h" // perf_tip()
> #include "ui/ui.h"
> #include "ui/progress.h"
> @@ -1455,6 +1456,9 @@ int cmd_report(int argc, const char **argv)
> OPT_CALLBACK(0, "addr2line-style", NULL, "addr2line style",
> "addr2line styles (libdw,llvm,libbfd,addr2line)",
> report_parse_addr2line_config),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
> "Symbol demangling. Enabled by default, use --no-demangle to disable."),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 9f8b0fd27a0a..b6c7c164d02d 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -63,6 +63,7 @@
> #include <linux/err.h>
> #include "util/dlfilter.h"
> #include "util/record.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/cgroup.h"
> #include "util/annotate.h"
> @@ -4164,6 +4165,9 @@ int cmd_script(int argc, const char **argv)
> "Enable symbol demangling"),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> "Enable kernel symbol demangling"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_STRING(0, "addr2line", &symbol_conf.addr2line_path, "path",
> "addr2line binary to use for line numbers"),
> OPT_STRING(0, "time", &script.time_str, "str",
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index bcccad7487a9..6190a8f5b0fa 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -218,6 +218,7 @@ ifndef CONFIG_SETNS
> perf-util-y += setns.o
> endif
>
> +perf-util-y += unwind.o
> perf-util-$(CONFIG_LIBDW) += probe-finder.o
> perf-util-$(CONFIG_LIBDW) += dwarf-aux.o
> perf-util-$(CONFIG_LIBDW) += dwarf-regs.o
> diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
> index 71bb17372a6c..25d92bbbfee7 100644
> --- a/tools/perf/util/symbol_conf.h
> +++ b/tools/perf/util/symbol_conf.h
> @@ -9,6 +9,19 @@
> struct strlist;
> struct intlist;
>
> +enum unwind_style {
> +
> + UNWIND_STYLE_UNKNOWN = 0,
> +
> + UNWIND_STYLE_LIBDW,
> +
> + UNWIND_STYLE_LIBUNWIND,
> +
> +};
> +
> +#define MAX_UNWIND_STYLE (UNWIND_STYLE_LIBUNWIND + 1)
> +
> +
> enum a2l_style {
> A2L_STYLE_UNKNOWN = 0,
> A2L_STYLE_LIBDW,
> @@ -80,6 +93,7 @@ struct symbol_conf {
> *bt_stop_list_str;
> const char *addr2line_path;
> enum a2l_style addr2line_style[MAX_A2L_STYLE];
> + enum unwind_style unwind_style[MAX_UNWIND_STYLE];
> unsigned long time_quantum;
> struct strlist *dso_list,
> *comm_list,
> @@ -103,3 +117,4 @@ struct symbol_conf {
> extern struct symbol_conf symbol_conf;
>
> #endif // __PERF_SYMBOL_CONF
> +
> diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
> index 05e8e68bd49c..d8a5b7d54192 100644
> --- a/tools/perf/util/unwind-libdw.c
> +++ b/tools/perf/util/unwind-libdw.c
> @@ -339,7 +339,7 @@ frame_callback(Dwfl_Frame *state, void *arg)
> DWARF_CB_ABORT : DWARF_CB_OK;
> }
>
> -int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> +int libdw__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data,
> int max_stack,
> diff --git a/tools/perf/util/unwind-libunwind.c b/tools/perf/util/unwind-libunwind.c
> index cb8be6acfb6f..a0016b897dae 100644
> --- a/tools/perf/util/unwind-libunwind.c
> +++ b/tools/perf/util/unwind-libunwind.c
> @@ -79,7 +79,7 @@ void unwind__finish_access(struct maps *maps)
> ops->finish_access(maps);
> }
>
> -int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> +int libunwind__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data, int max_stack,
> bool best_effort)
> diff --git a/tools/perf/util/unwind.c b/tools/perf/util/unwind.c
> new file mode 100644
> index 000000000000..9ae7d5ad246d
> --- /dev/null
> +++ b/tools/perf/util/unwind.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "debug.h"
> +#include "symbol_conf.h"
> +#include "unwind.h"
> +#include <linux/string.h>
> +#include <string.h>
> +#include <stdlib.h>
> +
> +int unwind__get_entries(unwind_entry_cb_t cb __maybe_unused, void *arg __maybe_unused,
> + struct thread *thread __maybe_unused,
> + struct perf_sample *data __maybe_unused,
> + int max_stack __maybe_unused,
> + bool best_effort __maybe_unused)
> +{
> + int ret = 0;
> +
> +#if defined(HAVE_LIBDW_SUPPORT) || defined(HAVE_LIBUNWIND_SUPPORT)
> + if (symbol_conf.unwind_style[0] == UNWIND_STYLE_UNKNOWN) {
> + int i = 0;
> +#ifdef HAVE_LIBDW_SUPPORT
> + symbol_conf.unwind_style[i++] = UNWIND_STYLE_LIBDW;
> +#endif
> +#ifdef HAVE_LIBUNWIND_SUPPORT
> + symbol_conf.unwind_style[i++] = UNWIND_STYLE_LIBUNWIND;
> +#endif
> + }
> +#endif //defined(HAVE_LIBDW_SUPPORT) || defined(HAVE_LIBUNWIND_SUPPORT)
> +
> + for (size_t i = 0; i < ARRAY_SIZE(symbol_conf.unwind_style); i++) {
> + switch (symbol_conf.unwind_style[i]) {
> + case UNWIND_STYLE_LIBDW:
> +#ifdef HAVE_LIBDW_SUPPORT
> + ret = libdw__get_entries(cb, arg, thread, data, max_stack, best_effort);
> +#endif
> + break;
> + case UNWIND_STYLE_LIBUNWIND:
> +#ifdef HAVE_LIBUNWIND_SUPPORT
> + ret = libunwind__get_entries(cb, arg, thread, data, max_stack, best_effort);
> +#endif
> + break;
What if the user asks for one of the unwinders, symbol_conf.unwind_style
will be populated with the user's choices, but then here in
unwind__get_entries() we end up returning 0 because the user choice is
not built-in?
Also no warning will be emitted that what was asked for is not
available?
Maybe remove the ifdefs here and have a dummy libdw__get_entries() when
HAVE_LIBDW_SUPPORT ins't defined that emits the warning and returns -1?
Ditto for UNWIND_STYLE_LIBUNWIND?
- Arnaldo
> + case UNWIND_STYLE_UNKNOWN:
> + default:
> +#if !defined(HAVE_LIBDW_SUPPORT) && !defined(HAVE_LIBUNWIND_SUPPORT)
> + pr_warning_once(
> + "Error: dwarf unwinding not supported, build perf with libdw or libunwind.\n");
> +#endif
> + ret = -1;
> + break;
> + }
> + if (ret == 0)
> + break;
> + }
> + return ret;
> +}
> +
> +int unwind__configure(const char *var, const char *value, void *cb __maybe_unused)
> +{
> + static const char * const unwind_style_names[] = {
> + [UNWIND_STYLE_LIBDW] = "libdw",
> + [UNWIND_STYLE_LIBUNWIND] = "libunwind",
> + NULL
> + };
> + char *s, *p, *saveptr;
> + size_t i = 0;
> +
> + if (strcmp(var, "unwind.style"))
> + return 0;
> +
> + if (!value)
> + return -1;
> +
> + s = strdup(value);
> + if (!s)
> + return -1;
> +
> + p = strtok_r(s, ",", &saveptr);
> + while (p && i < ARRAY_SIZE(symbol_conf.unwind_style)) {
> + bool found = false;
> + char *q = strim(p);
> +
> + for (size_t j = UNWIND_STYLE_LIBDW; j < MAX_UNWIND_STYLE; j++) {
> + if (!strcasecmp(q, unwind_style_names[j])) {
> + symbol_conf.unwind_style[i++] = j;
> + found = true;
> + break;
> + }
> + }
> + if (!found)
> + pr_warning("Unknown unwind style: %s\n", q);
> + p = strtok_r(NULL, ",", &saveptr);
> + }
> +
> + free(s);
> + return 0;
> +}
> +
> +int unwind__option(const struct option *opt __maybe_unused,
> + const char *arg,
> + int unset __maybe_unused)
> +{
> + return unwind__configure("unwind.style", arg, NULL);
> +}
> diff --git a/tools/perf/util/unwind.h b/tools/perf/util/unwind.h
> index 9f7164c6d9aa..581d042e170a 100644
> --- a/tools/perf/util/unwind.h
> +++ b/tools/perf/util/unwind.h
> @@ -7,6 +7,7 @@
> #include "util/map_symbol.h"
>
> struct maps;
> +struct option;
> struct perf_sample;
> struct thread;
>
> @@ -26,7 +27,9 @@ struct unwind_libunwind_ops {
> struct perf_sample *data, int max_stack, bool best_effort);
> };
>
> -#ifdef HAVE_DWARF_UNWIND_SUPPORT
> +int unwind__configure(const char *var, const char *value, void *cb);
> +int unwind__option(const struct option *opt, const char *arg, int unset);
> +
> /*
> * When best_effort is set, don't report errors and fail silently. This could
> * be expanded in the future to be more permissive about things other than
> @@ -36,8 +39,20 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
> struct thread *thread,
> struct perf_sample *data, int max_stack,
> bool best_effort);
> -/* libunwind specific */
> +
> +#ifdef HAVE_LIBDW_SUPPORT
> +int libdw__get_entries(unwind_entry_cb_t cb, void *arg,
> + struct thread *thread,
> + struct perf_sample *data, int max_stack,
> + bool best_effort);
> +#endif
> +
> #ifdef HAVE_LIBUNWIND_SUPPORT
> +/* libunwind specific */
> +int libunwind__get_entries(unwind_entry_cb_t cb, void *arg,
> + struct thread *thread,
> + struct perf_sample *data, int max_stack,
> + bool best_effort);
> #ifndef LIBUNWIND__ARCH_REG_ID
> #define LIBUNWIND__ARCH_REG_ID(regnum) libunwind__arch_reg_id(regnum)
> #endif
> @@ -57,26 +72,5 @@ static inline int unwind__prepare_access(struct maps *maps __maybe_unused,
> static inline void unwind__flush_access(struct maps *maps __maybe_unused) {}
> static inline void unwind__finish_access(struct maps *maps __maybe_unused) {}
> #endif
> -#else
> -static inline int
> -unwind__get_entries(unwind_entry_cb_t cb __maybe_unused,
> - void *arg __maybe_unused,
> - struct thread *thread __maybe_unused,
> - struct perf_sample *data __maybe_unused,
> - int max_stack __maybe_unused,
> - bool best_effort __maybe_unused)
> -{
> - return 0;
> -}
> -
> -static inline int unwind__prepare_access(struct maps *maps __maybe_unused,
> - struct map *map __maybe_unused,
> - bool *initialized __maybe_unused)
> -{
> - return 0;
> -}
>
> -static inline void unwind__flush_access(struct maps *maps __maybe_unused) {}
> -static inline void unwind__finish_access(struct maps *maps __maybe_unused) {}
> -#endif /* HAVE_DWARF_UNWIND_SUPPORT */
> #endif /* __UNWIND_H */
> --
> 2.53.0.473.g4a7958ca14-goog
^ permalink raw reply
* Re: [PATCH v9 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne @ 2026-03-31 20:39 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Greg Kroah-Hartman, Badhri Jagan Sridharan,
Heikki Krogerus, Peter Griffin, Tudor Ambarus, Alim Akhtar,
Mark Brown, Matti Vaittinen, Andrew Morton, linux-kernel,
linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso
In-Reply-To: <20260331123138.GE3795166@google.com>
Hi Lee,
On 3/31/26 5:31 AM, Lee Jones wrote:
> On Wed, 25 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
>
>> From: Amit Sunil Dhamne <amitsd@google.com>
>>
>> Add register bitmasks for charger function.
>> In addition split the charger IRQs further such that each bit represents
>> an IRQ downstream of charger regmap irq chip. In addition populate the
>> ack_base to offload irq ack to the regmap irq chip framework.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> Reviewed-by: André Draszik <andre.draszik@linaro.org>
>> ---
>> drivers/mfd/max77759.c | 95 ++++++++++++++++++++++---
>> include/linux/mfd/max77759.h | 166 +++++++++++++++++++++++++++++++++++--------
>> 2 files changed, 222 insertions(+), 39 deletions(-)
>>
> [...]
>
>> +/*
>> + * enum max77759_chgr_chgin_dtls_status - Charger Input Status
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
>> + * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE: Vchgin > Vuvlo and
>> + * Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
>> + * Vchgin > Over Voltage threshold (Vovlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
>> + * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
>> + */
> This comment is masquerading as a kernel-doc header, but isn't actually
> kernel-doc. Either change the formatting or adapt the formatting to use
> /** and use W=1 to check it.
Thanks for pointing this out! I'll fix this in the next version and
ensure it's a proper kernel-doc block.
BR,
Amit
>> +enum max77759_chgr_chgin_dtls_status {
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
>> +};
^ permalink raw reply
* Re: [PATCH v2 1/8] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
From: Arnaldo Carvalho de Melo @ 2026-03-31 20:38 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-2-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:20PM -0800, Ian Rogers wrote:
> Currently, both libdw and libunwind define 'unwind__get_entries'. This
> causes a duplicate symbol build failure when both are compiled into
> perf.
>
> This commit refactors the DWARF unwind post-processing to be
> configurable at runtime via the .perfconfig file option
> 'unwind.style', or using the argument '--unwind-style' in the commands
> 'perf report', 'perf script' and 'perf inject', in a similar manner to
> the addr2line or the disassembler style.
>
> The file 'tools/perf/util/unwind.c' adds the top-level dispatch
> function 'unwind__get_entries'. The backend implementations are
> renamed to 'libdw__get_entries' and 'libunwind__get_entries'. Both are
> attempted as fallbacks if not configured, or if the primary backend
> fails.
>
> Fixes: 2e9191573a69 ("perf build: Remove NO_LIBDW_DWARF_UNWIND option")
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/builtin-inject.c | 4 ++
> tools/perf/builtin-report.c | 4 ++
> tools/perf/builtin-script.c | 4 ++
> tools/perf/util/Build | 1 +
> tools/perf/util/symbol_conf.h | 15 +++++
> tools/perf/util/unwind-libdw.c | 2 +-
> tools/perf/util/unwind-libunwind.c | 2 +-
> tools/perf/util/unwind.c | 102 +++++++++++++++++++++++++++++
> tools/perf/util/unwind.h | 40 +++++------
> 9 files changed, 149 insertions(+), 25 deletions(-)
> create mode 100644 tools/perf/util/unwind.c
>
> diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
> index 5b29f4296861..9ad681b3c0dc 100644
> --- a/tools/perf/builtin-inject.c
> +++ b/tools/perf/builtin-inject.c
> @@ -26,6 +26,7 @@
> #include "util/synthetic-events.h"
> #include "util/thread.h"
> #include "util/namespaces.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/tsc.h"
>
> @@ -2539,6 +2540,9 @@ int cmd_inject(int argc, const char **argv)
> OPT_STRING(0, "guestmount", &symbol_conf.guestmount, "directory",
> "guest mount directory under which every guest os"
> " instance has a subdir"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "convert-callchain", &inject.convert_callchain,
> "Generate callchains using DWARF and drop register/stack data"),
> OPT_END()
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 3b81f4b3dc49..ae20c0679990 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -48,6 +48,7 @@
> #include "util/time-utils.h"
> #include "util/auxtrace.h"
> #include "util/units.h"
> +#include "util/unwind.h"
> #include "util/util.h" // perf_tip()
> #include "ui/ui.h"
> #include "ui/progress.h"
> @@ -1455,6 +1456,9 @@ int cmd_report(int argc, const char **argv)
> OPT_CALLBACK(0, "addr2line-style", NULL, "addr2line style",
> "addr2line styles (libdw,llvm,libbfd,addr2line)",
> report_parse_addr2line_config),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_BOOLEAN(0, "demangle", &symbol_conf.demangle,
> "Symbol demangling. Enabled by default, use --no-demangle to disable."),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 9f8b0fd27a0a..b6c7c164d02d 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -63,6 +63,7 @@
> #include <linux/err.h>
> #include "util/dlfilter.h"
> #include "util/record.h"
> +#include "util/unwind.h"
> #include "util/util.h"
> #include "util/cgroup.h"
> #include "util/annotate.h"
> @@ -4164,6 +4165,9 @@ int cmd_script(int argc, const char **argv)
> "Enable symbol demangling"),
> OPT_BOOLEAN(0, "demangle-kernel", &symbol_conf.demangle_kernel,
> "Enable kernel symbol demangling"),
> + OPT_CALLBACK(0, "unwind-style", NULL, "unwind style",
> + "unwind styles (libdw,libunwind)",
> + unwind__option),
> OPT_STRING(0, "addr2line", &symbol_conf.addr2line_path, "path",
> "addr2line binary to use for line numbers"),
> OPT_STRING(0, "time", &script.time_str, "str",
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index bcccad7487a9..6190a8f5b0fa 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -218,6 +218,7 @@ ifndef CONFIG_SETNS
> perf-util-y += setns.o
> endif
>
> +perf-util-y += unwind.o
> perf-util-$(CONFIG_LIBDW) += probe-finder.o
> perf-util-$(CONFIG_LIBDW) += dwarf-aux.o
> perf-util-$(CONFIG_LIBDW) += dwarf-regs.o
> diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
> index 71bb17372a6c..25d92bbbfee7 100644
> --- a/tools/perf/util/symbol_conf.h
> +++ b/tools/perf/util/symbol_conf.h
> @@ -9,6 +9,19 @@
> struct strlist;
> struct intlist;
>
> +enum unwind_style {
> +
> + UNWIND_STYLE_UNKNOWN = 0,
> +
> + UNWIND_STYLE_LIBDW,
> +
> + UNWIND_STYLE_LIBUNWIND,
> +
Please remove the blank lines.
- Arnaldo
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Heiko Stuebner @ 2026-03-31 20:19 UTC (permalink / raw)
To: Alexey Charkov, Dennis Gilmore
Cc: Jimmy Hon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Peter Robinson, Michael Riesch, Mykola Kvach, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <CAABkxwsD_59G3YrpMdUi7D1fVHruSuDHn9-gQAZbwTdxGBHaBA@mail.gmail.com>
Hi Dennis,
Am Dienstag, 31. März 2026, 21:41:50 Mitteleuropäische Sommerzeit schrieb Dennis Gilmore:
> On Wed, Mar 11, 2026 at 9:26 AM Alexey Charkov <alchark@gmail.com> wrote:
> >
> > On Wed, Mar 11, 2026 at 5:29 AM Dennis Gilmore <dennis@ausil.us> wrote:
> > >
> > > On Tue, Mar 10, 2026 at 7:20 PM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > > >
> > > > <snip>
> > > > > +
> > > > > + vcc5v0_otg: regulator-vcc5v0-otg {
> > > > > + compatible = "regulator-fixed";
> > > > > + enable-active-high;
> > > > > + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&vcc5v0_otg_en>;
> > > > > + regulator-always-on;
> > > > > + regulator-boot-on;
> > > > regulator-always-on and regulator-boot-on does not seem right.
> > > >
> > > > Why were these added? The vendor did not have them.
> > > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L216-L226
> > > >
> > > > Was this mistakenly taken from the regulator usb 20 which is powering
> > > > the onboard usb2.0 hub?
> > > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L111-L119
> > >
> > > It may have been a missreading of the schematic, but it was added to
> > > get power to the USB3 port. before I added it devices plugged into the
> > > USB 3 port would not power on
> >
> > Hi Dennis,
> >
> > The schematic says that this regulator supplies the VBUS voltage for
> > the USB3 part of your Type-A OTG connector. If you make it always-on,
> > you'll likely lose the possibility to use this port in device mode
> > (which you would need e.g. for flashing images over a USB cable in
> > U-boot which also takes device tree sources from Linux via
> > devicetree-rebasing).
> >
> > You also link it up as the PHY supply of the USB2 controller, which
> > doesn't describe the actual hardware.
> >
> > Please see if you'd rather define a connector node for your Type-A
> > port, and list this regulator as its VBUS supply explicitly. I've
> > recently submitted a patch [1] to make the "onboard_usb_dev" driver
> > take care of enabling VBUS in exactly this type of situations (it's in
> > usb-testing now and will hopefully hit -next sometime soon). If you
> > need an example for its use, please refer to [2].
> >
> > Best regards,
> > Alexey
> >
> > [1] https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
> > [2] https://github.com/flipperdevices/flipper-linux-kernel/blob/2f814cdf07f50e901fc1b1328213e76460864c20/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts#L303-L328
>
> Sorry for the delay, I am taking a look at it now. Please let me know
> when it lands in -next. In the meantime, I believe what I have is in
> good shape and is working well here. I am happy to make a change once
> support lands upstream.
Review comments should be addressed before patches get applied.
So there is no waiting for "when it lands upstream" to make additional
fixes, when you know at submission time, that things need improvement.
Heiko
^ permalink raw reply
* [PATCH] iommu: Always fill in gather when unmapping
From: Jason Gunthorpe @ 2026-03-31 19:56 UTC (permalink / raw)
To: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang
Cc: Lu Baolu, Janusz Krzysztofik, Joerg Roedel, Jon Hunter, patches,
Robin Murphy, Samiullah Khawaja, stable, Vasant Hegde
The fixed commit assumed that the gather would always be populated if
an iotlb_sync was required.
arm-smmu-v3, amd, VT-d, riscv, s390, mtk all use information from the
gather during their iotlb_sync() and this approach works for them.
However, arm-smmu, qcom_iommu, ipmmu-vmsa, sun50i, sprd, virtio,
apple-dart all ignore the gather during their iotlb_sync(). They
mostly issue a full flush.
Unfortunately the latter set of drivers often don't bother to add
anything to the gather since they don't intend on using it. Since the
core code now blocks gathers that were never filled, this caused those
drivers to stop getting their iotlb_sync() calls and breaks them.
Since it is impossible to tell the difference between gathers that are
empty because there is nothing to do and gathers that are empty
because they are not used, fill in the gathers for the missing cases.
io-pgtable might have intended to allow the driver to choose between
gather or immediate flush because it passed gather to
ops->tlb_add_page(), however no driver does anything with it.
mtk uses io-pgtable-arm-v7s but added the range to the gather in the
unmap callback. Move this into the io-pgtable-arm unmap itself. That
will fix all the armv7 using drivers (arm-smmu, qcom_iommu,
ipmmu-vmsa).
arm-smmu uses both ARM_V7S and ARM LPAE formats. The LPAE formats
already have the gather population because SMMUv3 requires it, so it
becomes consistent.
Add a trivial gather population to io-pgtable-dart.
Add trivial populations to sprd, sun50i and virtio-iommu in their
unmap functions.
Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/io-pgtable-arm.c | 4 +++-
drivers/iommu/io-pgtable-dart.c | 3 +++
drivers/iommu/mtk_iommu.c | 1 -
drivers/iommu/sprd-iommu.c | 1 +
drivers/iommu/sun50i-iommu.c | 1 +
drivers/iommu/virtio-iommu.c | 2 ++
6 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 0208e5897c299a..8572713a42ca29 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -666,9 +666,11 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
/* Clear the remaining entries */
__arm_lpae_clear_pte(ptep, &iop->cfg, i);
- if (gather && !iommu_iotlb_gather_queued(gather))
+ if (gather && !iommu_iotlb_gather_queued(gather)) {
+ iommu_iotlb_gather_add_range(gather, iova, i * size);
for (int j = 0; j < i; j++)
io_pgtable_tlb_add_page(iop, gather, iova + j * size, size);
+ }
return i * size;
} else if (iopte_leaf(pte, lvl, iop->fmt)) {
diff --git a/drivers/iommu/io-pgtable-dart.c b/drivers/iommu/io-pgtable-dart.c
index cbc5d6aa2daa23..75d699dc28e7b0 100644
--- a/drivers/iommu/io-pgtable-dart.c
+++ b/drivers/iommu/io-pgtable-dart.c
@@ -330,6 +330,9 @@ static size_t dart_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
i++;
}
+ if (i && !iommu_iotlb_gather_queued(gather))
+ iommu_iotlb_gather_add_range(gather, iova, i * pgsize);
+
return i * pgsize;
}
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be990c108de2b..a2f80a92f51f2c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -828,7 +828,6 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- iommu_iotlb_gather_add_range(gather, iova, pgsize * pgcount);
return dom->iop->unmap_pages(dom->iop, iova, pgsize, pgcount, gather);
}
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
index c1a34445d244fb..893ea67d322644 100644
--- a/drivers/iommu/sprd-iommu.c
+++ b/drivers/iommu/sprd-iommu.c
@@ -340,6 +340,7 @@ static size_t sprd_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
spin_lock_irqsave(&dom->pgtlock, flags);
memset(pgt_base_iova, 0, pgcount * sizeof(u32));
spin_unlock_irqrestore(&dom->pgtlock, flags);
+ iommu_iotlb_gather_add_range(iotlb_gather, iova, size);
return size;
}
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index be3f1ce696ba29..b9aa4bbc82acad 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -655,6 +655,7 @@ static size_t sun50i_iommu_unmap(struct iommu_domain *domain, unsigned long iova
memset(pte_addr, 0, sizeof(*pte_addr));
sun50i_table_flush(sun50i_domain, pte_addr, 1);
+ iommu_iotlb_gather_add_range(gather, iova, SZ_4K);
return SZ_4K;
}
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc13197f122..5865b8f6c6e67a 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -897,6 +897,8 @@ static size_t viommu_unmap_pages(struct iommu_domain *domain, unsigned long iova
if (unmapped < size)
return 0;
+ iommu_iotlb_gather_add_range(gather, iova, unmapped);
+
/* Device already removed all mappings after detach. */
if (!vdomain->nr_endpoints)
return unmapped;
base-commit: fcbe430399ca5c318e99bfda6df9beee90ab051c
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-03-31 19:41 UTC (permalink / raw)
To: Alexey Charkov
Cc: Jimmy Hon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, FUKAUMI Naoki, Hsun Lai, Jonas Karlman,
Chaoyi Chen, John Clark, Michael Opdenacker, Quentin Schulz,
Andrew Lunn, Chukun Pan, Peter Robinson, Michael Riesch,
Mykola Kvach, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <CABjd4Yz3MKOp-gE8kNc4EOt3-a0mKZsxvbVYCN4KsbqTRDtWgA@mail.gmail.com>
On Wed, Mar 11, 2026 at 9:26 AM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Wed, Mar 11, 2026 at 5:29 AM Dennis Gilmore <dennis@ausil.us> wrote:
> >
> > On Tue, Mar 10, 2026 at 7:20 PM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > >
> > > <snip>
> > > > +
> > > > + vcc5v0_otg: regulator-vcc5v0-otg {
> > > > + compatible = "regulator-fixed";
> > > > + enable-active-high;
> > > > + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&vcc5v0_otg_en>;
> > > > + regulator-always-on;
> > > > + regulator-boot-on;
> > > regulator-always-on and regulator-boot-on does not seem right.
> > >
> > > Why were these added? The vendor did not have them.
> > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L216-L226
> > >
> > > Was this mistakenly taken from the regulator usb 20 which is powering
> > > the onboard usb2.0 hub?
> > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L111-L119
> >
> > It may have been a missreading of the schematic, but it was added to
> > get power to the USB3 port. before I added it devices plugged into the
> > USB 3 port would not power on
>
> Hi Dennis,
>
> The schematic says that this regulator supplies the VBUS voltage for
> the USB3 part of your Type-A OTG connector. If you make it always-on,
> you'll likely lose the possibility to use this port in device mode
> (which you would need e.g. for flashing images over a USB cable in
> U-boot which also takes device tree sources from Linux via
> devicetree-rebasing).
>
> You also link it up as the PHY supply of the USB2 controller, which
> doesn't describe the actual hardware.
>
> Please see if you'd rather define a connector node for your Type-A
> port, and list this regulator as its VBUS supply explicitly. I've
> recently submitted a patch [1] to make the "onboard_usb_dev" driver
> take care of enabling VBUS in exactly this type of situations (it's in
> usb-testing now and will hopefully hit -next sometime soon). If you
> need an example for its use, please refer to [2].
>
> Best regards,
> Alexey
>
> [1] https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
> [2] https://github.com/flipperdevices/flipper-linux-kernel/blob/2f814cdf07f50e901fc1b1328213e76460864c20/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts#L303-L328
Sorry for the delay, I am taking a look at it now. Please let me know
when it lands in -next. In the meantime, I believe what I have is in
good shape and is working well here. I am happy to make a change once
support lands upstream.
Dennis
^ permalink raw reply
* Re: [PATCH v5 11/38] KVM: arm64: Split teardown hypercall into two phases
From: Will Deacon @ 2026-03-31 19:24 UTC (permalink / raw)
To: Mark Brown
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Quentin Perret,
Fuad Tabba, Vincent Donnefort, Mostafa Saleh, Alexandru Elisei,
Aishwarya.TCV
In-Reply-To: <0cf948e9-be64-4c75-97f8-a560442eb5d2@sirena.org.uk>
On Tue, Mar 31, 2026 at 08:15:40PM +0100, Mark Brown wrote:
> On Mon, Mar 30, 2026 at 03:48:12PM +0100, Will Deacon wrote:
> > In preparation for reclaiming protected guest VM pages from the host
> > during teardown, split the current 'pkvm_teardown_vm' hypercall into
> > separate 'start' and 'finalise' calls.
> >
> > The 'pkvm_start_teardown_vm' hypercall puts the VM into a new 'is_dying'
> > state, which is a point of no return past which no vCPU of the pVM is
> > allowed to run any more. Once in this new state,
> > 'pkvm_finalize_teardown_vm' can be used to reclaim meta-data and
> > page-table pages from the VM. A subsequent patch will add support for
> > reclaiming the individual guest memory pages.
>
> We've started seeing WARN_ON()s generated in -next on N1DSP when running
> kvm-unit-tests under pKVM:
>
> 1821 23:03:59.721620 <4>[ 17.558270] ------------[ cut here ]------------
> 1822 23:03:59.725053 <4>[ 17.558274] WARNING: arch/arm64/kvm/pkvm.c:373 at __pkvm_pgtable_stage2_unshare+0xbc/0xfc, CPU#3: qemu-system-aar/390
Aha! That's probably the thing I tried to fix today. Please can you try
these patches on top?
https://lore.kernel.org/r/20260331155056.28220-1-will@kernel.org
Thanks,
Will
^ permalink raw reply
* Re: [PATCH v5 11/38] KVM: arm64: Split teardown hypercall into two phases
From: Mark Brown @ 2026-03-31 19:15 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Quentin Perret,
Fuad Tabba, Vincent Donnefort, Mostafa Saleh, Alexandru Elisei,
Aishwarya.TCV
In-Reply-To: <20260330144841.26181-12-will@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4853 bytes --]
On Mon, Mar 30, 2026 at 03:48:12PM +0100, Will Deacon wrote:
> In preparation for reclaiming protected guest VM pages from the host
> during teardown, split the current 'pkvm_teardown_vm' hypercall into
> separate 'start' and 'finalise' calls.
>
> The 'pkvm_start_teardown_vm' hypercall puts the VM into a new 'is_dying'
> state, which is a point of no return past which no vCPU of the pVM is
> allowed to run any more. Once in this new state,
> 'pkvm_finalize_teardown_vm' can be used to reclaim meta-data and
> page-table pages from the VM. A subsequent patch will add support for
> reclaiming the individual guest memory pages.
We've started seeing WARN_ON()s generated in -next on N1DSP when running
kvm-unit-tests under pKVM:
1821 23:03:59.721620 <4>[ 17.558270] ------------[ cut here ]------------
1822 23:03:59.725053 <4>[ 17.558274] WARNING: arch/arm64/kvm/pkvm.c:373 at __pkvm_pgtable_stage2_unshare+0xbc/0xfc, CPU#3: qemu-system-aar/390
...
1839 23:03:59.850178 <4>[ 17.697247] Call trace:
1840 23:03:59.853079 <4>[ 17.699940] __pkvm_pgtable_stage2_unshare+0xbc/0xfc (P)
1841 23:03:59.865729 <4>[ 17.705500] pkvm_pgtable_stage2_destroy_range+0x90/0x214
1842 23:03:59.866226 <4>[ 17.711145] kvm_stage2_destroy+0x74/0xd0
1843 23:03:59.869119 <4>[ 17.715403] kvm_free_stage2_pgd+0x5c/0xc0
1844 23:03:59.881700 <4>[ 17.719746] kvm_uninit_stage2_mmu+0x1c/0x34
1845 23:03:59.882197 <4>[ 17.724262] kvm_arch_flush_shadow_all+0x6c/0x84
1846 23:03:59.885123 <4>[ 17.729127] kvm_mmu_notifier_release+0x30/0x84
1847 23:03:59.897681 <4>[ 17.733905] __mmu_notifier_release+0x74/0x264
1848 23:03:59.898181 <4>[ 17.738596] exit_mmap+0x260/0x268
1849 23:03:59.898513 <4>[ 17.742247] __mmput+0x38/0x120
1850 23:03:59.898817 <4>[ 17.745637] mmput+0x50/0x5c
1851 23:03:59.901098 <4>[ 17.748766] do_exit+0x220/0x8f4
A bisect points at this patch:
git bisect start
# status: waiting for both good and bad commits
# bad: [cf7c3c02fdd0dfccf4d6611714273dcb538af2cb] Add linux-next specific files for 20260330
git bisect bad cf7c3c02fdd0dfccf4d6611714273dcb538af2cb
# status: waiting for good commit(s), bad commit known
# good: [a010730e610019b6d010ec43ce737cb59a37809d] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good a010730e610019b6d010ec43ce737cb59a37809d
# good: [5c552968883f4b10da9a1baeefd38a28afe993cd] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
git bisect good 5c552968883f4b10da9a1baeefd38a28afe993cd
# good: [de8f4e3b3d9aec5d4fdd5113ff09a6904b8a9f91] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
git bisect good de8f4e3b3d9aec5d4fdd5113ff09a6904b8a9f91
# bad: [7b3de9ac54f51bf09357802f02f0672de8bd49c0] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
git bisect bad 7b3de9ac54f51bf09357802f02f0672de8bd49c0
# good: [6778bd8a07f6f11414325ba6fe6d263f6b6994c9] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
git bisect good 6778bd8a07f6f11414325ba6fe6d263f6b6994c9
# good: [1cb1ca5899ab60d85e21ccf38da645a875fcf242] Merge branch 'edac-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
git bisect good 1cb1ca5899ab60d85e21ccf38da645a875fcf242
# bad: [4476dfd35bb0428c406fa68ce0d2125960535150] Merge branch 'next' of https://github.com/kvm-x86/linux.git
git bisect bad 4476dfd35bb0428c406fa68ce0d2125960535150
# good: [8f3483cd04d6ee6579594417d4a19394de63463a] Merge branch 'selftests'
git bisect good 8f3483cd04d6ee6579594417d4a19394de63463a
# bad: [5ad2ff071b5980f072a85c8114649218971c586e] Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/next
git bisect bad 5ad2ff071b5980f072a85c8114649218971c586e
# bad: [9ff714a09222128da16900fc7c15dea65692fc26] KVM: arm64: Inject SIGSEGV on illegal accesses
git bisect bad 9ff714a09222128da16900fc7c15dea65692fc26
# good: [f0877a1455cc6a93be14e4da741ce26ac0d6ca6d] KVM: arm64: Prevent unsupported memslot operations on protected VMs
git bisect good f0877a1455cc6a93be14e4da741ce26ac0d6ca6d
# bad: [ea03466e806fea942841a41cfaab8db8c851aa71] KVM: arm64: Handle aborts from protected VMs
git bisect bad ea03466e806fea942841a41cfaab8db8c851aa71
# bad: [6c58f914eb9c4ce5225d03183ae1290d72b5f639] KVM: arm64: Split teardown hypercall into two phases
git bisect bad 6c58f914eb9c4ce5225d03183ae1290d72b5f639
# good: [73c55be08932a348f8b0a44f561c33eaa2cf1ad2] KVM: arm64: Ignore -EAGAIN when mapping in pages for the pKVM host
git bisect good 73c55be08932a348f8b0a44f561c33eaa2cf1ad2
# first bad commit: [6c58f914eb9c4ce5225d03183ae1290d72b5f639] KVM: arm64: Split teardown hypercall into two phases
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* arm `rustdoc` Rust 1.85.0-only build error
From: Miguel Ojeda @ 2026-03-31 19:00 UTC (permalink / raw)
To: Christian Schrrefl, Russell King, Fabian Grünbichler
Cc: Rudraksha Gupta, Ard Biesheuvel, linux-arm-kernel, Miguel Ojeda,
rust-for-linux, linux-kernel
Hi Christian, Russell, arm, Fabian,
For Rust 1.85.0, for arm32, for the `rustdoc` target (i.e. all those
combined), I am seeing:
RUSTDOC .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs
error: target feature `fp-armv8` cannot be toggled with `#[target_feature]`: Rust ties `fp-armv8` to `neon`
--> .../1.85.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:7538:48
|
7538 | #[cfg_attr(target_arch = "arm", target_feature(enable = "fp-armv8,v8"))]
| ^^^^^^^^^^^^^^^^^^^^^
The issue is [1], was introduced in Rust 1.85.0 and was fixed already in
Rust 1.85.1 [2]:
Link: https://github.com/rust-lang/rust/issues/137366 [1]
Link: https://github.com/rust-lang/rust/pull/137632 [2]
It is unfortunate since our minimum is going to be 1.85.0 since that is
what Debian Stable has (even if patches may be on top) -- I generally
test the latest patch versions for each minor, but I noticed this since
I also test the actual minimum, and I am bumping it to 1.85.0.
To be clear, it is likely almost no one actually cares about this, since
nobody complained yet, and this can easily be fixed using the already
released Rust 1.85.1.
By the way, what is Debian's policy on upstream Rust patch versions?
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path
From: Marc Zyngier @ 2026-03-31 18:28 UTC (permalink / raw)
To: Anshuman Khandual
Cc: kvmarm, linux-arm-kernel, kvm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <8bd2b649-01b5-44f4-a034-c202e226e97c@arm.com>
On Tue, 31 Mar 2026 07:57:48 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> On 27/03/26 5:06 PM, Marc Zyngier wrote:
> > From: Fuad Tabba <tabba@google.com>
> >
> > Simplify the non-cacheable attributes assignment by using a ternary
> > operator. Additionally, hoist the MTE validation check (mte_allowed) out
> > of kvm_s2_fault_map() and into kvm_s2_fault_compute_prot(). This allows
> > us to fail faster and avoid acquiring the KVM MMU lock unnecessarily
> > when the VMM introduces a disallowed VMA for an MTE-enabled guest.
> >
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/mmu.c | 28 ++++++++++++----------------
> > 1 file changed, 12 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 0c71e3a9af8b0..ee2a548999b1b 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1870,18 +1870,21 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
> > if (fault->exec_fault)
> > fault->prot |= KVM_PGTABLE_PROT_X;
> >
> > - if (fault->s2_force_noncacheable) {
> > - if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
> > - fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
> > - else
> > - fault->prot |= KVM_PGTABLE_PROT_DEVICE;
> > - } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
> > + if (fault->s2_force_noncacheable)
> > + fault->prot |= (fault->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
> > + KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
> > + else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
> > fault->prot |= KVM_PGTABLE_PROT_X;
> > - }
>
> Is not the existing code block bit more cleaner though ?
What is wrong with this? Are you stating a matter of personal taste ?
Ternary operators are great at making things more readable by reducing
the amount of nesting, and I'm all in favour of anything that makes
this $%^&*( code easier to parse.
Or are you pointing out a technical issue?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v5 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Paul Menzel @ 2026-03-31 18:13 UTC (permalink / raw)
To: Javier Tia
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, Jose Tiburcio Ribeiro Netto,
Ivan Lubnin
In-Reply-To: <20260331-mt7927-bt-support-v5-8-6f31b4342daa@jetm.me>
Dear Javier,
Thank you for the patches and your persistence on improving them. I
noticed one more thing, just in this one:
Am 31.03.26 um 19:09 schrieb Javier Tia:
> Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek
> MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX
> X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards.
>
> Note: boards with this USB ID expose only one ISO alternate setting
> (alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
> setup for single alt setting"), this caused ~19 second initialization
> delays. With the fix applied, initialization completes in ~2.6
> seconds.
>
> The information in /sys/kernel/debug/usb/devices about the Bluetooth
> device is listed as the below.
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
> D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=13d3 ProdID=3588 Rev= 1.00
> S: Manufacturer=MediaTek Inc.
> S: Product=Wireless_Device
> S: SerialNumber=000000000
> C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
> A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
> E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
> E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
> Link: https://github.com/openwrt/mt76/issues/927
> Signed-off-by: Javier Tia <floss@jetm.me>
> Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
> Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com>
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 55a000540439..45ef0d008bce 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -761,6 +761,8 @@ static const struct usb_device_id quirks_table[] = {
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
> BTUSB_WIDEBAND_SPEECH },
> + { USB_DEVICE(0x13d3, 0x3588), .driver_info = BTUSB_MEDIATEK |
> + BTUSB_WIDEBAND_SPEECH },
This is not sorted. Is there a reason to place it here?
> { USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH] iommu/rockchip: fix page table allocation flags for v2 IOMMU
From: Jonas Karlman @ 2026-03-31 18:13 UTC (permalink / raw)
To: Midgy BALON
Cc: Shawn Lin, Simon Xue, iommu, joro, will, robin.murphy, heiko,
linux-arm-kernel, linux-rockchip, linux-kernel, stable
In-Reply-To: <20260331075010.1463-1-midgy971@gmail.com>
Hi Midgy,
On 3/31/2026 9:50 AM, Midgy BALON wrote:
> commit 2a7e6400f72b ("iommu: rockchip: Allocate tables from all
> available memory for IOMMU v2") removed GFP_DMA32 from
> iommu_data_ops_v2, reasoning that RK356x and RK3588 IOMMU v2 hardware
> supports up to 40-bit physical addresses for page tables. However, the
> RK3568 IOMMU page-table walker uses a 32-bit AXI bus: it cannot access
> physical addresses above 4 GB regardless of the address encoding range.
>
> On boards with more than 4 GB of RAM (e.g. 8 GB LPDDR4X), removing
> GFP_DMA32 causes two distinct failure modes:
>
> 1. Direct allocation above 4 GB: iommu_alloc_pages_sz() may return
> memory above 0x100000000. The hardware page-table walker issues a
> bus error trying to dereference those addresses, causing an IOMMU
> fault on the first DMA transaction.
>
> 2. SWIOTLB bounce-buffer poisoning: without GFP_DMA32, page tables land
> above the SWIOTLB window. dma_map_single() with DMA_BIT_MASK(32)
> then bounces them into a buffer below 4 GB. rk_dte_get_page_table()
> returns phys_to_virt() of the bounce buffer address; PTEs are written
> there; the next dma_sync_single_for_device(DMA_TO_DEVICE) copies the
> original (zero) data back over the bounce buffer, silently erasing the
> freshly written PTEs. The IOMMU faults because every PTE reads as zero.
>
> Restore GFP_DMA32 (and DMA_BIT_MASK(32)) for iommu_data_ops_v2, which
> currently only serves "rockchip,rk3568-iommu" in mainline.
>
> Tested on Radxa ROCK 3B (RK3568, 8 GB LPDDR4X):
> - MobileNetV1 via RKNN: 5.8 ms/inference (IOMMU mode)
> - YOLOv5s 640x640 via RKNN: ~57 ms/inference (IOMMU mode)
> - No IOMMU faults, correct inference results
>
> Fixes: 2a7e6400f72b ("iommu: rockchip: Allocate tables from all available memory for IOMMU v2")
> Cc: stable@vger.kernel.org
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> drivers/iommu/rockchip-iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 85f3667e797..8b45db29471 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1358,8 +1358,8 @@ static struct rk_iommu_ops iommu_data_ops_v2 = {
> .pt_address = &rk_dte_pt_address_v2,
> .mk_dtentries = &rk_mk_dte_v2,
> .mk_ptentries = &rk_mk_pte_v2,
> - .dma_bit_mask = DMA_BIT_MASK(40),
> - .gfp_flags = 0,
> + .dma_bit_mask = DMA_BIT_MASK(32),
> + .gfp_flags = GFP_DMA32,
This change is wrong because this struct describe the RK IOMMU v2 that
is capable of 40-bit addressing, used with e.g. RK3568 VOP2 MMU and MMUs
in other RK35xx SoCs.
What you have discovered is most likely that some IP blocks, e.g. NPU on
RK3568, is not capable of >32-bit addressing, and/or that such IP blocks
are still using IOMMU v1 blocks, or some variant with 32-bit limitation.
However, the RK IOMMU driver is currently not capable of supporting
different IOMMU revisions, if I recall correctly there may have been a
patch trying to address that already on ML.
Have you seen this issue with a variant of the rockit driver that add
support for RK3568 or a variant of the downstream rknpu driver forward
ported to mainline?
If your findings are correct it is likely that the NPU MMU needs to use
a different compatible, since rockchip,rk3568-iommu describe the IOMMUv2
that is capable of 40-bit addressing and is also used by other RK35xx
SoCs.
Regards,
Jonas
> };
>
> static const struct of_device_id rk_iommu_dt_ids[] = {
^ permalink raw reply
* Re: [PATCH v15 1/5] ring-buffer: Flush and stop persistent ring buffer on panic
From: Steven Rostedt @ 2026-03-31 18:03 UTC (permalink / raw)
To: Catalin Marinas
Cc: Masami Hiramatsu (Google), Will Deacon, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, Ian Rogers, linux-arm-kernel,
Robin Murphy
In-Reply-To: <acwK-Xu-Mon2_6bT@arm.com>
On Tue, 31 Mar 2026 18:57:13 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:
> I assume the ring buffer here is cacheable memory, otherwise we'd also
> need a dmb(osh) as in arch_wb_cache_pmem(). If that's correct:
Yes, it's cacheable (I couldn't imagine the performance overhead if it
wasn't! ;-)
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks!
-- Steve
^ permalink raw reply
* [PATCH 2/2] pmdomain/rockchip: skip domains returning -EPROBE_DEFER
From: Daniel Bozeman @ 2026-03-31 18:02 UTC (permalink / raw)
To: ulf.hansson, heiko
Cc: linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel,
Daniel Bozeman
In-Reply-To: <20260331180223.1682283-1-daniel@orb.net>
When iterating child nodes during probe, a single domain returning
-EPROBE_DEFER (e.g. due to clock dependencies not yet available)
causes the entire power domain controller to fail and tear down all
successfully registered domains.
This creates a window where devices in unrelated power domains that
would have registered successfully cannot access their hardware. On
RK3528, PD_GPU requires CRU clocks that may not be available yet,
but the idle-only domains (PD_RKVENC, PD_VO, PD_VPU) have no clock
requirements. When the controller fails due to PD_GPU, GPIO
controllers in PD_RKVENC become inaccessible, leading to synchronous
external aborts when GPIO-controlled regulators probe.
Skip domains that return -EPROBE_DEFER and continue registering the
rest. Skipped domains have NULL entries in the provider, causing
their consumers to receive -ENOENT and defer until available.
Fixes: 7c696693a4f5 ("soc: rockchip: power-domain: Add power domain driver")
Signed-off-by: Daniel Bozeman <daniel@orb.net>
---
drivers/pmdomain/rockchip/pm-domains.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 2eecae092a..f42880c94f 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -1077,6 +1077,11 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
for_each_available_child_of_node_scoped(np, node) {
error = rockchip_pm_add_one_domain(pmu, node);
if (error) {
+ if (error == -EPROBE_DEFER) {
+ dev_dbg(dev, "skipped node %pOFn, dependencies not yet available\n",
+ node);
+ continue;
+ }
dev_err(dev, "failed to handle node %pOFn: %d\n",
node, error);
goto err_out;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Daniel Bozeman @ 2026-03-31 18:02 UTC (permalink / raw)
To: ulf.hansson, heiko
Cc: linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel,
Daniel Bozeman
Idle-only power domains (pwr_mask == 0) cannot actually be powered
on or off. rockchip_do_pmu_set_power_domain() already returns early
for these domains, but rockchip_pd_power() still attempts QoS save
and idle requests before reaching that check.
On RK3528, the idle-only domains (PD_RKVENC, PD_VO, PD_VPU) have
QoS registers that may be inaccessible when the generic power domain
framework attempts to power them off, leading to synchronous external
aborts.
Return early from rockchip_pd_power() when pwr_mask is zero, matching
the existing guard in rockchip_do_pmu_set_power_domain().
Fixes: 1fe767a56c32 ("soc: rockchip: power-domain: allow domains only handling idle requests")
Signed-off-by: Daniel Bozeman <daniel@orb.net>
---
drivers/pmdomain/rockchip/pm-domains.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 490bbb1d1d..2eecae092a 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -640,6 +640,9 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on)
if (rockchip_pmu_domain_is_on(pd) == power_on)
return 0;
+ if (pd->info->pwr_mask == 0)
+ return 0;
+
ret = clk_bulk_enable(pd->num_clks, pd->clks);
if (ret < 0) {
dev_err(pmu->dev, "failed to enable clocks\n");
base-commit: bc330699801d3b4f99110365512caed5adcfaca3
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-03-31 18:00 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaMPgRALnoUIHMC@lpieralisi>
On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>> PSCI supports different types of resets like COLD reset, ARCH WARM
>> reset, vendor-specific resets. Currently there is no common driver that
>> handles all supported psci resets at one place. Additionally, there is
>> no common mechanism to issue the supported psci resets from userspace.
>>
>> Add a PSCI reboot mode driver and define two types of PSCI resets in the
>> driver as reboot-modes: predefined resets controlled by Linux
>> reboot_mode and customizable resets defined by SoC vendors in their
>> device tree under the psci:reboot-mode node.
>>
>> Register the driver with the reboot-mode framework to interface these
>> resets to userspace. When userspace initiates a supported command, pass
>> the reset arguments to the PSCI driver to enable command-based reset.
>>
>> This change allows userspace to issue supported PSCI reset commands
>> using the standard reboot system calls while enabling SoC vendors to
>> define their specific resets for PSCI.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/power/reset/Kconfig | 10 +++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
>> 3 files changed, 130 insertions(+)
>>
>> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
>> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
>> --- a/drivers/power/reset/Kconfig
>> +++ b/drivers/power/reset/Kconfig
>> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
>> then the bootloader can read it and take different
>> action according to the mode.
>>
>> +config PSCI_REBOOT_MODE
>> + bool "PSCI reboot mode driver"
>> + depends on OF && ARM_PSCI_FW
>> + select REBOOT_MODE
>> + help
>> + Say y here will enable PSCI reboot mode driver. This gets
>> + the PSCI reboot mode arguments and passes them to psci
>> + driver. psci driver uses these arguments for issuing
>> + device reset into different boot states.
>> +
>> config POWER_MLXBF
>> tristate "Mellanox BlueField power handling driver"
>> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
>> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
>> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
>> --- a/drivers/power/reset/Makefile
>> +++ b/drivers/power/reset/Makefile
>> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
>> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
>> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
>> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
>> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
>> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
>> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
>> --- /dev/null
>> +++ b/drivers/power/reset/psci-reboot-mode.c
>> @@ -0,0 +1,119 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#include <linux/device/faux.h>
>> +#include <linux/device.h>
>
> Nit: swap the two.
Ack. thanks.
>> +#include <linux/err.h>
>> +#include <linux/of.h>
>> +#include <linux/psci.h>
>> +#include <linux/reboot.h>
>> +#include <linux/reboot-mode.h>
>> +#include <linux/types.h>
>> +
>> +/*
>> + * Predefined reboot-modes are defined as per the values
>> + * of enum reboot_mode defined in the kernel: reboot.c.
>> + */
>> +static struct mode_info psci_resets[] = {
>> + { .mode = "warm", .magic = REBOOT_WARM},
>> + { .mode = "soft", .magic = REBOOT_SOFT},
>> + { .mode = "cold", .magic = REBOOT_COLD},
>> +};
>> +
>> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
>> +{
>> + INIT_LIST_HEAD(&reboot->predefined_modes);
>> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
>> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
>> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
>
> This looks weird to me, why can't we just initialize the array with the values
> directly ?
Ack. The idea was to avoid Typecasting. Will check on this.
>> + INIT_LIST_HEAD(&psci_resets[i].list);
>> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
>> + }
>> +}
>> +
>> +/*
>> + * arg1 is reset_type(Low 32 bit of magic).
>> + * arg2 is cookie(High 32 bit of magic).
>> + * If reset_type is 0, cookie will be used to decide the reset command.
>> + */
>> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
>> +{
>> + u32 reset_type = REBOOT_MODE_ARG1(magic);
>> + u32 cookie = REBOOT_MODE_ARG2(magic);
>> +
>> + if (reset_type == 0) {
>> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
>> + psci_set_reset_cmd(true, 0, 0);
>> + else
>> + psci_set_reset_cmd(false, 0, 0);
>> + } else {
>> + psci_set_reset_cmd(true, reset_type, cookie);
>> + }
>
> I don't think that psci_set_reset_cmd() has the right interface (and this
> nested if is too complicated for my taste). All we need to pass is reset-type
> and cookie (and if the reset is one of the predefined ones, reset-type is 0
> and cookie is the REBOOT_* cookie).
>
> Then the PSCI firmware driver will take the action according to what
> resets are available.
>
> How does it sound ?
So we mean these checks will move to the psci driver? Sorry for
re-iterating the question.
>> +
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
>> +{
>> + struct reboot_mode_driver *reboot;
>> + int ret;
>> +
>> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
>> + if (!reboot)
>> + return -ENOMEM;
>> +
>> + psci_reboot_mode_set_predefined_modes(reboot);
>> + reboot->write = psci_reboot_mode_write;
>> + reboot->dev = &fdev->dev;
>> +
>> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
>> + if (ret) {
>> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int __init psci_reboot_mode_init(void)
>> +{
>> + struct device_node *psci_np;
>> + struct faux_device *fdev;
>> + struct device_node *np;
>> + int ret;
>> +
>> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
>> + if (!psci_np)
>> + return -ENODEV;
>> + /*
>> + * Look for reboot-mode in the psci node. Even if the reboot-mode
>> + * node is not defined in psci, continue to register with the
>> + * reboot-mode driver and let the dev.ofnode be set as NULL.
>> + */
>> + np = of_find_node_by_name(psci_np, "reboot-mode");
>> +
>> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
>
> Same comment as Bartosz (have you picked up his work and working towards
> a solution) ?
Working on this via MFD. Some issue as again MFD framework does not
allows a fwnode based driver registration. Will update.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v15 1/5] ring-buffer: Flush and stop persistent ring buffer on panic
From: Catalin Marinas @ 2026-03-31 17:57 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Steven Rostedt, Will Deacon, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Ian Rogers, linux-arm-kernel, Robin Murphy
In-Reply-To: <177494616630.71933.2941681397188791689.stgit@mhiramat.tok.corp.google.com>
On Tue, Mar 31, 2026 at 05:36:06PM +0900, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> On real hardware, panic and machine reboot may not flush hardware cache
> to memory. This means the persistent ring buffer, which relies on a
> coherent state of memory, may not have its events written to the buffer
> and they may be lost. Moreover, there may be inconsistency with the
> counters which are used for validation of the integrity of the
> persistent ring buffer which may cause all data to be discarded.
>
> To avoid this issue, stop recording of the ring buffer on panic and
> flush the cache of the ring buffer's memory.
>
> Fixes: e645535a954a ("tracing: Add option to use memmapped memory for trace boot instance")
> Cc: stable@vger.kernel.org
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
[...]
> diff --git a/arch/arm64/include/asm/ring_buffer.h b/arch/arm64/include/asm/ring_buffer.h
> new file mode 100644
> index 000000000000..62316c406888
> --- /dev/null
> +++ b/arch/arm64/include/asm/ring_buffer.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _ASM_ARM64_RING_BUFFER_H
> +#define _ASM_ARM64_RING_BUFFER_H
> +
> +#include <asm/cacheflush.h>
> +
> +/* Flush D-cache on persistent ring buffer */
> +#define arch_ring_buffer_flush_range(start, end) dcache_clean_pop(start, end)
> +
> +#endif /* _ASM_ARM64_RING_BUFFER_H */
Adding Robin as he wrote the pmem support for arm64.
I assume the ring buffer here is cacheable memory, otherwise we'd also
need a dmb(osh) as in arch_wb_cache_pmem(). If that's correct:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: oe-kbuild-all, Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Louis-Alexis Eyraud,
Gary Bisson, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010103.FzAGRPye-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: 'ldo_volt_table1b' defined but not used [-Wunused-const-variable=]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Mathieu Poirier @ 2026-03-31 17:43 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Marc Zyngier,
Will Deacon, James Morse, Oliver Upton, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve
In-Reply-To: <152f5070-fda6-4381-bc40-4a70908c27c1@arm.com>
On Tue, Mar 31, 2026 at 12:05:47PM +0100, Suzuki K Poulose wrote:
> Hi Mathieu,
>
> On 30/03/2026 21:58, Mathieu Poirier wrote:
> > Hi,
> >
> > On Wed, Mar 18, 2026 at 03:53:34PM +0000, Steven Price wrote:
> > > The RMM may not be tracking all the memory of the system at boot. Create
> > > the necessary tracking state and GPTs within the RMM so that all boot
> > > memory can be delegated to the RMM as needed during runtime.
> > >
> > > Note: support is currently missing for SROs which means that if the RMM
> > > needs memory donating this will fail (and render CCA unusable in Linux).
> > >
> > > Signed-off-by: Steven Price <steven.price@arm.com>
> > > ---
> > > New patch for v13
> > > ---
> > > arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 89 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> > > index 9590dff9a2c1..80aedc85e94a 100644
> > > --- a/arch/arm64/kvm/rmi.c
> > > +++ b/arch/arm64/kvm/rmi.c
> > > @@ -4,6 +4,7 @@
> > > */
> > > #include <linux/kvm_host.h>
> > > +#include <linux/memblock.h>
> > > #include <asm/kvm_pgtable.h>
> > > #include <asm/rmi_cmds.h>
> > > @@ -56,6 +57,18 @@ static int rmi_check_version(void)
> > > return 0;
> > > }
> > > +/*
> > > + * These are the 'default' sizes when passing 0 as the tracking_region_size.
> > > + * TODO: Support other granule sizes
> > > + */
> > > +#ifdef CONFIG_PAGE_SIZE_4KB
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
> > > +#elif defined(CONFIG_PAGE_SIZE_16KB)
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
> > > +#elif defined(CONFIG_PAGE_SIZE_64KB)
> > > +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
> > > +#endif
> > > +
> > > static int rmi_configure(void)
> > > {
> > > struct rmm_config *config __free(free_page) = NULL;
> > > @@ -95,6 +108,80 @@ static int rmi_configure(void)
> > > return 0;
> > > }
> > > +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > > +{
> > > + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> >
> > This will produce an error on systems where the start of system memory is not
> > aligned to RMM_GRANULE_TRACKING_SIZE. For instance, on QEMU-SBSA the system
> > memory starts at 0x100_4300_0000. With the above and RMM_GRANULE_TRACKING_SIZE
> > set to SZ_1G, @start becomes 0x100_4000_0000, which falls outside the memory map
> > known to the TF-A. I fixed it with these modifications:
>
> Thanks for raising this. This would need to be addressed in the RMM
> spec, I have raised it with the team and will be addressed soon.
>
> >
> > LINUX:
> >
> > diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> > index 10ff1c3bddaf..21bfbbe2f047 100644
> > --- a/arch/arm64/kvm/rmi.c
> > +++ b/arch/arm64/kvm/rmi.c
> > @@ -424,7 +424,9 @@ static int rmi_configure(void)
> > static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > {
> > - start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> > + phys_addr_t offset;
> > +
> > + offset = start - ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> > end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> > while (start < end) {
> > @@ -439,7 +441,13 @@ static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> > start);
> > return -ENODEV;
> > }
> > - start += RMM_GRANULE_TRACKING_SIZE;
> > +
> > + if (offset) {
> > + start += (RMM_GRANULE_TRACKING_SIZE - offset);
> > + offset = 0;
> > + } else {
> > + start += RMM_GRANULE_TRACKING_SIZE;
> > + }
> > }
> > return 0;
> >
> > RMM:
> >
> > diff --git a/runtime/rmi/granule.c b/runtime/rmi/granule.c
> > index cef521fc0869..60358d9ee81e 100644
> > --- a/runtime/rmi/granule.c
> > +++ b/runtime/rmi/granule.c
> > @@ -209,9 +209,11 @@ void smc_granule_tracking_get(unsigned long addr,
> > return;
> > }
> > +#if 0
> > if (!ALIGNED(addr, RMM_INTERNAL_TRACKING_REGION_SIZE)) {
> > return;
> > }
> > +#endif
> > g = find_granule(addr);
> > if (g != NULL) {
> >
> > This is likely not the right fix but hopefully provides some guidance. Send me
> > your patches when you have an idea and I'll test them.
>
> We will send you the update once it is fixed in the RMM spec. The rough idea
> is to remove the ALIGNMENT restrictions and return a Range that
> the host can iterate over to find "regions" with the same type of
> memory.
>
Ok, thanks for looking into this.
>
> Cheers
> Suzuki
>
>
> >
> > Thanks,
> > Mathieu
> >
> >
> > > + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> > > +
> > > + while (start < end) {
> > > + unsigned long ret, category, state;
> > > +
> > > + ret = rmi_granule_tracking_get(start, &category, &state);
> > > + if (ret != RMI_SUCCESS ||
> > > + state != RMI_TRACKING_FINE ||
> > > + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
> > > + /* TODO: Set granule tracking in this case */
> > > + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
> > > + start);
> > > + return -ENODEV;
> > > + }
> > > + start += RMM_GRANULE_TRACKING_SIZE;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static unsigned long rmi_l0gpt_size(void)
> > > +{
> > > + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> > > + rmm_feat_reg1));
> > > +}
> > > +
> > > +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
> > > +{
> > > + unsigned long l0gpt_sz = rmi_l0gpt_size();
> > > +
> > > + start = ALIGN_DOWN(start, l0gpt_sz);
> > > + end = ALIGN(end, l0gpt_sz);
> > > +
> > > + while (start < end) {
> > > + int ret = rmi_gpt_l1_create(start);
> > > +
> > > + if (ret && ret != RMI_ERROR_GPT) {
> > > + /*
> > > + * FIXME: Handle SRO so that memory can be donated for
> > > + * the tables.
> > > + */
> > > + kvm_err("GPT Level1 table missing for %llx\n", start);
> > > + return -ENOMEM;
> > > + }
> > > + start += l0gpt_sz;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int rmi_init_metadata(void)
> > > +{
> > > + phys_addr_t start, end;
> > > + const struct memblock_region *r;
> > > +
> > > + for_each_mem_region(r) {
> > > + int ret;
> > > +
> > > + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
> > > + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
> > > + ret = rmi_verify_memory_tracking(start, end);
> > > + if (ret)
> > > + return ret;
> > > + ret = rmi_create_gpts(start, end);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int rmm_check_features(void)
> > > {
> > > if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
> > > @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
> > > return;
> > > if (rmi_configure())
> > > return;
> > > + if (rmi_init_metadata())
> > > + return;
> > > /* Future patch will enable static branch kvm_rmi_is_available */
> > > }
> > > --
> > > 2.43.0
> > >
> > >
>
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-03-31 17:40 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaQzmVhO50oAbbE@lpieralisi>
On 27-03-2026 19:44, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
>> PSCI supports different types of resets like COLD reset, ARCH WARM
>> reset, vendor-specific resets. Currently there is no common driver that
>> handles all supported psci resets at one place. Additionally, there is
>> no common mechanism to issue the supported psci resets from userspace.
>>
>> Add a PSCI reboot mode driver and define two types of PSCI resets in the
>> driver as reboot-modes: predefined resets controlled by Linux
>> reboot_mode and customizable resets defined by SoC vendors in their
>> device tree under the psci:reboot-mode node.
>>
>> Register the driver with the reboot-mode framework to interface these
>> resets to userspace. When userspace initiates a supported command, pass
>> the reset arguments to the PSCI driver to enable command-based reset.
>>
>> This change allows userspace to issue supported PSCI reset commands
>> using the standard reboot system calls while enabling SoC vendors to
>> define their specific resets for PSCI.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/power/reset/Kconfig | 10 +++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
>
> Add an entry into MAINTAINERS.POWER STATE COORDINATION INTERFACE for this
> specific file because I'd like to keep an eye on it, if you don't mind.
>
> Creating a MAINTAINER entry just for this seems overkill to me, it
> does not look like it is done for other reboot mode drivers.
Ack.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v20 04/10] firmware: psci: Introduce command-based reset in psci_sys_reset
From: Shivendra Pratap @ 2026-03-31 17:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <acaPCJnX6lb9lxPy@lpieralisi>
On 27-03-2026 19:37, Lorenzo Pieralisi wrote:
> On Wed, Mar 04, 2026 at 11:33:04PM +0530, Shivendra Pratap wrote:
>> PSCI currently supports only COLD reset and ARCH WARM reset based on the
>> Linux reboot_mode variable. The PSCI specification now includes
>> SYSTEM_RESET2 for vendor-specific resets, but there's no mechanism to
>> issue these through psci_sys_reset.
>>
>> Add a command-based reset mechanism that allows external drivers to set
>> the psci reset command via a new psci_set_reset_cmd() function.
>>
>> The psci command-based reset is disabled by default and the
>> psci_sys_reset follows its original flow until a psci_reset command is
>> set. In kernel panic path, psci_reset command is ignored.
>
> If it is function calls you should add parenthesis (eg psci_sys_reset ->
> psci_sys_reset()).
>
> You must explain why the kernel panic path requires separate handling
> here AND in the code - think about looking at this years down the line
> and figure out why kernel panics are special here.
Ack.
>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/firmware/psci/psci.c | 45 ++++++++++++++++++++++++++++++++++++++++++--
>> include/linux/psci.h | 2 ++
>> 2 files changed, 45 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
>> index 38ca190d4a22d6e7e0f06420e8478a2b0ec2fe6f..ae6f7a0aead913d740070080d4b2a3da15b29485 100644
>> --- a/drivers/firmware/psci/psci.c
>> +++ b/drivers/firmware/psci/psci.c
>> @@ -51,6 +51,15 @@ static int resident_cpu = -1;
>> struct psci_operations psci_ops;
>> static enum arm_smccc_conduit psci_conduit = SMCCC_CONDUIT_NONE;
>>
>> +struct psci_sys_reset_params {
>> + u32 system_reset;
>> + u32 reset_type;
>> + u32 cookie;
>> + bool cmd;
>> +};
>> +
>> +static struct psci_sys_reset_params psci_reset;
>> +
>> bool psci_tos_resident_on(int cpu)
>> {
>> return cpu == resident_cpu;
>> @@ -80,6 +89,28 @@ static u32 psci_cpu_suspend_feature;
>> static bool psci_system_reset2_supported;
>> static bool psci_system_off2_hibernate_supported;
>>
>> +/**
>> + * psci_set_reset_cmd - Sets the psci_reset_cmd for command-based
>> + * reset which will be used in psci_sys_reset call.
>> + *
>> + * @cmd_sys_rst2: Set to true for SYSTEM_RESET2 based resets.
>> + * @cmd_reset_type: Set the reset_type argument for psci_sys_reset.
>> + * @cmd_cookie: Set the cookie argument for psci_sys_reset.
>> + */
>> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie)
>> +{
>
> I don't think cmd_sys_rst2 is needed, as a replied in a different thread.
Need bit more clarification. The issue is that at some point we need to
decide - sys_rst2 or the reboot_mode based reset. Are you suggesting
that this check should be in psci driver instead of a pre-check in
psci_reboot_mode driver?
>
>> + if (cmd_sys_rst2 && psci_system_reset2_supported) {
>> + psci_reset.system_reset = PSCI_FN_NATIVE(1_1, SYSTEM_RESET2);
>> + psci_reset.reset_type = cmd_reset_type;
>> + psci_reset.cookie = cmd_cookie;
>> + } else {
>> + psci_reset.system_reset = PSCI_0_2_FN_SYSTEM_RESET;
>> + psci_reset.reset_type = 0;
>> + psci_reset.cookie = 0;
>> + }
>> + psci_reset.cmd = true;
>> +}
>> +
>> static inline bool psci_has_ext_power_state(void)
>> {
>> return psci_cpu_suspend_feature &
>> @@ -309,14 +340,24 @@ static int get_set_conduit_method(const struct device_node *np)
>> static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
>> void *data)
>> {
>> - if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
>> - psci_system_reset2_supported) {
>> + if (((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
>> + psci_system_reset2_supported) && (panic_in_progress() || !psci_reset.cmd)) {
>> /*
>> * reset_type[31] = 0 (architectural)
>> * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
>> * cookie = 0 (ignored by the implementation)
>> */
>> invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
>> + } else if (!panic_in_progress() && psci_reset.cmd) {
>> + /*
>> + * Commands are being set in psci_set_reset_cmd
>> + * This issues, SYSTEM_RESET2 arch warm reset or
>> + * SYSTEM_RESET2 vendor-specific reset or
>> + * a SYSTEM_RESET cold reset in accordance with
>> + * the reboot-mode command.
>> + */
>> + invoke_psci_fn(psci_reset.system_reset, psci_reset.reset_type,
>> + psci_reset.cookie, 0);
>> } else {
>> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
>
> This is very hard to parse. IMO, what you should do is:
>
> - Split this into two different paths: reboot_mode vs psci_reset.cmd == true.
> - Document very clearly why a panic needs separate handling.
>
> Something like:
>
> if (psci_reset.cmd)
> handle_reset_cmd();
> else
> handle_reboot_mode();
>
> I don't think we are far from converging but I want to be able to maintain
> this code going forward.
Ack. Will restructure it as suggested.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Luiz Augusto von Dentz @ 2026-03-31 17:31 UTC (permalink / raw)
To: Javier Tia
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
In-Reply-To: <20260331171043.F1C481EA006B@mailuser.phl.internal>
Hi Javier,
On Tue, Mar 31, 2026 at 1:10 PM Javier Tia <floss@jetm.me> wrote:
>
> Hi Luiz,
>
> On Tue, 31 Mar 2026 Luiz Augusto von Dentz wrote:
> > Ok, but on 8/8 it seem to suggest the problem still exists which
> > trigger the following review:
> >
> > https://sashiko.dev/#/patchset/20260330-mt7927-bt-support-v4-0-cecc025e7062%40jetm.me
> >
> > Perhaps we should ajust the commit description if the 19 seconds
> > doesn't really occurs when 2/8 is applied.
>
> Good catch. The ~19 second delay is indeed fixed by patch 2/8, so the
> note in 8/8 was misleading as written.
>
> I've updated the commit message in 8/8 to clarify:
>
> Note: boards with this USB ID expose only one ISO alternate setting
> (alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
> setup for single alt setting"), this caused ~19 second initialization
> delays. With the fix applied, initialization completes in ~2.6
> seconds.
>
> This is addressed in v5:
> https://lore.kernel.org/linux-bluetooth/20260331-mt7927-bt-support-v5-0-6f31b4342daa@jetm.me/
I've already pushed v4 with the 19 seconds comments removed.
> Best,
> Javier
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] dt-bindings: arm: arm,vexpress-scc: convert to DT schema
From: Khushal Chitturi @ 2026-03-31 17:29 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, liviu.dudau, sudeep.holla, lpieralisi,
pawel.moll
Cc: devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the ARM Versatile Express Serial Configuration Controller
bindings to DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/arm/arm,vexpress-scc.yaml | 51 +++++++++++++++++++
.../devicetree/bindings/arm/vexpress-scc.txt | 33 ------------
2 files changed, 51 insertions(+), 33 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/vexpress-scc.txt
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
new file mode 100644
index 000000000000..7870410211a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,vexpress-scc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Versatile Express Serial Configuration Controller
+
+maintainers:
+ - Pawel Moll <pawel.moll@arm.com>
+
+description: |
+ Test chips for ARM Versatile Express platform implement SCC (Serial
+ Configuration Controller) interface, used to set initial conditions
+ for the test chip.
+
+ In some cases its registers are also mapped in normal address space
+ and can be used to obtain runtime information about the chip internals
+ (like silicon temperature sensors) and as interface to other subsystems
+ like platform configuration control and power management.
+
+properties:
+ compatible:
+ items:
+ - pattern: "^arm,vexpress-scc,[a-z0-9_-]+$"
+ - const: arm,vexpress-scc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ scc@7fff0000 {
+ compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
+ reg = <0 0x7fff0000 0 0x1000>;
+ interrupts = <0 95 4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt
deleted file mode 100644
index ae5043e42e5d..000000000000
--- a/Documentation/devicetree/bindings/arm/vexpress-scc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-ARM Versatile Express Serial Configuration Controller
------------------------------------------------------
-
-Test chips for ARM Versatile Express platform implement SCC (Serial
-Configuration Controller) interface, used to set initial conditions
-for the test chip.
-
-In some cases its registers are also mapped in normal address space
-and can be used to obtain runtime information about the chip internals
-(like silicon temperature sensors) and as interface to other subsystems
-like platform configuration control and power management.
-
-Required properties:
-
-- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
- where <model> is the full tile model name (as used
- in the tile's Technical Reference Manual),
- eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
-
-Optional properties:
-
-- reg: when the SCC is memory mapped, physical address and size of the
- registers window
-- interrupts: when the SCC can generate a system-level interrupt
-
-Example:
-
- scc@7fff0000 {
- compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
- reg = <0 0x7fff0000 0 0x1000>;
- interrupts = <0 95 4>;
- };
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs
From: Marc Zyngier @ 2026-03-31 17:18 UTC (permalink / raw)
To: Sascha Bischoff
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Joey Gouly,
yuzenghui@huawei.com, Suzuki Poulose, oupton@kernel.org,
broonie@kernel.org, nd
In-Reply-To: <729851f0e7d277d308adf04d0008156a01f482bb.camel@arm.com>
On Tue, 31 Mar 2026 16:09:10 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> > The way the effective priority mask is computed, and then compared
> > to the priority of an interrupt to decide whether to wake-up or not,
> > is slightly odd, and breaks at the limits.
> >
> > This could result in spurious wake-ups that are undesirable.
> >
> > Adopt the GICv[23] logic instead, which checks that the priority
> > value
> > is strictly lower than the mask.
> >
> > Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
> > Link:
> > https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> > b/arch/arm64/kvm/vgic/vgic-v5.c
> > index 0f269321ece4b..75372bbfb6a6a 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v5.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> > @@ -238,7 +238,7 @@ static u32
> > vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> > */
> > priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR,
> > cpu_if->vgic_vmcr);
> >
> > - return min(highest_ap, priority_mask + 1);
> > + return min(highest_ap, priority_mask);
>
> Hi Marc,
>
> This part of your change (dropping the `- 1`) is not correct for GICv5.
> The GICv[23] PMR works differently to the GICv5 PCR.
>
> For GICv[23] the mask is exclusive, i.e., only higher priority (lower
> numerical value) interrupts are of sufficient priority to be signalled.
>
> For GICv5, the priority of an interrupt can be equal to or higher than
> (numerically lower than) the mask. See DMSQKF in the GICv5 spec:
>
> A physical interrupt has Sufficient priority to be signaled when all of
> the following are true:
> * The priority of the interrupt is higher than the physical running
> priority for the Physical Interrupt Domain.
> * The priority of the interrupt is equal to or higher than the
> Physical Priority Mask for the Physical Interrupt Domain.
>
> Therefore, we require this `+ 1` for the priority_mask in order to allow
> us to combine the active priority and priority mask. Else, they operate on
> different scales.
>
> I'd tried to explain this in a comment that lies just outside the diff,
> but hadn't explicitly called out that GICv5 operates differently to
> GICv[23] in this regard. Apologies.
Nothing to apologise about, this is me not being able to read.
>
> > }
> >
> > /*
> > @@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu
> > *vcpu)
> >
> > scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> > has_pending = (irq->enabled &&
> > irq_is_pending(irq) &&
> > - irq->priority <=
> > priority_mask);
> > + irq->priority <
> > priority_mask);
>
> I agree that this was wrong and should never have included the
> equality. This was definitely a bug!
Cool. I'll revert the revert of the first hunk and keep the second
one.
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-31 17:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
Hi Luiz,
On Tue, 31 Mar 2026 Luiz Augusto von Dentz wrote:
> Ok, but on 8/8 it seem to suggest the problem still exists which
> trigger the following review:
>
> https://sashiko.dev/#/patchset/20260330-mt7927-bt-support-v4-0-cecc025e7062%40jetm.me
>
> Perhaps we should ajust the commit description if the 19 seconds
> doesn't really occurs when 2/8 is applied.
Good catch. The ~19 second delay is indeed fixed by patch 2/8, so the
note in 8/8 was misleading as written.
I've updated the commit message in 8/8 to clarify:
Note: boards with this USB ID expose only one ISO alternate setting
(alt 0). Without the fix in patch 2/8 ("btmtk: fix ISO interface
setup for single alt setting"), this caused ~19 second initialization
delays. With the fix applied, initialization completes in ~2.6
seconds.
This is addressed in v5:
https://lore.kernel.org/linux-bluetooth/20260331-mt7927-bt-support-v5-0-6f31b4342daa@jetm.me/
Best,
Javier
^ 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