* Re: [PATCH v2 3/7] dt-bindings: soc: samsung: exynos-pmu: deprecate google,pmu-intr-gen-syscon
From: Krzysztof Kozlowski @ 2026-04-01 14:23 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-3-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> The generic property samsung,pmu-intr-gen-syscon should be used
> by default for Samsung Exynos PMU hardware blocks. Update binding
> document to add deprecated flag for google,pmu-intr-gen-syscon
> property.
> While at this, also add dependency to not allow usage of both
> above mentioned properties in the same time.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
This should be squashed. Otherwise you add incorrect code - duplicated
property - which only later you adjust/correct.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Andy Shevchenko @ 2026-04-01 14:24 UTC (permalink / raw)
To: Erim, Salih
Cc: Simek, Michal, Jonathan Cameron, Christofer Jonason,
O'Griofa, Conall, lars@metafoo.de, dlechner@baylibre.com,
nuno.sa@analog.com, andy@kernel.org,
victor.jonsson@guidelinegeo.com, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <IA1PR12MB77369F79026F7BCB1D9C64999F50A@IA1PR12MB7736.namprd12.prod.outlook.com>
On Wed, Apr 1, 2026 at 4:58 PM Erim, Salih <Salih.Erim@amd.com> wrote:
> > -----Original Message-----
> > From: Erim, Salih <Salih.Erim@amd.com>
> > Sent: Wednesday, April 1, 2026 2:13 PM
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> > [AMD Official Use Only - AMD Internal Distribution Only]
>
> I am deeply sorry about these markings. Please try to ignore them, and I will do my best to escape from them.
Maybe, but ignoring them might be subject to law enforcement or other
legal actions. You must get rid of them for your OSS contributions.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 1/4] perf arm_spe: Make a function to get the MIDR
From: James Clark @ 2026-04-01 14:25 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
In-Reply-To: <20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org>
We'll need the MIDR to dump IMPDEF events in the next commits so extract
a function for it.
No functional changes intended.
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 70dd9bee47c7..7447b000f9cd 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -958,14 +958,9 @@ static void arm_spe__synth_memory_level(struct arm_spe_queue *speq,
}
}
-static void arm_spe__synth_ds(struct arm_spe_queue *speq,
- const struct arm_spe_record *record,
- union perf_mem_data_src *data_src)
+static int arm_spe__get_midr(struct arm_spe *spe, int cpu, u64 *midr)
{
- struct arm_spe *spe = speq->spe;
- u64 *metadata = NULL;
- u64 midr;
- unsigned int i;
+ u64 *metadata;
/* Metadata version 1 assumes all CPUs are the same (old behavior) */
if (spe->metadata_ver == 1) {
@@ -973,15 +968,28 @@ static void arm_spe__synth_ds(struct arm_spe_queue *speq,
pr_warning_once("Old SPE metadata, re-record to improve decode accuracy\n");
cpuid = perf_env__cpuid(perf_session__env(spe->session));
- midr = strtol(cpuid, NULL, 16);
- } else {
- metadata = arm_spe__get_metadata_by_cpu(spe, speq->cpu);
- if (!metadata)
- return;
-
- midr = metadata[ARM_SPE_CPU_MIDR];
+ *midr = strtol(cpuid, NULL, 16);
+ return 0;
}
+ metadata = arm_spe__get_metadata_by_cpu(spe, cpu);
+ if (!metadata)
+ return -EINVAL;
+
+ *midr = metadata[ARM_SPE_CPU_MIDR];
+ return 0;
+}
+
+static void arm_spe__synth_ds(struct arm_spe_queue *speq,
+ const struct arm_spe_record *record,
+ union perf_mem_data_src *data_src)
+{
+ u64 midr;
+ unsigned int i;
+
+ if (arm_spe__get_midr(speq->spe, speq->cpu, &midr))
+ return;
+
for (i = 0; i < ARRAY_SIZE(data_source_handles); i++) {
if (is_midr_in_range_list(midr, data_source_handles[i].midr_ranges)) {
return data_source_handles[i].ds_synth(record, data_src);
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] perf arm_spe: Dump IMPDEF events
From: James Clark @ 2026-04-01 14:25 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
In the Arm SPE raw data dump, IMPDEF events aren't printed. Add the
ability to add names for some known events or print the raw event number
for unknown events.
For example:
$ perf report -D
... ARM SPE data: size 0xd000 bytes
00000000: b0 18 c6 32 80 00 80 ff a0 PC 0xff80008032c618 el1 ns=1
00000009: 64 e7 42 00 00 CONTEXT 0x42e7 el1
0000000e: 00 00 00 00 00 PAD
00000013: 49 00 LD GP-REG
00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS
On N1 the event line becomes:
00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS LATE-PREFETCH
Or on other cores it becomes:
00000015: 52 16 10 EV RETIRED L1D-ACCESS TLB-ACCESS IMPDEF:12
Signed-off-by: James Clark <james.clark@linaro.org>
---
James Clark (4):
perf arm_spe: Make a function to get the MIDR
perf arm_spe: Turn event name mappings into an array
perf arm_spe: Decode Arm N1 IMPDEF events
perf arm_spe: Print remaining IMPDEF event numbers
tools/perf/util/arm-spe-decoder/Build | 2 +
.../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 147 ++++++++++++++-------
.../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 +-
tools/perf/util/arm-spe.c | 49 ++++---
4 files changed, 135 insertions(+), 68 deletions(-)
---
base-commit: 74e2dbe7be5037a5e5eed6bc1ad562747ac88566
change-id: 20260331-james-spe-impdef-decode-d944f4fdcff7
Best regards,
--
James Clark <james.clark@linaro.org>
^ permalink raw reply
* [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: James Clark @ 2026-04-01 14:25 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
In-Reply-To: <20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org>
From the TRM [1], N1 has one IMPDEF event which isn't covered by the
common list. Add a framework so that more cores can be added in the
future and that the N1 IMPDEF event can be decoded. Also increase the
size of the buffer because we're adding more strings and if it gets
truncated it falls back to a hex dump only.
[1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
Suggested-by: Al Grant <al.grant@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe-decoder/Build | 2 +
.../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
.../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
tools/perf/util/arm-spe.c | 13 ++++---
4 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
index ab500e0efe24..97a298d1e279 100644
--- a/tools/perf/util/arm-spe-decoder/Build
+++ b/tools/perf/util/arm-spe-decoder/Build
@@ -1 +1,3 @@
perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
+
+CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
index c880b0dec3a1..42a7501d4dfe 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
@@ -15,6 +15,8 @@
#include "arm-spe-pkt-decoder.h"
+#include "../../arm64/include/asm/cputype.h"
+
static const char * const arm_spe_packet_name[] = {
[ARM_SPE_PAD] = "PAD",
[ARM_SPE_END] = "END",
@@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
{ .event = 0, .desc = NULL },
};
+static const struct ev_string n1_event_strings[] = {
+ { .event = 12, .desc = "LATE-PREFETCH" },
+ { .event = 0, .desc = NULL },
+};
+
static u64 print_event_list(int *err, char **buf, size_t *buf_len,
const struct ev_string *ev_strings, u64 payload)
{
@@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
return payload;
}
+struct event_print_handle {
+ const struct midr_range *midr_ranges;
+ const struct ev_string *ev_strings;
+};
+
+#define EV_PRINT(range, strings) \
+ { \
+ .midr_ranges = range, \
+ .ev_strings = strings, \
+ }
+
+static const struct midr_range n1_event_encoding_cpus[] = {
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
+ {},
+};
+
+static const struct event_print_handle event_print_handles[] = {
+ EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
+};
+
static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
- char *buf, size_t buf_len)
+ char *buf, size_t buf_len, u64 midr)
{
u64 payload = packet->payload;
int err = 0;
arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
- print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
+ payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
+ payload);
+
+ /* Try to decode IMPDEF bits for known CPUs */
+ for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
+ if (is_midr_in_range_list(midr,
+ event_print_handles[i].midr_ranges))
+ payload = print_event_list(&err, &buf, &buf_len,
+ event_print_handles[i].ev_strings,
+ payload);
+ }
return err;
}
@@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
}
int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
- size_t buf_len)
+ size_t buf_len, u64 midr)
{
int idx = packet->index;
unsigned long long payload = packet->payload;
@@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
break;
case ARM_SPE_EVENTS:
- err = arm_spe_pkt_desc_event(packet, buf, buf_len);
+ err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
break;
case ARM_SPE_OP_TYPE:
err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
index adf4cde320aa..17b067fe3c87 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
@@ -11,7 +11,7 @@
#include <stddef.h>
#include <stdint.h>
-#define ARM_SPE_PKT_DESC_MAX 256
+#define ARM_SPE_PKT_DESC_MAX 512
#define ARM_SPE_NEED_MORE_BYTES -1
#define ARM_SPE_BAD_PACKET -2
@@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
int arm_spe_get_packet(const unsigned char *buf, size_t len,
struct arm_spe_pkt *packet);
-int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
+int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
+ u64 midr);
#endif
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 7447b000f9cd..46f0309c092b 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -135,7 +135,7 @@ struct data_source_handle {
}
static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
- unsigned char *buf, size_t len)
+ unsigned char *buf, size_t len, u64 midr)
{
struct arm_spe_pkt packet;
size_t pos = 0;
@@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
color_fprintf(stdout, color, " ");
if (ret > 0) {
ret = arm_spe_pkt_desc(&packet, desc,
- ARM_SPE_PKT_DESC_MAX);
+ ARM_SPE_PKT_DESC_MAX, midr);
if (!ret)
color_fprintf(stdout, color, " %s\n", desc);
} else {
@@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
}
static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
- size_t len)
+ size_t len, u64 midr)
{
printf(".\n");
- arm_spe_dump(spe, buf, len);
+ arm_spe_dump(spe, buf, len, midr);
}
static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
@@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
/* Dump here now we have copied a piped trace out of the pipe */
if (dump_trace) {
if (auxtrace_buffer__get_data(buffer, fd)) {
+ u64 midr = 0;
+
+ arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
arm_spe_dump_event(spe, buffer->data,
- buffer->size);
+ buffer->size, midr);
auxtrace_buffer__put_data(buffer);
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] perf arm_spe: Turn event name mappings into an array
From: James Clark @ 2026-04-01 14:25 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
In-Reply-To: <20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org>
This is so we can have a single function that prints events and can be
used with multiple mappings from different CPUs. Remove any bit that was
printed so that later we can print out the remaining unknown impdef
bits.
No functional changes intended.
Signed-off-by: James Clark <james.clark@linaro.org>
---
.../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 88 +++++++++++-----------
1 file changed, 43 insertions(+), 45 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
index 5769ba2f4140..c880b0dec3a1 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
@@ -276,6 +276,48 @@ static int arm_spe_pkt_out_string(int *err, char **buf_p, size_t *blen,
return ret;
}
+struct ev_string {
+ u8 event;
+ const char *desc;
+};
+
+static const struct ev_string common_ev_strings[] = {
+ { .event = EV_EXCEPTION_GEN, .desc = "EXCEPTION-GEN" },
+ { .event = EV_RETIRED, .desc = "RETIRED" },
+ { .event = EV_L1D_ACCESS, .desc = "L1D-ACCESS" },
+ { .event = EV_L1D_REFILL, .desc = "L1D-REFILL" },
+ { .event = EV_TLB_ACCESS, .desc = "TLB-ACCESS" },
+ { .event = EV_TLB_WALK, .desc = "TLB-REFILL" },
+ { .event = EV_NOT_TAKEN, .desc = "NOT-TAKEN" },
+ { .event = EV_MISPRED, .desc = "MISPRED" },
+ { .event = EV_LLC_ACCESS, .desc = "LLC-ACCESS" },
+ { .event = EV_LLC_MISS, .desc = "LLC-REFILL" },
+ { .event = EV_REMOTE_ACCESS, .desc = "REMOTE-ACCESS" },
+ { .event = EV_ALIGNMENT, .desc = "ALIGNMENT" },
+ { .event = EV_TRANSACTIONAL, .desc = "TXN" },
+ { .event = EV_PARTIAL_PREDICATE, .desc = "SVE-PARTIAL-PRED" },
+ { .event = EV_EMPTY_PREDICATE, .desc = "SVE-EMPTY-PRED" },
+ { .event = EV_L2D_ACCESS, .desc = "L2D-ACCESS" },
+ { .event = EV_L2D_MISS, .desc = "L2D-MISS" },
+ { .event = EV_CACHE_DATA_MODIFIED, .desc = "HITM" },
+ { .event = EV_RECENTLY_FETCHED, .desc = "LFB" },
+ { .event = EV_DATA_SNOOPED, .desc = "SNOOPED" },
+ { .event = EV_STREAMING_SVE_MODE, .desc = "STREAMING-SVE" },
+ { .event = EV_SMCU, .desc = "SMCU" },
+ { .event = 0, .desc = NULL },
+};
+
+static u64 print_event_list(int *err, char **buf, size_t *buf_len,
+ const struct ev_string *ev_strings, u64 payload)
+{
+ for (const struct ev_string *ev = ev_strings; ev->desc != NULL; ev++) {
+ if (payload & BIT(ev->event))
+ arm_spe_pkt_out_string(err, buf, buf_len, " %s", ev->desc);
+ payload &= ~BIT(ev->event);
+ }
+ return payload;
+}
+
static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
char *buf, size_t buf_len)
{
@@ -283,51 +325,7 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
int err = 0;
arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
-
- if (payload & BIT(EV_EXCEPTION_GEN))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " EXCEPTION-GEN");
- if (payload & BIT(EV_RETIRED))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " RETIRED");
- if (payload & BIT(EV_L1D_ACCESS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " L1D-ACCESS");
- if (payload & BIT(EV_L1D_REFILL))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " L1D-REFILL");
- if (payload & BIT(EV_TLB_ACCESS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " TLB-ACCESS");
- if (payload & BIT(EV_TLB_WALK))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " TLB-REFILL");
- if (payload & BIT(EV_NOT_TAKEN))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " NOT-TAKEN");
- if (payload & BIT(EV_MISPRED))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " MISPRED");
- if (payload & BIT(EV_LLC_ACCESS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " LLC-ACCESS");
- if (payload & BIT(EV_LLC_MISS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " LLC-REFILL");
- if (payload & BIT(EV_REMOTE_ACCESS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " REMOTE-ACCESS");
- if (payload & BIT(EV_ALIGNMENT))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " ALIGNMENT");
- if (payload & BIT(EV_TRANSACTIONAL))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " TXN");
- if (payload & BIT(EV_PARTIAL_PREDICATE))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " SVE-PARTIAL-PRED");
- if (payload & BIT(EV_EMPTY_PREDICATE))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " SVE-EMPTY-PRED");
- if (payload & BIT(EV_L2D_ACCESS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " L2D-ACCESS");
- if (payload & BIT(EV_L2D_MISS))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " L2D-MISS");
- if (payload & BIT(EV_CACHE_DATA_MODIFIED))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " HITM");
- if (payload & BIT(EV_RECENTLY_FETCHED))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " LFB");
- if (payload & BIT(EV_DATA_SNOOPED))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " SNOOPED");
- if (payload & BIT(EV_STREAMING_SVE_MODE))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " STREAMING-SVE");
- if (payload & BIT(EV_SMCU))
- arm_spe_pkt_out_string(&err, &buf, &buf_len, " SMCU");
+ print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
return err;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 4/4] perf arm_spe: Print remaining IMPDEF event numbers
From: James Clark @ 2026-04-01 14:25 UTC (permalink / raw)
To: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Al Grant
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark
In-Reply-To: <20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org>
Any IMPDEF events not printed out from a known core's IMPDEF list or for
a completely unknown core will still not be shown to the user. Fix this
by printing the remaining bits as comma separated raw numbers, e.g.
"IMPDEF:1,2,3,4".
Suggested-by: Al Grant <al.grant@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
index 42a7501d4dfe..b93712ce0aca 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
@@ -364,6 +364,24 @@ static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
payload);
}
+ /*
+ * Print remaining IMPDEF bits that weren't printed above as raw
+ * "IMPDEF:1,2,3,4" etc.
+ */
+ if (payload) {
+ arm_spe_pkt_out_string(&err, &buf, &buf_len, " IMPDEF:",
+ payload);
+ for (int i = 0; i < 64; i++) {
+ const char *sep = payload & (payload - 1) ? "," : "";
+
+ if (payload & BIT(i)) {
+ arm_spe_pkt_out_string(&err, &buf, &buf_len,
+ "%d%s", i, sep);
+ payload &= ~BIT(i);
+ }
+ }
+ }
+
return err;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 5/7] soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
From: Krzysztof Kozlowski @ 2026-04-01 14:26 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-5-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> + regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
> + mask, (0 << cpu));
> +
> + regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
> +
> + regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR,
> + reg & mask);
> +
> + regmap_update_bits(pmu_context->pmureg,
> + EXYNOS850_CLUSTER_CPU_INT_EN(this_cluster, cluster_cpu),
> + 1 << 3, 0 << 3);
> + return 0;
> +}
> +
> +const struct exynos_pmu_data exynos850_pmu_data = {
> + .pmu_cpuhp = true,
> + .cpu_pmu_offline = exynos850_cpu_pmu_offline,
> + .cpu_pmu_online = exynos850_cpu_pmu_online,
> +};
> +
Unnecessary blank line.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] MAINTAINERS: add exynos850-pmu.c to Exynos850 entry
From: Krzysztof Kozlowski @ 2026-04-01 14:28 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-6-c5a760a3e259@linaro.org>
On 01/04/2026 06:51, Alexey Klimov wrote:
> Update Exynos850 entry to include new file
> drivers/soc/samsung/exynos850-pmu.c. Add myself as M
> there.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e14e6f874e05..4b28e92b4d9b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23601,6 +23601,7 @@ F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
>
> SAMSUNG EXYNOS850 SoC SUPPORT
> M: Sam Protsenko <semen.protsenko@linaro.org>
> +M: Alexey Klimov <alexey.klimov@linaro.org>
I am surprised to see this because I did not find many reviews from your
side before.
Please first engage in reviewing of this platform, before assigning
yourself as a maintainer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: exynos850: add PMU interrupt generation node
From: Krzysztof Kozlowski @ 2026-04-01 14:29 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, linux-samsung-soc, Peter Griffin,
André Draszik, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-7-c5a760a3e259@linaro.org>
On 01/04/2026 06:52, Alexey Klimov wrote:
> Add pmu_intr_gen node for Exynos850. This hw block is required
> for different power management routines like CPU hotplug and
> different sleep and idle states.
> Also reference this node from main PMU node.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
I took a brief look at other patches and seemed fine. Anyway, my tree is
currently closed for new features till the end of the merge window so I
will probably take a more detailed look after it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8] arm64: Use static call trampolines when kCFI is enabled
From: Catalin Marinas @ 2026-04-01 14:31 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Will Deacon, linux-arm-kernel, Ard Biesheuvel, kernel-team,
linux-hardening, Mark Rutland, Carlos Llamas, Sami Tolvanen,
Sean Christopherson, Kees Cook, Peter Zijlstra, Will McVicker
In-Reply-To: <2b0b9c69-650c-46bb-8579-4af85c17b8ab@app.fastmail.com>
On Wed, Apr 01, 2026 at 02:03:22PM +0200, Ard Biesheuvel wrote:
>
> On Wed, 1 Apr 2026, at 12:03, Will Deacon wrote:
> > On Tue, 31 Mar 2026 13:04:23 +0200, Ard Biesheuvel wrote:
> >> Implement arm64 support for the 'unoptimized' static call variety, which
> >> routes all calls through a trampoline that performs a tail call to the
> >> chosen function, and wire it up for use when kCFI is enabled. This works
> >> around an issue with kCFI and generic static calls, where the prototypes
> >> of default handlers such as __static_call_nop() and __static_call_ret0()
> >> don't match the expected prototype of the call site, resulting in kCFI
> >> false positives [0].
> >>
> >> [...]
> >
> > Applied to arm64 (for-next/fixes), thanks!
> >
> > [1/1] arm64: Use static call trampolines when kCFI is enabled
> > https://git.kernel.org/arm64/c/e70c2335f889
> >
>
> Thanks,
>
> I just spotted that the function name gets stringified twice inadvertently.
>
> E.g., the assembler may see
>
> .quad "__static_call_return0"
>
> rather than the intended
>
> .quad __static_call_return0
>
> The assembler does not seem to care, and still emits an ABS64 relocation against the correct symbol, but it is definitely unintentional.
>
> I can send a follow-up fix if you prefer, or you could just tweak the patch in place:
>
> --- a/arch/arm64/include/asm/static_call.h
> +++ b/arch/arm64/include/asm/static_call.h
> @@ -16,7 +16,7 @@
> " .popsection \n" \
> " .pushsection .rodata, \"a\" \n" \
> " .align 3 \n" \
> - "1: .quad " #target " \n" \
> + "1: .quad " target " \n" \
> " .popsection \n")
Not sure Will is going to look at this until next week. I folded it into
the arm64 for-next/fixes branch and pushed out.
--
Catalin
^ permalink raw reply
* RE: Question: interrupt randomness and handle_percpu_devid_irq()
From: Michael Kelley @ 2026-04-01 14:33 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Thomas Gleixner
Cc: Michael Kelley, Marc Zyngier, Lorenzo Pieralisi,
linux-arm-kernel@lists.infradead.org, LKML, Jan Kiszka
In-Reply-To: <20260401141417.6uJk69i9@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Sent: Wednesday, April 1, 2026 7:14 AM
> On 2026-03-20 16:10:37 [+0100], Thomas Gleixner wrote:
> > On Thu, Mar 19 2026 at 19:34, Michael Kelley wrote:
> > > The function header comment for handle_percpu_devid_irq() says that it is the
> > > same as handle_percpu_irq(), but with the addition of a pointer to a percpu
> > > variable with the real device id. That makes sense. But there's another difference:
> > > handle_percpu_irq() calls add_interrupt_randomness() [via handle_irq_event_percpu()],
> > > while handle_percpu_devid_irq() does not.
> > >
> > > Question: Is there a reason for this difference in handling interrupt randomness?
> > > Or is it just an oversight? handle_percpu_devid_irq() is used, for example, for the
> > > SGIs and PPIs on the GICv3 chip, so I wondered if IPIs (as built on SGIs) & PPIs
> > > specifically did not want the overhead of add_interrupt_randomness(). But then
> > > GICv5 is doing IPIs using LPIs, which use handle_percpu_irq() and hence *do*
> > > add interrupt randomness. That seemed inconsistent, which didn't help provide
> > > an answer.
> > >
> > > The question arises in the context of Linux guests running on Hyper-V. Hyper-V
> > > VMBus interrupts to the guest are per-CPU interrupts in Linux, using a PPI on
> > > arm64. So these interrupts do not call add_interrupt_randomness(), which is a
> > > problem because these guests don't have much other way to get entropy. To
> > > fix this, the VMBus ISR has always had an explicit call to
> > > add_interrupt_randomness(). But maybe that's not the best approach, and
> > > handle_percpu_devid_irq() should be fixed to call add_interrupt_randomness().
> >
> > I don't think there is a real good reason unless any of those interrupts
> > is NMI like.
>
> So we could wire up the generic/ arch code here and feed the
> "randomness" from there and it from the driver bits.
>
I'm planning to submit patches to do that, and remove the
add_interrupt_randomness() calls from the VMBus ISRs. Hopefully will
get the patches out today or tomorrow.
Michael
^ permalink raw reply
* Re: RE: Question: interrupt randomness and handle_percpu_devid_irq()
From: Sebastian Andrzej Siewior @ 2026-04-01 14:34 UTC (permalink / raw)
To: Michael Kelley
Cc: Thomas Gleixner, Marc Zyngier, Lorenzo Pieralisi,
linux-arm-kernel@lists.infradead.org, LKML, Jan Kiszka
In-Reply-To: <SN6PR02MB4157BC5ADA592D8D6084C6DED450A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 2026-04-01 14:33:34 [+0000], Michael Kelley wrote:
> I'm planning to submit patches to do that, and remove the
> add_interrupt_randomness() calls from the VMBus ISRs. Hopefully will
> get the patches out today or tomorrow.
Thank you.
> Michael
Sebastian
^ permalink raw reply
* Re: [PATCH 13/33] rust: block: update `const_refs_to_static` MSRV TODO comment
From: Gary Guo @ 2026-04-01 14:37 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-14-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> `feature(const_refs_to_static)` was stabilized in Rust 1.83.0 [1].
>
> Thus update the comment to reflect that.
>
> Link: https://github.com/rust-lang/rust/pull/129759 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/block/mq/gen_disk.rs | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-04-01 14:37 UTC (permalink / raw)
To: Shivendra Pratap
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: <93a78bc2-4fd1-41bd-bf4a-b433b06fc218@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>
>
> 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},
These strings match the command userspace issue right ? I think that we
should make them match the corresponding PSCI reset types, the list above
maps command to reboot_mode values and those can belong to any reboot
mode driver to be honest they don't make much sense in a PSCI reboot
mode driver only.
It is a question for everyone here: would it make sense to make these
predefined resets a set of strings, eg:
psci-system-reset
psci-system-reset2-arch-warm-reset
and then vendor resets:
psci-system-reset2-vendor-reset
at least we know what a string maps to ?
We can export a function from the PSCI driver to detect whether PSCI
SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
instance that we can call from this driver to detect its presence.
> > > +};
> > > +
> > > +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.
Given what I say above, I believe that something we can do is mapping the magic
to an enum like:
PSCI_SYSTEM_RESET
PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
PSCI_SYSTEM_RESET2_VENDOR_RESET
and can add a probe function into PSCI driver similar to psci_has_osi_support() but
to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
depending on its presence.
It is getting a bit hairy, agreed, but I am not sure there is cleaner ways
of pulling this off.
Lorenzo
>
> > > +
> > > + 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 14/33] rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)
From: Gary Guo @ 2026-04-01 14:38 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-15-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's `bindgen` versions as our minimum
> supported version.
>
> Debian Trixie was released with `bindgen` 0.71.1, which it still uses
> to this day [2].
>
> Debian Trixie's release happened on 2025-08-09 [3], which means that a
> fair amount of time has passed since its release for kernel developers
> to upgrade.
>
> Thus bump the minimum to the new version.
>
> Then, in later commits, clean up most of the workarounds and other bits
> that this upgrade of the minimum allows us.
>
> Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already
> unsupported Ubuntu 25.04 had it), and they also provide versioned packages
> with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5].
>
> Link: https://lwn.net/Articles/1050174/ [1]
> Link: https://packages.debian.org/trixie/bindgen [2]
> Link: https://www.debian.org/releases/trixie/ [3]
> Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4]
> Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 7.1
From: Arnd Bergmann @ 2026-04-01 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Florian Fainelli
Cc: soc, Rob Herring, Gregor Herburger, Maíra Canal,
Stefan Wahren, linux-arm-kernel, Kevin Hilman,
bcm-kernel-feedback-list
In-Reply-To: <2e47f487-da04-411d-bf78-4c76ac793a91@kernel.org>
On Wed, Apr 1, 2026, at 14:02, Krzysztof Kozlowski wrote:
> On 01/04/2026 13:18, Krzysztof Kozlowski wrote:
>> On Mon, Mar 23, 2026 at 12:02:39PM -0700, Florian Fainelli wrote:
>>
>> I think the same issue was last time and repo is non korg, so nothing
>> seems to improve.
>
>
> Maybe last time I mentioned this only internally or on IRC, so could get
> lost. Please get your key in to the kernel keyring, to solve above. Pull
> is not rejected, but I leave it to Arnd who might have your key.
>
> How to get key signed? Obviously conferences are the easiest way, but
> other is to find people around you or on your travel itinerary via
> ksmap. Eventually many people do video call cross signing, so even
> travel is not needed. I video signed twice, but that was an exception
> because I prefer to meet in person. Kernel wiki has guideline on all
> this, so I am not saying anything new here.
I think what happened is that the key expired. I can see that
Florian is using the same key as the last 113 times, and I see
it has signatures from other developers, but the copy I have
expired in 2024, which probably caused it to disappear from
the keyservers.
this is what I see:
$ gpg --list-sigs 9BE46ADFE60625D891F72B8587D0969C44070704
pub dsa1024/61579915B563760E 2008-09-16 [SCA] [expired: 2024-11-06]
FE4FA16F65261D8BDA57BCBD61579915B563760E
uid [ expired] Florian Fainelli <f.fainelli@gmail.com>
sig DE95E6B5B9FA86CB 2008-09-16 Florian Fainelli <florian.fainelli@openpattern.org>
sig 9B1F67D46FF7D7AB 2008-09-16 Florian Fainelli <florian.fainelli@telecomint.eu>
sig F91A73ED49C617B5 2008-09-16 Florian Fainelli <florian@minet.net>
sig 972BE49811AD8F26 2008-09-16 Florian Fainelli <florian@openwrt.org>
sig 3 61579915B563760E 2008-09-16 Florian Fainelli <f.fainelli@gmail.com>
sig 3 61579915B563760E 2014-11-09 Florian Fainelli <f.fainelli@gmail.com>
sig 3A8F3B2F5A7C9849 2016-03-12 Michael Turquette <mturquette@baylibre.com>
sig E6BF0DCBA6694C84 2017-04-08 Andrew Lunn <andrew@lunn.ch>
sig 987E58D467ED50B8 2017-04-09 [User ID not found]
Arnd
^ permalink raw reply
* Re: [GIT PULL 2/2] Broadcom devicetree-arm64 changes for 7.1
From: Krzysztof Kozlowski @ 2026-04-01 14:47 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: soc, Rob Herring, Gregor Herburger, Maíra Canal,
Stefan Wahren, linux-arm-kernel, Kevin Hilman,
bcm-kernel-feedback-list
In-Reply-To: <df52b2ae-4b8b-487a-bb6b-07bf021500b5@app.fastmail.com>
On 01/04/2026 16:37, Arnd Bergmann wrote:
> On Wed, Apr 1, 2026, at 14:02, Krzysztof Kozlowski wrote:
>> On 01/04/2026 13:18, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 23, 2026 at 12:02:39PM -0700, Florian Fainelli wrote:
>>>
>>> I think the same issue was last time and repo is non korg, so nothing
>>> seems to improve.
>>
>>
>> Maybe last time I mentioned this only internally or on IRC, so could get
>> lost. Please get your key in to the kernel keyring, to solve above. Pull
>> is not rejected, but I leave it to Arnd who might have your key.
>>
>> How to get key signed? Obviously conferences are the easiest way, but
>> other is to find people around you or on your travel itinerary via
>> ksmap. Eventually many people do video call cross signing, so even
>> travel is not needed. I video signed twice, but that was an exception
>> because I prefer to meet in person. Kernel wiki has guideline on all
>> this, so I am not saying anything new here.
>
> I think what happened is that the key expired. I can see that
> Florian is using the same key as the last 113 times, and I see
> it has signatures from other developers, but the copy I have
> expired in 2024, which probably caused it to disappear from
> the keyservers.
>
> this is what I see:
>
> $ gpg --list-sigs 9BE46ADFE60625D891F72B8587D0969C44070704
> pub dsa1024/61579915B563760E 2008-09-16 [SCA] [expired: 2024-11-06]
dsa1024 might be another answer... DSA1024 was deprecated by NIST in
2013, so maybe gnugp even drops it just like keys with too weak signatures?
But another problem is that I do not see it in the `git log` of keyring
at all which suggests it wasn't ever submitted.
I don't think DSA1024 can be accepted now in keyring, so this requires a
new key, cross signed by the old one.
> FE4FA16F65261D8BDA57BCBD61579915B563760E
> uid [ expired] Florian Fainelli <f.fainelli@gmail.com>
> sig DE95E6B5B9FA86CB 2008-09-16 Florian Fainelli <florian.fainelli@openpattern.org>
> sig 9B1F67D46FF7D7AB 2008-09-16 Florian Fainelli <florian.fainelli@telecomint.eu>
> sig F91A73ED49C617B5 2008-09-16 Florian Fainelli <florian@minet.net>
> sig 972BE49811AD8F26 2008-09-16 Florian Fainelli <florian@openwrt.org>
> sig 3 61579915B563760E 2008-09-16 Florian Fainelli <f.fainelli@gmail.com>
> sig 3 61579915B563760E 2014-11-09 Florian Fainelli <f.fainelli@gmail.com>
> sig 3A8F3B2F5A7C9849 2016-03-12 Michael Turquette <mturquette@baylibre.com>
> sig E6BF0DCBA6694C84 2017-04-08 Andrew Lunn <andrew@lunn.ch>
> sig 987E58D467ED50B8 2017-04-09 [User ID not found]
>
> Arnd
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Pass a 64bit function-id in the SMC handlers
From: Marc Zyngier @ 2026-04-01 14:55 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, joey.gouly, korneld, mrigendra.chaubey, oupton,
perlarsen, suzuki.poulose, will, yuzenghui
In-Reply-To: <20260401123201.389906-1-sebastianene@google.com>
On Wed, 01 Apr 2026 13:32:01 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> Make the SMC handlers accept a 64bit value for the function-id to keep
> it uniform with the rest of the code and prevent a u64 -> u32 -> u64
> conversion as it currently happens when we handle PSCI.
That seems overly creative. The spec says (2.5, from ARM DEN 0028 1.6
G):
"The Function Identifier is passed on W0 on every SMC and HVC
call. Its 32-bit integer value indicates which function is being
requested by the caller. It is always passed as the first argument to
every SMC or HVC call in R0 or W0."
which indicates that it is *always* a 32bit value.
So if you have a 64bit value somewhere, *that* should be fixed, not
propagated arbitrarily.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Arnd Bergmann @ 2026-04-01 14:56 UTC (permalink / raw)
To: Lorenzo Pieralisi, Shivendra Pratap
Cc: 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, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>> > > +#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},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
>
> at least we know what a string maps to ?
>
> We can export a function from the PSCI driver to detect whether PSCI
> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
> instance that we can call from this driver to detect its presence.
Sorry I've been out of the loop for this series for a while, but
can someone refresh me on why we got back to mixing in
the 'enum reboot_mode' from legacy i386 and arm32 into the new
interface?
I don't mind having whichever strings are defined for PSCI present
in the user interface, but this seems like a mistake to me.
If at all possible, lets define your own magic constants that
are not tied to "enum reboot_mode" or the legacy reboot= command
line argument.
Arnd
^ permalink raw reply
* Re: [PATCH 01/33] rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)
From: Benno Lossin @ 2026-04-01 14:57 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Trevor Gross,
rust-for-linux, linux-kbuild, Lorenzo Stoakes, Vlastimil Babka,
Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-2-ojeda@kernel.org>
On Wed Apr 1, 2026 at 1:45 PM CEST, Miguel Ojeda wrote:
> As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1],
> we are going to follow Debian Stable's Rust versions as our minimum
> supported version.
>
> Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it
> still uses to this day [3] (i.e. no update to Rust 1.85.1).
>
> Debian Trixie's release happened on 2025-08-09 [4], which means that a
> fair amount of time has passed since its release for kernel developers
> to upgrade.
>
> Thus bump the minimum to the new version.
>
> Then, in later commits, clean up most of the workarounds and other bits
> that this upgrade of the minimum allows us.
>
> pin-init was left as-is since the patches come from upstream. And the
> vendored crates are unmodified, since we do not want to change those.
>
> Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the
> Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION`
> tests can also be updated, but there are no suitable ones to simplify.
>
> Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also
> provide versioned packages with a Rust 1.85.1 toolchain even back to
> Ubuntu 22.04 LTS [6].
>
> Link: https://lwn.net/Articles/1050174/ [1]
> Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2]
> Link: https://packages.debian.org/trixie/rustc [3]
> Link: https://www.debian.org/releases/trixie/ [4]
> Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5]
> Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Very happy to see this!
Acked-by: Benno Lossin <lossin@kernel.org>
Cheers,
Benno
> ---
> Documentation/process/changes.rst | 2 +-
> scripts/min-tool-version.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Gary Guo @ 2026-04-01 14:58 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-16-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> It is not possible anymore to fall into the issue that this warning was
> alerting about given the `bindgen` version bump.
>
> Thus simplify by removing the machinery behind it, including tests.
The scripts/rust_is_available.sh change looks correct to me, although I couldn't
get scripts/rust_is_available_test.py to run on NixOS.
Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For
obvious reasons that will only work if python is located /usr/bin/python.
Best,
Gary
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> scripts/rust_is_available.sh | 13 ------------
> scripts/rust_is_available_bindgen_0_66.h | 2 --
> scripts/rust_is_available_test.py | 26 +++---------------------
> 3 files changed, 3 insertions(+), 38 deletions(-)
> delete mode 100644 scripts/rust_is_available_bindgen_0_66.h
>
> diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
> index d2323de0692c..77896e31dab5 100755
> --- a/scripts/rust_is_available.sh
> +++ b/scripts/rust_is_available.sh
> @@ -163,19 +163,6 @@ if [ "$rust_bindings_generator_cversion" -lt "$rust_bindings_generator_min_cvers
> echo >&2 "***"
> exit 1
> fi
> -if [ "$rust_bindings_generator_cversion" -eq 6600 ] ||
> - [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
> - # Distributions may have patched the issue (e.g. Debian did).
> - if ! "$BINDGEN" $(dirname $0)/rust_is_available_bindgen_0_66.h >/dev/null; then
> - echo >&2 "***"
> - echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
> - echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567),"
> - echo >&2 "*** unless patched (like Debian's)."
> - echo >&2 "*** Your version: $rust_bindings_generator_version"
> - echo >&2 "***"
> - warning=1
> - fi
> -fi
>
> # Check that the `libclang` used by the Rust bindings generator is suitable.
> #
> diff --git a/scripts/rust_is_available_bindgen_0_66.h b/scripts/rust_is_available_bindgen_0_66.h
> deleted file mode 100644
> index c0431293421c..000000000000
> --- a/scripts/rust_is_available_bindgen_0_66.h
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#define A "\0"
> diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
> index 4fcc319dea84..b66fa5933844 100755
> --- a/scripts/rust_is_available_test.py
> +++ b/scripts/rust_is_available_test.py
> @@ -54,17 +54,12 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen(cls, version_stdout, libclang_stderr, version_0_66_patched=False, libclang_concat_patched=False):
> + def generate_bindgen(cls, version_stdout, libclang_stderr, libclang_concat_patched=False):
> if libclang_stderr is None:
> libclang_case = f"raise SystemExit({cls.bindgen_default_bindgen_libclang_failure_exit_code})"
> else:
> libclang_case = f"print({repr(libclang_stderr)}, file=sys.stderr)"
>
> - if version_0_66_patched:
> - version_0_66_case = "pass"
> - else:
> - version_0_66_case = "raise SystemExit(1)"
> -
> if libclang_concat_patched:
> libclang_concat_case = "print('pub static mut foofoo: ::std::os::raw::c_int;')"
> else:
> @@ -74,8 +69,6 @@ else:
> import sys
> if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
> {libclang_case}
> -elif "rust_is_available_bindgen_0_66.h" in " ".join(sys.argv):
> - {version_0_66_case}
> elif "rust_is_available_bindgen_libclang_concat.h" in " ".join(sys.argv):
> {libclang_concat_case}
> else:
> @@ -83,8 +76,8 @@ else:
> """)
>
> @classmethod
> - def generate_bindgen_version(cls, stdout, version_0_66_patched=False):
> - return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr, version_0_66_patched)
> + def generate_bindgen_version(cls, stdout):
> + return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr)
>
> @classmethod
> def generate_bindgen_libclang_failure(cls):
> @@ -245,19 +238,6 @@ else:
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
> self.assertIn(f"Rust bindings generator '{bindgen}' is too old.", result.stderr)
>
> - def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}")
> - result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
> - self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
> -
> - def test_bindgen_bad_version_0_66_0_and_0_66_1_patched(self):
> - for version in ("0.66.0", "0.66.1"):
> - with self.subTest(version=version):
> - bindgen = self.generate_bindgen_version(f"bindgen {version}", True)
> - result = self.run_script(self.Expected.SUCCESS, { "BINDGEN": bindgen })
> -
> def test_bindgen_libclang_failure(self):
> bindgen = self.generate_bindgen_libclang_failure()
> result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
^ permalink raw reply
* RE: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Erim, Salih @ 2026-04-01 15:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Simek, Michal, Jonathan Cameron, Christofer Jonason,
O'Griofa, Conall, lars@metafoo.de, dlechner@baylibre.com,
nuno.sa@analog.com, andy@kernel.org,
victor.jonsson@guidelinegeo.com, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <CAHp75Vcg1u86z_TWwz+1Gk9QQ9RB63QmNcqpkGa5HQHZhSE=5Q@mail.gmail.com>
Hi Andy,
...
> On Wed, Apr 1, 2026 at 4:58 PM Erim, Salih <Salih.Erim@amd.com> wrote:
> > > -----Original Message-----
> > > From: Erim, Salih <Salih.Erim@amd.com>
> > > Sent: Wednesday, April 1, 2026 2:13 PM
>
>
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > I am deeply sorry about these markings. Please try to ignore them, and I will do
> my best to escape from them.
>
> Maybe, but ignoring them might be subject to law enforcement or other legal actions.
> You must get rid of them for your OSS contributions.
You are right, My mistake is replying OSS emails with Outlook, it does marking automatically.
I need to start using another email - mutt, thunderbird etc. Thanks for the warning.
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks,
Salih.
^ permalink raw reply
* Re: [PATCH 17/33] rust: kbuild: update `bindgen --rust-target` version and replace comment
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-18-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> As the comment in the `Makefile` explains, previously, we needed to
> limit ourselves to the list of Rust versions known by `bindgen` for its
> `--rust-target` option.
>
> In other words, we needed to consult the versions known by the minimum
> version of `bindgen` that we supported.
>
> Now that we bumped the minimum version of `bindgen`, that limitation
> does not apply anymore.
>
> Thus replace the comment and simply write our minimum supported Rust
> version there, which is much simpler.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/Makefile | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH 18/33] rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1
From: Gary Guo @ 2026-04-01 15:05 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet
Cc: Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, rust-for-linux, linux-kbuild, Lorenzo Stoakes,
Vlastimil Babka, Liam R . Howlett, Uladzislau Rezki, linux-block,
moderated for non-subscribers, Alexandre Ghiti, linux-riscv,
nouveau, dri-devel, Rae Moar, linux-kselftest, kunit-dev,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, linux-kernel,
Shuah Khan, linux-doc
In-Reply-To: <20260401114540.30108-19-ojeda@kernel.org>
On Wed Apr 1, 2026 at 12:45 PM BST, Miguel Ojeda wrote:
> Until the version bump of `bindgen`, we needed to pass a dummy parameter
> to avoid failing the `--version` call.
>
> Thus remove it.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> init/Kconfig | 7 +------
> scripts/rust_is_available.sh | 8 +-------
> 2 files changed, 2 insertions(+), 13 deletions(-)
^ 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