* Re: [PATCH RFC] ACPI: processor: idle: Do not propagate acpi_processor_ffh_lpi_probe() -ENODEV
From: Breno Leitao @ 2026-04-14 12:05 UTC (permalink / raw)
To: lihuisong (C)
Cc: Rafael J. Wysocki, Len Brown, lpieralisi, catalin.marinas, will,
Rafael J. Wysocki, linux-acpi, linux-kernel, pjaroszynski,
guohanjun, sudeep.holla, linux-arm-kernel, rmikey, kernel-team
In-Reply-To: <6694ca7c-13bf-4e7d-9621-bc992cbf96a7@huawei.com>
On Tue, Apr 14, 2026 at 07:31:29PM +0800, lihuisong (C) wrote:
>
> On 4/14/2026 6:21 PM, Breno Leitao wrote:
> > Hello Huisong,
> >
> > On Tue, Apr 14, 2026 at 05:43:51PM +0800, lihuisong (C) wrote:
> > > But it is a real issue. Thanks for your report.
> > > I think the best way to fix your issue is that remove this verification in
> > > psci_acpi_cpu_init_idle().
> > > Because it is legal for platform to report one LPI state.
> > > This function just needs to verify the LPI states which are FFH.
> > Thank you for the prompt feedback.
> >
> > Would this approach work?
> >
> > commit 6c9d52840a4f778cc989838ba76ee51416e85de3
> > Author: Breno Leitao <leitao@debian.org>
> > Date: Tue Apr 14 03:16:08 2026 -0700
> >
> > ACPI: processor: idle: Allow platforms with only one LPI state
> > psci_acpi_cpu_init_idle() rejects platforms where power.count - 1 <= 0
> > by returning -ENODEV. However, having a single LPI state (WFI) is a
> > valid configuration. The function's purpose is to verify FFH idle states,
> > and when count is zero, there are simply no FFH states to validate —
> > this is not an error.
> > On NVIDIA Grace (aarch64) systems with PSCIv1.1, power.count is 1 for
> > all 72 CPUs, so the probe fails with -ENODEV. After commit cac173bea57d
> > ("ACPI: processor: idle: Rework the handling of
> > acpi_processor_ffh_lpi_probe()"), this failure propagates up and prevents
> > cpuidle registration entirely.
> > Change the check from (count <= 0) to (count < 0) so that platforms
> > with only WFI are accepted. The for loop naturally handles count == 0
> > by not iterating.
> > Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> >
> > diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> > index 801f9c4501425..7791b751042ce 100644
> > --- a/drivers/acpi/arm64/cpuidle.c
> > +++ b/drivers/acpi/arm64/cpuidle.c
> > @@ -31,7 +31,7 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> > return -EOPNOTSUPP;
> > count = pr->power.count - 1;
> > - if (count <= 0)
> > + if (count < 0)
> > return -ENODEV;
> > for (i = 0; i < count; i++) {
>
> This count already verified in acpi_processor_get_lpi_info.
>
> I suggest modifing it as below:
>
> -->
>
> git diff
> diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> index 801f9c450142..c68a5db8ebba 100644
> --- a/drivers/acpi/arm64/cpuidle.c
> +++ b/drivers/acpi/arm64/cpuidle.c
> @@ -16,7 +16,7 @@
>
> static int psci_acpi_cpu_init_idle(unsigned int cpu)
> {
> - int i, count;
> + int i;
> struct acpi_lpi_state *lpi;
> struct acpi_processor *pr = per_cpu(processors, cpu);
>
> @@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> if (!psci_ops.cpu_suspend)
> return -EOPNOTSUPP;
>
> - count = pr->power.count - 1;
> - if (count <= 0)
> - return -ENODEV;
> -
> - for (i = 0; i < count; i++) {
> + for (i = 1; i < pr->power.count; i++) {
> u32 state;
>
> - lpi = &pr->power.lpi_states[i + 1];
> + lpi = &pr->power.lpi_states[i];
> /*
> * Only bits[31:0] represent a PSCI power_state while
> * bits[63:32] must be 0x0 as per ARM ACPI FFH Specification
Ack, I will respin.
Thanks for your help,
--breno
^ permalink raw reply
* Re: [PATCH v3 1/8] sframe: Allow kernelspace sframe sections.
From: Jens Remus @ 2026-04-14 12:09 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel
In-Reply-To: <20260406185000.1378082-2-dylanbhatch@google.com>
Hello Dylan!
On 4/6/2026 8:49 PM, Dylan Hatch wrote:
> Generalize the sframe lookup code to support kernelspace sections. This
> is done by defining a SFRAME_LOOKUP option that can be activated
> separate from UNWIND_USER_SFRAME, as there will be other clients to this
> library than just userspace unwind.
Nit: s/UNWIND_USER_SFRAME/HAVE_UNWIND_USER_SFRAME/
This actually uses the following two new Kconfig options (with
SFRAME_UNWINDER technically being introduced in the next patch):
SFRAME_LOOKUP
SFRAME_UNWINDER
IIUC SFRAME_UNWINDER is the kernel counterpart to the existing
HAVE_UNWIND_USER_SFRAME. Would it therefore make sense to align the
naming as follows?
HAVE_UNWIND_KERNEL_SFRAME (instead of SFRAME_UNWINDER)
HAVE_UNWIND_USER_SFRAME
> Sframe section location is now tracked in a separate sec_type field to
> determine whether user-access functions are necessary to read the sframe
> data. Relevant type delarations are moved and renamed to reflect the
> non-user sframe support.
>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> diff --git a/arch/Kconfig b/arch/Kconfig
> @@ -486,6 +486,9 @@ config AS_SFRAME3
> def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
> select AS_SFRAME
>
> +config SFRAME_LOOKUP
> + bool
> +
> config UNWIND_USER
> bool
>
> @@ -496,6 +499,7 @@ config HAVE_UNWIND_USER_FP
> config HAVE_UNWIND_USER_SFRAME
> bool
> select UNWIND_USER
> + select SFRAME_LOOKUP
>
> config SFRAME_VALIDATION
> bool "Enable .sframe section debugging"
IIUC SFRAME_LOOKUP only exists to pull in the common (kernel and user)
sframe lookup code if SFRAME_UNWINDER and/or UNWIND_USER_SFRAME are
enabled. Given there is currently no other use case than kernel/user
stacktrace unwinding, would it make sense to rename it as follows to
group all of the related options with the UNWIND prefix?
UNWIND_SFRAME[_LOOKUP]
> diff --git a/include/linux/sframe.h b/include/linux/sframe.h
> @@ -4,36 +4,85 @@
>
> #include <linux/mm_types.h>
> #include <linux/srcu.h>
> -#include <linux/unwind_user_types.h>
>
> -#ifdef CONFIG_HAVE_UNWIND_USER_SFRAME
> +#define UNWIND_RULE_DEREF BIT(31)
> +
> +enum unwind_cfa_rule {
> + UNWIND_CFA_RULE_SP_OFFSET, /* CFA = SP + offset */
> + UNWIND_CFA_RULE_FP_OFFSET, /* CFA = FP + offset */
> + UNWIND_CFA_RULE_REG_OFFSET, /* CFA = reg + offset */
> + /* DEREF variants */
> + UNWIND_CFA_RULE_REG_OFFSET_DEREF = /* CFA = *(reg + offset) */
> + UNWIND_CFA_RULE_REG_OFFSET | UNWIND_RULE_DEREF,
> +};
> +
> +struct unwind_cfa_rule_data {
> + enum unwind_cfa_rule rule;
> + s32 offset;
> + unsigned int regnum;
> +};
> +
> +enum unwind_rule {
> + UNWIND_RULE_RETAIN, /* entity = entity */
> + UNWIND_RULE_CFA_OFFSET, /* entity = CFA + offset */
> + UNWIND_RULE_REG_OFFSET, /* entity = register + offset */
> + /* DEREF variants */
> + UNWIND_RULE_CFA_OFFSET_DEREF = /* entity = *(CFA + offset) */
> + UNWIND_RULE_CFA_OFFSET | UNWIND_RULE_DEREF,
> + UNWIND_RULE_REG_OFFSET_DEREF = /* entity = *(register + offset) */
> + UNWIND_RULE_REG_OFFSET | UNWIND_RULE_DEREF,
> +};
> +
> +struct unwind_rule_data {
> + enum unwind_rule rule;
> + s32 offset;
> + unsigned int regnum;
> +};
> +
> +struct unwind_frame {
> + struct unwind_cfa_rule_data cfa;
> + struct unwind_rule_data ra;
> + struct unwind_rule_data fp;
> + bool outermost;
> +};
You are moving (and renaming to generalize for kernel and user unwind
use) the above definitions from include/linux/unwind_user_types.h to
include/linux/sframe.h. Given the definitions are used in
kernel/unwind/user.c for FP and SFRAME unwinding this seems wrong to
me. The definitions should better be moved (and renamed as you did)
into a new include/linux/unwind_types.h (or the like).
> diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h
> @@ -27,47 +27,6 @@ struct unwind_stacktrace {
> unsigned long *entries;
> };
>
> -#define UNWIND_USER_RULE_DEREF BIT(31)
> -
> -enum unwind_user_cfa_rule {
> - UNWIND_USER_CFA_RULE_SP_OFFSET, /* CFA = SP + offset */
> - UNWIND_USER_CFA_RULE_FP_OFFSET, /* CFA = FP + offset */
> - UNWIND_USER_CFA_RULE_REG_OFFSET, /* CFA = reg + offset */
> - /* DEREF variants */
> - UNWIND_USER_CFA_RULE_REG_OFFSET_DEREF = /* CFA = *(reg + offset) */
> - UNWIND_USER_CFA_RULE_REG_OFFSET | UNWIND_USER_RULE_DEREF,
> -};
> -
> -struct unwind_user_cfa_rule_data {
> - enum unwind_user_cfa_rule rule;
> - s32 offset;
> - unsigned int regnum;
> -};
> -
> -enum unwind_user_rule {
> - UNWIND_USER_RULE_RETAIN, /* entity = entity */
> - UNWIND_USER_RULE_CFA_OFFSET, /* entity = CFA + offset */
> - UNWIND_USER_RULE_REG_OFFSET, /* entity = register + offset */
> - /* DEREF variants */
> - UNWIND_USER_RULE_CFA_OFFSET_DEREF = /* entity = *(CFA + offset) */
> - UNWIND_USER_RULE_CFA_OFFSET | UNWIND_USER_RULE_DEREF,
> - UNWIND_USER_RULE_REG_OFFSET_DEREF = /* entity = *(register + offset) */
> - UNWIND_USER_RULE_REG_OFFSET | UNWIND_USER_RULE_DEREF,
> -};
> -
> -struct unwind_user_rule_data {
> - enum unwind_user_rule rule;
> - s32 offset;
> - unsigned int regnum;
> -};
> -
> -struct unwind_user_frame {
> - struct unwind_user_cfa_rule_data cfa;
> - struct unwind_user_rule_data ra;
> - struct unwind_user_rule_data fp;
> - bool outermost;
> -};
> -
> struct unwind_user_state {
> unsigned long ip;
> unsigned long sp;
> diff --git a/kernel/unwind/Makefile b/kernel/unwind/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_UNWIND_USER) += user.o deferred.o
> - obj-$(CONFIG_HAVE_UNWIND_USER_SFRAME) += sframe.o
> + obj-$(CONFIG_SFRAME_LOOKUP) += sframe.o
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> @@ -44,8 +43,6 @@ struct sframe_fre_internal {
> unsigned char dw_size;
> };
>
> -DEFINE_STATIC_SRCU(sframe_srcu);
> -
> static __always_inline unsigned char fre_type_to_size(unsigned char fre_type)
> {
> if (fre_type > 2)
> @@ -60,6 +57,78 @@ static __always_inline unsigned char dataword_size_enum_to_size(unsigned char da
> return 1 << dataword_size;
> }
>
> +#ifdef CONFIG_HAVE_UNWIND_USER_SFRAME
> +
> +DEFINE_STATIC_SRCU(sframe_srcu);
> +
> +#define UNSAFE_USER_COPY(to, from, size, label) \
> + unsafe_copy_from_user(to, (void __user *)from, size, label)
> +
> +#define UNSAFE_USER_GET(to, from, type, label) \
> + unsafe_get_user(to, (type __user *)from, label)
> +
> +#else /* !CONFIG_HAVE_UNWIND_USER_SFRAME */
> +
> +#define UNSAFE_USER_COPY(to, from, size, label) do { \
> + (void)to; (void)from; (void)size; \
> + goto label; \
> +} while (0)
> +
> +#define UNSAFE_USER_GET(to, from, type, label) do { \
> + (void)to; (void)from; \
> + goto label; \
> +} while (0)
> +
> +#endif /* !CONFIG_HAVE_UNWIND_USER_SFRAME */
> +
> +#ifdef CONFIG_SFRAME_UNWINDER
> +
> +#define KERNEL_COPY(to, from, size) memcpy(to, (void *)from, size)
> +#define KERNEL_GET(to, from, type) ({ (to) = *(type *)(from); })
> +
> +#else /* !CONFIG_SFRAME_UNWINDER */
> +
> +#define KERNEL_COPY(to, from, size) do { \
> + (void)(to); (void)(from); (void)size; \
> + return -EFAULT; \
> +} while (0)
> +
> +#define KERNEL_GET(to, from, type) do { \
> + (void)(to); (void)(from); \
> + return -EFAULT; \
> +} while (0)
The error return value in above dummy implementations is never used
(see DATA_COPY() and DATA_GET() below). Maybe better define the KERNEL
flavors with the same interface as the UNSAFE_USER ones (with error
label) and have the dummy implementations goto that label?
> +
> +
Nit: Two instead of one empty line.
> +#endif /* !CONFIG_SFRAME_UNWINDER */
> +
> +#define DATA_COPY(sec, to, from, size, label) \
> +({ \
> + switch (sec->sec_type) { \
> + case SFRAME_KERNEL: \
> + KERNEL_COPY(to, from, size); \
> + break; \
> + case SFRAME_USER: \
> + UNSAFE_USER_COPY(to, from, size, label); \
> + break; \
> + default: \
> + return -EFAULT; \
> + } \
> +})
> +
> +#define DATA_GET(sec, to, from, type, label) \
> +({ \
> + switch (sec->sec_type) { \
> + case SFRAME_KERNEL: \
> + KERNEL_GET(to, from, type); \
> + break; \
> + case SFRAME_USER: \
> + UNSAFE_USER_GET(to, from, type, label); \
> + break; \
> + default: \
> + return -EFAULT; \
> + } \
> +})
> +
> static __always_inline int __read_fde(struct sframe_section *sec,
> unsigned int fde_num,
> struct sframe_fde_internal *fde)
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH RFC] ACPI: processor: idle: Do not propagate acpi_processor_ffh_lpi_probe() -ENODEV
From: Sudeep Holla @ 2026-04-14 12:25 UTC (permalink / raw)
To: lihuisong (C)
Cc: Breno Leitao, Sudeep Holla, Rafael J. Wysocki, Len Brown,
lpieralisi, catalin.marinas, will, Rafael J. Wysocki, linux-acpi,
linux-kernel, pjaroszynski, guohanjun, linux-arm-kernel, rmikey,
kernel-team
In-Reply-To: <6694ca7c-13bf-4e7d-9621-bc992cbf96a7@huawei.com>
On Tue, Apr 14, 2026 at 07:31:29PM +0800, lihuisong (C) wrote:
>
> On 4/14/2026 6:21 PM, Breno Leitao wrote:
> > Hello Huisong,
> >
> > On Tue, Apr 14, 2026 at 05:43:51PM +0800, lihuisong (C) wrote:
> > > But it is a real issue. Thanks for your report.
> > > I think the best way to fix your issue is that remove this verification in
> > > psci_acpi_cpu_init_idle().
> > > Because it is legal for platform to report one LPI state.
> > > This function just needs to verify the LPI states which are FFH.
> > Thank you for the prompt feedback.
> >
> > Would this approach work?
> >
> > commit 6c9d52840a4f778cc989838ba76ee51416e85de3
> > Author: Breno Leitao <leitao@debian.org>
> > Date: Tue Apr 14 03:16:08 2026 -0700
> >
> > ACPI: processor: idle: Allow platforms with only one LPI state
> > psci_acpi_cpu_init_idle() rejects platforms where power.count - 1 <= 0
> > by returning -ENODEV. However, having a single LPI state (WFI) is a
> > valid configuration. The function's purpose is to verify FFH idle states,
> > and when count is zero, there are simply no FFH states to validate —
> > this is not an error.
> > On NVIDIA Grace (aarch64) systems with PSCIv1.1, power.count is 1 for
> > all 72 CPUs, so the probe fails with -ENODEV. After commit cac173bea57d
> > ("ACPI: processor: idle: Rework the handling of
> > acpi_processor_ffh_lpi_probe()"), this failure propagates up and prevents
> > cpuidle registration entirely.
> > Change the check from (count <= 0) to (count < 0) so that platforms
> > with only WFI are accepted. The for loop naturally handles count == 0
> > by not iterating.
> > Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> >
> > diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> > index 801f9c4501425..7791b751042ce 100644
> > --- a/drivers/acpi/arm64/cpuidle.c
> > +++ b/drivers/acpi/arm64/cpuidle.c
> > @@ -31,7 +31,7 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> > return -EOPNOTSUPP;
> > count = pr->power.count - 1;
> > - if (count <= 0)
> > + if (count < 0)
> > return -ENODEV;
> > for (i = 0; i < count; i++) {
>
> This count already verified in acpi_processor_get_lpi_info.
>
> I suggest modifing it as below:
>
> -->
>
> git diff
> diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
> index 801f9c450142..c68a5db8ebba 100644
> --- a/drivers/acpi/arm64/cpuidle.c
> +++ b/drivers/acpi/arm64/cpuidle.c
> @@ -16,7 +16,7 @@
>
> static int psci_acpi_cpu_init_idle(unsigned int cpu)
> {
> - int i, count;
> + int i;
> struct acpi_lpi_state *lpi;
> struct acpi_processor *pr = per_cpu(processors, cpu);
>
> @@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
> if (!psci_ops.cpu_suspend)
> return -EOPNOTSUPP;
>
> - count = pr->power.count - 1;
> - if (count <= 0)
> - return -ENODEV;
> -
It was intentionally designed this way, as there is little value in defining
only WFI in the _LPI tables. In the absence of a cpuidle driver/LPI entry,
arch_cpu_idle() is invoked, which is sufficient and avoids unnecessary
complexity, only to ultimately execute wfi() anyway.
So while I understand that the kernel did not report an error previously, that
does not mean the _LPI table is merely moot on this platform when it contains
only a WFI state.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Jason Gunthorpe @ 2026-04-14 12:29 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Sami Mujawar, Dan Williams, linux-arm-kernel, linux-kernel,
catalin.marinas, will, thuth, steven.price, gshan, YeoReum.Yun,
cedric.xing, Dan Williams, Dionna Glaze, Aneesh Kumar K . V,
Alexey Kardashevskiy, linux-coco@lists.linux.dev
In-Reply-To: <514ddb27-137b-4223-84fe-2152737db3a6@arm.com>
On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> > Isn't this also sort of incomplete? Doesn't anything serious need
> > signed measurements? Isnt't there alot more data that comes out of RMM
> > than just a few measurement registers?
> As mentioned above, this series adds the support for Runtime Extendible
> Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is
> already provided via the TSM_REPORT
Okay, but what actual use is this?
Extendable measrements with no log
Measurement read back without signature
What is the use case? What do you imagine any userspace will do with
this? Put it in the cover letter.
I don't think the raw rmm calls are sufficiently developed to be
usable directly by userspace. They are less capable than TPM and even
TPM has a lot of software around it to make it useful.
Jason
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-14 12:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260413-impose-cartel-bd7d18f91a24@spud>
On 4/13/26 5:42 PM, Conor Dooley wrote:
> On Mon, Apr 13, 2026 at 12:52:42PM +0200, Ronald Claveau wrote:
>> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>>
>> Unlike existing variants which use a phandle to the ao-secure syscon,
>> the T7 relies on a secure monitor interface described by a phandle and
>> a sensor index argument.
>>
>> The T7 integrates multiple thermal sensors, all accessed through the
>> same SMC call. The sensor index argument is required to identify which
>> sensor's calibration data the secure monitor should return, as a single
>> SM_THERMAL_CALIB_READ command serves all of them.
>>
>> Introduce the amlogic,secure-monitor property as a phandle-array and
>> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
>> depending on the compatible.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> .../bindings/thermal/amlogic,thermal.yaml | 42 ++++++++++++++++++++--
>> 1 file changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> index 70b273271754b..1c096116b2dda 100644
>> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> @@ -21,7 +21,9 @@ properties:
>> - amlogic,g12a-cpu-thermal
>> - amlogic,g12a-ddr-thermal
>> - const: amlogic,g12a-thermal
>> - - const: amlogic,a1-cpu-thermal
>> + - enum:
>> + - amlogic,a1-cpu-thermal
>> + - amlogic,t7-thermal
>>
>> reg:
>> maxItems: 1
>> @@ -42,12 +44,39 @@ properties:
>> '#thermal-sensor-cells':
>> const: 0
>>
>> + amlogic,secure-monitor:
>> + description: phandle to the secure monitor
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to the secure monitor
>> + - description: sensor index to get specific calibration data
>> +
>> required:
>> - compatible
>> - reg
>> - interrupts
>> - clocks
>> - - amlogic,ao-secure
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a1-cpu-thermal
>> + - amlogic,g12a-thermal
>> + then:
>> + required:
>> + - amlogic,ao-secure
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: amlogic,t7-thermal
>
> This can just be replaced by a else I think.
>
Thank you for your feedback, I will replace this `if` condition by an
`else`.
>> + then:
>> + required:
>> + - amlogic,secure-monitor
>>
>> unevaluatedProperties: false
>>
>> @@ -62,4 +91,13 @@ examples:
>> #thermal-sensor-cells = <0>;
>> amlogic,ao-secure = <&sec_AO>;
>> };
>> + - |
>> + a73_tsensor: temperature-sensor@20000 {
>
> Can drop the label here, it has no users.
>
Ok, I will remove this label.
> Otherwise, seems fine.
>
> Cheers,
> Conor.
>
> pw-bot: changes-requested
>
>> + compatible = "amlogic,t7-thermal";
>> + reg = <0x0 0x20000 0x0 0x50>;
>> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clkc_periphs CLKID_TS>;
>> + #thermal-sensor-cells = <0>;
>> + amlogic,secure-monitor = <&sm 1>;
>> + };
>> ...
>>
>> --
>> 2.49.0
>>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Simon Horman @ 2026-04-14 12:40 UTC (permalink / raw)
To: lorenzo
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-fix-max-mtu-v1-1-333030d0a564@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: airoha: Fix max TX packet length configuration
This commit fixes the MTU configuration for the Airoha driver by removing
ETH_FCS_LEN from the maximum TX packet length, matching the hardware
documentation which states the register does not include the FCS length.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index c14cdce588a7c..a81ffda72b39f 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
>
> static int airoha_dev_open(struct net_device *dev)
> {
> - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = netdev_priv(dev);
> struct airoha_qdma *qdma = port->qdma;
> + int err, len = ETH_HLEN + dev->mtu;
Does this regression cause MTU-sized VLAN-tagged frames to be dropped by the
hardware?
By limiting the frame size to ETH_HLEN + dev->mtu, the maximum allowed length
becomes 1514 bytes for a standard 1500 MTU. An Ethernet frame containing a
standard 802.1Q VLAN tag and a maximum-sized 1500-byte IP payload requires an
18-byte L2 header, making the total frame size 1518 bytes (excluding FCS).
Previously, the inclusion of ETH_FCS_LEN inadvertently provided the 4-byte
headroom needed to accommodate a single VLAN tag.
Could the configuration explicitly account for VLAN headers using VLAN_ETH_HLEN
instead?
[ ... ]
^ permalink raw reply
* Re: [patch 31/38] parisc: Select ARCH_HAS_RANDOM_ENTROPY
From: Helge Deller @ 2026-04-14 12:41 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: linux-parisc, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.658485572@kernel.org>
On 4/10/26 14:21, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch parisc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-parisc@vger.kernel.org
> ---
> arch/parisc/Kconfig | 1 +
> arch/parisc/include/asm/random.h | 12 ++++++++++++
> arch/parisc/include/asm/timex.h | 6 ------
> arch/parisc/kernel/processor.c | 1 +
> arch/parisc/kernel/time.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
I tested this series on parisc.
Works as expected.
Tested-by: Helge Deller <deller@gmx.de>
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info
From: Jens Remus @ 2026-04-14 12:43 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Heiko Carstens, Vasily Gorbik, Ilya Leoshkevich
In-Reply-To: <20260406185000.1378082-3-dylanbhatch@google.com>
On 4/6/2026 8:49 PM, Dylan Hatch wrote:
> Build with -Wa,--gsframe-3 flags to generate a .sframe section. This
> will be used for in-kernel reliable stacktrace in cases where the frame
> pointer alone is insufficient.
>
> Currently, the sframe format only supports arm64, x86_64 and s390x
> architectures.
>
> Signed-off-by: Weinan Liu <wnliu@google.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
> diff --git a/MAINTAINERS b/MAINTAINERS
> @@ -27561,6 +27561,7 @@ STACK UNWINDING
> M: Josh Poimboeuf <jpoimboe@kernel.org>
> M: Steven Rostedt <rostedt@goodmis.org>
> S: Maintained
> +F: arch/*/include/asm/unwind_sframe.h
> F: include/linux/sframe.h
> F: include/linux/unwind*.h
> F: kernel/unwind/
Good catch! Should we rather add the following in the series you are
basing on, as there are already arch-specific unwind_user.h and
unwind_user_sframe.h?
F: arch/*/include/asm/unwind*.h
On the other hand I wonder whether the arch-specific headers should
remain maintained by the respective arch maintainers? How is that
handled in general?
> diff --git a/arch/Kconfig b/arch/Kconfig
> @@ -520,6 +520,13 @@ config SFRAME_VALIDATION
>
> If unsure, say N.
>
> +config ARCH_SUPPORTS_SFRAME_UNWINDER
> + bool
> + help
> + An architecture can select this if it enables the sframe (Simple
> + Frame) unwinder for unwinding kernel stack traces. It uses unwind
> + table that is directly generatedby toolchain based on DWARF CFI information.
Nit: s/sframe/SFrame/
> +
> config HAVE_PERF_REGS
> bool
> help
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> @@ -112,6 +112,7 @@ config ARM64
> select ARCH_SUPPORTS_SCHED_SMT
> select ARCH_SUPPORTS_SCHED_CLUSTER
> select ARCH_SUPPORTS_SCHED_MC
> + select ARCH_SUPPORTS_SFRAME_UNWINDER
> select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
> select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
> select ARCH_WANT_DEFAULT_BPF_JIT
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> @@ -20,4 +20,17 @@ config ARM64_RELOC_TEST
> depends on m
> tristate "Relocation testing module"
>
> +config SFRAME_UNWINDER
Why do you introduce this for arm64 (and debug) only? If s390 were to
add support (as replacement for s390 backchain), this would have to be
moved or duplicated. It would not suffice to enable
ARCH_SUPPORTS_SFRAME_UNWINDER to also enable SFRAME_UNWINDER.
As mentioned in my feedback on the previous patch in this series:
Would it make sense to align the naming to the existing
HAVE_UNWIND_USER_SFRAME, for instance:
HAVE_UNWIND_KERNEL_SFRAME
> + bool "Sframe unwinder"
> + depends on AS_SFRAME3
> + depends on 64BIT
> + depends on ARCH_SUPPORTS_SFRAME_UNWINDER
> + select SFRAME_LOOKUP
> + help
> + This option enables the sframe (Simple Frame) unwinder for unwinding
> + kernel stack traces. It uses unwind table that is directly generated
> + by toolchain based on DWARF CFI information. In, practice this can
> + provide more reliable stacktrace results than unwinding with frame
> + pointers alone.
Nit: s/sframe/SFrame/
> +
> source "drivers/hwtracing/coresight/Kconfig"
You are introducing two new Kconfig options (SFRAME_UNWINDER and
ARCH_SUPPORTS_SFRAME_UNWINDER). I wonder whether they could somehow be
combined into a single new option. Although I am not sure how an option
can be both selectable and depending at the same time, so that the ARM64
config could select it, but it would also depend on the above.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> @@ -491,6 +491,8 @@
> *(.rodata1) \
> } \
> \
> + SFRAME \
> + \
> /* PCI quirks */ \
> .pci_fixup : AT(ADDR(.pci_fixup) - LOAD_OFFSET) { \
> BOUNDED_SECTION_PRE_LABEL(.pci_fixup_early, _pci_fixups_early, __start, __end) \
> @@ -911,6 +913,19 @@
> #define TRACEDATA
> #endif
>
> +#ifdef CONFIG_SFRAME_UNWINDER
> +#define SFRAME \
> + /* sframe */ \
> + .sframe : AT(ADDR(.sframe) - LOAD_OFFSET) { \
> + __start_sframe_header = .; \
__start_sframe[_section] = .;
> + KEEP(*(.sframe)) \
> + KEEP(*(.init.sframe)) \
> + __stop_sframe_header = .; \
__stop_sframe[_section] = .;
Unless I am missing something both are not the start/stop of the .sframe
header (in the .sframe section) but the .sframe section itself (see also
your subsequent "[PATCH v3 4/8] sframe: Provide PC lookup for vmlinux
.sframe section." where you assign both to kernel_sfsec.sframe_start
and kernel_sfsec.sframe_end.
> + }
> +#else
> +#define SFRAME
> +#endif
> +
> #ifdef CONFIG_PRINTK_INDEX
> #define PRINTK_INDEX \
> .printk_index : AT(ADDR(.printk_index) - LOAD_OFFSET) { \
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH net] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: Simon Horman @ 2026-04-14 12:46 UTC (permalink / raw)
To: lorenzo
Cc: 'Simon Horman', andrew+netdev, davem, edumazet, kuba,
pabeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-wait-for-npu-config-offload-setup-v1-1-f4e0aa2a5d85@kernel.org>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
This commit adds a poll loop in airoha_ppe_offload_setup() to wait for the NPU
PPE configuration to complete before running airoha_ppe_hw_init().
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index c2c32b6833df9..52199f6b39f9b 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
[ ... ]
> @@ -1340,6 +1341,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> if (err)
> goto error_npu_put;
>
> + /* Wait for NPU PPE configuration to complete */
> + err = read_poll_timeout(airoha_fe_rr, val, val, USEC_PER_MSEC,
> + 100 * USEC_PER_MSEC, false, eth,
> + REG_PPE_PPE_FLOW_CFG(0));
If the SoC has multiple PPE instances, is it sufficient to only wait for
REG_PPE_PPE_FLOW_CFG(0)?
Later in airoha_ppe_hw_init(), the code iterates up to eth->soc->num_ppe,
initializing all available instances:
drivers/net/ethernet/airoha/airoha_ppe.c:airoha_ppe_hw_init() {
...
for (i = 0; i < eth->soc->num_ppe; i++) {
...
airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
ppe->foe_dma + sram_tb_size);
...
}
If we only poll PPE 0, could the driver race with the NPU firmware's
initialization of subsequent PPEs?
Additionally, does this poll condition properly ensure the hardware is ready?
Since the break condition is simply `val`, it exits immediately if the register
contains any non-zero value.
If the register retains a non-zero value from a previous session (like across
driver reloads), or if an unclocked domain returns 0xFFFFFFFF, this poll might
succeed immediately and bypass the wait.
Could we clear the register before polling, or wait for a specific bit instead?
> + if (err)
> + goto error_npu_put;
> +
> ppe_num_stats_entries = airoha_ppe_get_total_num_stats_entries(ppe);
^ permalink raw reply
* [PATCH v4 0/6] perf arm_spe: Dump IMPDEF events
From: James Clark @ 2026-04-14 12:47 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Leo Yan, Al Grant
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>
---
Changes in v4:
- Change a pr_err() to pr_warning_once() to avoid spam (Sashiko)
- Link to v3: https://lore.kernel.org/r/20260414-james-spe-impdef-decode-v3-0-63baf9c893b1@linaro.org
Changes in v3:
- Revert for_each_set_bit() back to a loop with BIT_ULL to fix both 32
bit builds and decoding on big endian machines.
- Link to v2: https://lore.kernel.org/r/20260407-james-spe-impdef-decode-v2-0-55d3ef997c48@linaro.org
Changes in v2:
- Put MIDR in arm_spe_pkt (Leo)
- Use for_each_set_bit() (Leo)
- Use BIT_ULL() to fix 32bit builds (Ian)
- Don't call strtol() with NULL (Ian)
- Link to v1: https://lore.kernel.org/r/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c@linaro.org
---
James Clark (6):
perf arm_spe: Make a function to get the MIDR
perf arm_spe: Handle missing CPU IDs
perf arm_spe: Store MIDR in arm_spe_pkt
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 +
tools/perf/util/arm-spe-decoder/arm-spe-decoder.c | 17 ++-
tools/perf/util/arm-spe-decoder/arm-spe-decoder.h | 3 +-
.../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 144 ++++++++++++++-------
.../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 +-
tools/perf/util/arm-spe.c | 62 ++++++---
6 files changed, 158 insertions(+), 75 deletions(-)
---
base-commit: 4e03d6494f9504f8af46ba68a2a8b6877c196789
change-id: 20260331-james-spe-impdef-decode-d944f4fdcff7
Best regards,
--
James Clark <james.clark@linaro.org>
^ permalink raw reply
* [PATCH v4 1/6] perf arm_spe: Make a function to get the MIDR
From: James Clark @ 2026-04-14 12:47 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@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.
Reviewed-by: Leo Yan <leo.yan@arm.com>
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 e5835042acdf7685f95e19665cd45f97ed868275..39046033e1433cff82ef0668074867aba4a462a4 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -972,14 +972,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) {
@@ -987,15 +982,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 v4 2/6] perf arm_spe: Handle missing CPU IDs
From: James Clark @ 2026-04-14 12:48 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@linaro.org>
Don't call strtol() with a null pointer to avoid undefined behavior.
I'm not sure of the exact scenario for missing CPU IDs but I don't think
it happens in practice. SPE decoding can continue without them with
reduced functionality, but print an error message anyway.
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 39046033e1433cff82ef0668074867aba4a462a4..037c7aa150c1efeda6e8e956a5b1db733e6ea74a 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -982,16 +982,23 @@ static int arm_spe__get_midr(struct arm_spe *spe, int cpu, u64 *midr)
pr_warning_once("Old SPE metadata, re-record to improve decode accuracy\n");
cpuid = perf_env__cpuid(perf_session__env(spe->session));
+ if (!cpuid)
+ goto err;
+
*midr = strtol(cpuid, NULL, 16);
return 0;
}
metadata = arm_spe__get_metadata_by_cpu(spe, cpu);
if (!metadata)
- return -EINVAL;
+ goto err;
*midr = metadata[ARM_SPE_CPU_MIDR];
return 0;
+
+err:
+ pr_warning_once("Failed to get MIDR for CPU %d\n", cpu);
+ return -EINVAL;
}
static void arm_spe__synth_ds(struct arm_spe_queue *speq,
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/6] perf arm_spe: Store MIDR in arm_spe_pkt
From: James Clark @ 2026-04-14 12:48 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@linaro.org>
The MIDR will affect printing of arm_spe_pkts, so store a copy of it
there. Technically it's constant for each decoder, but there is no
decoder when doing a raw dump, so it has to be stored in every packet.
It will only be used in raw dump mode and not in normal decoding for
now, but to avoid any surprises, set MIDR properly on the decoder too.
Having both the MIDR and the arm_spe_pkt (which has a copy of it) in the
decoder seemed a bit weird, so remove arm_spe_pkt from the decoder. The
packet is only short lived anyway so probably shouldn't have been there
in the first place.
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
tools/perf/util/arm-spe-decoder/arm-spe-decoder.c | 17 ++++++++++-------
tools/perf/util/arm-spe-decoder/arm-spe-decoder.h | 3 +--
.../perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 3 ++-
.../perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h | 3 ++-
tools/perf/util/arm-spe.c | 21 +++++++++++++++------
5 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
index 9e02b2bdd1177193996d071dd88f969e25b1ad86..7a3a4815fd37b7f57687189c09c618aaf7ac9801 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
@@ -120,7 +120,8 @@ static int arm_spe_get_data(struct arm_spe_decoder *decoder)
return decoder->len;
}
-static int arm_spe_get_next_packet(struct arm_spe_decoder *decoder)
+static int arm_spe_get_next_packet(struct arm_spe_decoder *decoder,
+ struct arm_spe_pkt *packet)
{
int ret;
@@ -134,7 +135,8 @@ static int arm_spe_get_next_packet(struct arm_spe_decoder *decoder)
}
ret = arm_spe_get_packet(decoder->buf, decoder->len,
- &decoder->packet);
+ packet, decoder->midr);
+
if (ret <= 0) {
/* Move forward for 1 byte */
decoder->buf += 1;
@@ -144,7 +146,7 @@ static int arm_spe_get_next_packet(struct arm_spe_decoder *decoder)
decoder->buf += ret;
decoder->len -= ret;
- } while (decoder->packet.type == ARM_SPE_PAD);
+ } while (packet->type == ARM_SPE_PAD);
return 1;
}
@@ -154,19 +156,20 @@ static int arm_spe_read_record(struct arm_spe_decoder *decoder)
int err;
int idx;
u64 payload, ip;
+ struct arm_spe_pkt packet;
memset(&decoder->record, 0x0, sizeof(decoder->record));
decoder->record.context_id = (u64)-1;
while (1) {
- err = arm_spe_get_next_packet(decoder);
+ err = arm_spe_get_next_packet(decoder, &packet);
if (err <= 0)
return err;
- idx = decoder->packet.index;
- payload = decoder->packet.payload;
+ idx = packet.index;
+ payload = packet.payload;
- switch (decoder->packet.type) {
+ switch (packet.type) {
case ARM_SPE_TIMESTAMP:
decoder->record.timestamp = payload;
return 1;
diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
index 3310e05122f02e8ef32f79f8ed3c6932cc43eecc..0cbcb501edc9965d34cfd3ede79cab3fd9b318f8 100644
--- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
+++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
@@ -147,8 +147,7 @@ struct arm_spe_decoder {
const unsigned char *buf;
size_t len;
-
- struct arm_spe_pkt packet;
+ u64 midr;
};
struct arm_spe_decoder *arm_spe_decoder_new(struct arm_spe_params *params);
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 5769ba2f414049161f271fd8b8f40c440d15a75a..718022aecec30bf30a51ba3d2bca9cf6465259a7 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
@@ -222,11 +222,12 @@ static int arm_spe_do_get_packet(const unsigned char *buf, size_t len,
}
int arm_spe_get_packet(const unsigned char *buf, size_t len,
- struct arm_spe_pkt *packet)
+ struct arm_spe_pkt *packet, u64 midr)
{
int ret;
ret = arm_spe_do_get_packet(buf, len, packet);
+ packet->midr = midr;
/* put multiple consecutive PADs on the same line, up to
* the fixed-width output format of 16 bytes per line.
*/
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 adf4cde320aad01265b5232b0d6ff6b1f752f35f..a457821f3bccb67691cfd530de2f1c5bf9d8d50c 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
@@ -35,6 +35,7 @@ struct arm_spe_pkt {
enum arm_spe_pkt_type type;
unsigned char index;
uint64_t payload;
+ uint64_t midr;
};
/* Short header (HEADER0) and extended header (HEADER1) */
@@ -184,7 +185,7 @@ enum arm_spe_events {
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);
+ struct arm_spe_pkt *packet, u64 midr);
int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
#endif
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 037c7aa150c1efeda6e8e956a5b1db733e6ea74a..2b31da231ef3ec84a37b5a314ab1fc1151dca907 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -134,8 +134,10 @@ struct data_source_handle {
.ds_synth = arm_spe__synth_##func, \
}
+static int arm_spe__get_midr(struct arm_spe *spe, int cpu, u64 *midr);
+
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;
@@ -148,7 +150,8 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
len);
while (len) {
- ret = arm_spe_get_packet(buf, len, &packet);
+ ret = arm_spe_get_packet(buf, len, &packet, midr);
+
if (ret > 0)
pkt_len = ret;
else
@@ -174,10 +177,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)
@@ -302,8 +305,10 @@ static void arm_spe_set_pid_tid_cpu(struct arm_spe *spe,
if (speq->thread) {
speq->pid = thread__pid(speq->thread);
- if (queue->cpu == -1)
+ if (queue->cpu == -1) {
speq->cpu = thread__cpu(speq->thread);
+ arm_spe__get_midr(spe, speq->cpu, &speq->decoder->midr);
+ }
}
}
@@ -1248,6 +1253,7 @@ static int arm_spe__setup_queue(struct arm_spe *spe,
if (queue->cpu != -1)
speq->cpu = queue->cpu;
+ arm_spe__get_midr(spe, queue->cpu, &speq->decoder->midr);
if (!speq->on_heap) {
int ret;
@@ -1490,8 +1496,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 v4 4/6] perf arm_spe: Turn event name mappings into an array
From: James Clark @ 2026-04-14 12:48 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@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.
Reviewed-by: Leo Yan <leo.yan@arm.com>
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 718022aecec30bf30a51ba3d2bca9cf6465259a7..67ca356100e53aaf6d47489717537ba27aa2b98e 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
@@ -277,6 +277,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_ULL(ev->event))
+ arm_spe_pkt_out_string(err, buf, buf_len, " %s", ev->desc);
+ payload &= ~BIT_ULL(ev->event);
+ }
+ return payload;
+}
+
static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
char *buf, size_t buf_len)
{
@@ -284,51 +326,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 v4 5/6] perf arm_spe: Decode Arm N1 IMPDEF events
From: James Clark @ 2026-04-14 12:48 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Al Grant, Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@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>
Reviewed-by: Leo Yan <leo.yan@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 | 39 +++++++++++++++++++++-
.../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 2 +-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
index ab500e0efe2449fa2535d6efae2a30bc2690cb9e..97a298d1e2791bb9556cf893bd170ef938bfe631 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 67ca356100e53aaf6d47489717537ba27aa2b98e..b74f887a48f2a13b1be165947b4e3293f9987bd4 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",
@@ -308,6 +310,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)
{
@@ -319,6 +326,26 @@ 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)
{
@@ -326,7 +353,17 @@ 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");
- 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(packet->midr,
+ event_print_handles[i].midr_ranges))
+ payload = print_event_list(&err, &buf, &buf_len,
+ event_print_handles[i].ev_strings,
+ payload);
+ }
return err;
}
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 a457821f3bccb67691cfd530de2f1c5bf9d8d50c..a3300bec4990a76608d23e34368d6146c9f4a5b5 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
--
2.34.1
^ permalink raw reply related
* [PATCH v4 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: James Clark @ 2026-04-14 12:48 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
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, James Clark,
Al Grant, Leo Yan
In-Reply-To: <20260414-james-spe-impdef-decode-v4-0-1dd30783a33b@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>
Reviewed-by: Leo Yan <leo.yan@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 b74f887a48f2a13b1be165947b4e3293f9987bd4..600677318f84c06970e4e618280c39cc83ac5b1e 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
@@ -8,6 +8,7 @@
#include <string.h>
#include <endian.h>
#include <byteswap.h>
+#include <linux/bitmap.h>
#include <linux/bitops.h>
#include <stdarg.h>
#include <linux/kernel.h>
@@ -365,6 +366,23 @@ 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:");
+ for (int i = 0; i < 64; i++) {
+ const char *sep = payload & (payload - 1) ? "," : "";
+
+ if (payload & BIT_ULL(i)) {
+ arm_spe_pkt_out_string(&err, &buf, &buf_len, "%d%s", i,
+ sep);
+ payload &= ~BIT_ULL(i);
+ }
+ }
+ }
+
return err;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: Simon Horman @ 2026-04-14 12:48 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
On Sun, Apr 12, 2026 at 10:43:26AM +0200, Lorenzo Bianconi wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Lorenzo Bianconi @ 2026-04-14 13:04 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124011.751922-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Fix max TX packet length configuration
>
> This commit fixes the MTU configuration for the Airoha driver by removing
> ETH_FCS_LEN from the maximum TX packet length, matching the hardware
> documentation which states the register does not include the FCS length.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index c14cdce588a7c..a81ffda72b39f 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> >
> > static int airoha_dev_open(struct net_device *dev)
> > {
> > - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = netdev_priv(dev);
> > struct airoha_qdma *qdma = port->qdma;
> > + int err, len = ETH_HLEN + dev->mtu;
>
> Does this regression cause MTU-sized VLAN-tagged frames to be dropped by the
> hardware?
>
> By limiting the frame size to ETH_HLEN + dev->mtu, the maximum allowed length
> becomes 1514 bytes for a standard 1500 MTU. An Ethernet frame containing a
> standard 802.1Q VLAN tag and a maximum-sized 1500-byte IP payload requires an
> 18-byte L2 header, making the total frame size 1518 bytes (excluding FCS).
>
> Previously, the inclusion of ETH_FCS_LEN inadvertently provided the 4-byte
> headroom needed to accommodate a single VLAN tag.
>
> Could the configuration explicitly account for VLAN headers using VLAN_ETH_HLEN
> instead?
ack, thx for pointing this out. I will fix it in v2.
Regards,
Lorenzo
>
> [ ... ]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix max TX packet length configuration
From: Paolo Abeni @ 2026-04-14 13:04 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260412-airoha-fix-max-mtu-v1-1-333030d0a564@kernel.org>
On 4/12/26 10:09 AM, Lorenzo Bianconi wrote:
> According to the Airoha documentation, REG_GDM_LEN_CFG() register does not
> include FCS length. Fix MTU configuration removing ETH_FCS_LEN from
> maximum TX packet length configuration.
>
> Fixes: 54d989d58d2ac ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Fixes: 03b1b69f0662c ("net: airoha: Introduce airoha_dev_change_mtu callback")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index c14cdce588a7..a81ffda72b39 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1629,9 +1629,9 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port)
>
> static int airoha_dev_open(struct net_device *dev)
> {
> - int err, len = ETH_HLEN + dev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = netdev_priv(dev);
> struct airoha_qdma *qdma = port->qdma;
> + int err, len = ETH_HLEN + dev->mtu;
Sashiko noted that the above may cause regressions, dropping max MTU
vlan frames.
/P
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 13:12 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZfubV6LgRjO3NQvhrG2Q5o0ftkFFupLWVYS50XDnmCaog@mail.gmail.com>
Hi Andrey, thanks for the prompt review !
On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
[...]
>> +#ifdef CONFIG_KASAN_GENERIC
>> +void __asan_load1(void *p);
>> +void __asan_store1(void *p);
>> +void __asan_load2(void *p);
>> +void __asan_store2(void *p);
>> +void __asan_load4(void *p);
>> +void __asan_store4(void *p);
>> +void __asan_load8(void *p);
>> +void __asan_store8(void *p);
>> +void __asan_load16(void *p);
>> +void __asan_store16(void *p);
>> +#endif /* CONFIG_KASAN_GENERIC */
>
> This looks ugly, let's not do this unless it's really required.
>
> You can just use kasan_check_read/write() instead - these are public
> wrappers around the same shadow memory checking functions. And they
> also work with the SW_TAGS mode, in case the BPF would want to use
> that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
> that checks a single byte, but it can be extended in the future if
> required to be used by BPF.)
ACK, I'll try to use those kasan_check_read and kasan_check_write rather
than __asan_{load,store}X.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RFC] ACPI: processor: idle: Do not propagate acpi_processor_ffh_lpi_probe() -ENODEV
From: Breno Leitao @ 2026-04-14 13:14 UTC (permalink / raw)
To: Sudeep Holla
Cc: lihuisong (C), Rafael J. Wysocki, Len Brown, lpieralisi,
catalin.marinas, will, Rafael J. Wysocki, linux-acpi,
linux-kernel, pjaroszynski, guohanjun, linux-arm-kernel, rmikey,
kernel-team
In-Reply-To: <20260414-cute-shapeless-dolphin-c5b2fc@sudeepholla>
Hello Sudeep,
On Tue, Apr 14, 2026 at 01:25:53PM +0100, Sudeep Holla wrote:
> So while I understand that the kernel did not report an error previously, that
> does not mean the _LPI table is merely moot on this platform when it contains
> only a WFI state.
Can you clarify whether datacenter ARM systems are expected to expose
deeper idle states beyond WFI in their _LPI tables?
Backing up, I'm observing 72 pr_err() messages during boot on these
hosts and trying to determine whether this indicates a firmware issue or
if the kernel needs adjustment.
^ permalink raw reply
* Re: [PATCH net] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: Lorenzo Bianconi @ 2026-04-14 13:15 UTC (permalink / raw)
To: Simon Horman
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414124641.754059-1-horms@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
>
> This commit adds a poll loop in airoha_ppe_offload_setup() to wait for the NPU
> PPE configuration to complete before running airoha_ppe_hw_init().
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> > index c2c32b6833df9..52199f6b39f9b 100644
> > --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> > +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> [ ... ]
> > @@ -1340,6 +1341,13 @@ static int airoha_ppe_offload_setup(struct airoha_eth *eth)
> > if (err)
> > goto error_npu_put;
> >
> > + /* Wait for NPU PPE configuration to complete */
> > + err = read_poll_timeout(airoha_fe_rr, val, val, USEC_PER_MSEC,
> > + 100 * USEC_PER_MSEC, false, eth,
> > + REG_PPE_PPE_FLOW_CFG(0));
>
> If the SoC has multiple PPE instances, is it sufficient to only wait for
> REG_PPE_PPE_FLOW_CFG(0)?
>
> Later in airoha_ppe_hw_init(), the code iterates up to eth->soc->num_ppe,
> initializing all available instances:
>
> drivers/net/ethernet/airoha/airoha_ppe.c:airoha_ppe_hw_init() {
> ...
> for (i = 0; i < eth->soc->num_ppe; i++) {
> ...
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
> ...
> }
ack, let me look into it, I will post a v2.
>
> If we only poll PPE 0, could the driver race with the NPU firmware's
> initialization of subsequent PPEs?
>
> Additionally, does this poll condition properly ensure the hardware is ready?
> Since the break condition is simply `val`, it exits immediately if the register
> contains any non-zero value.
>
> If the register retains a non-zero value from a previous session (like across
> driver reloads), or if an unclocked domain returns 0xFFFFFFFF, this poll might
> succeed immediately and bypass the wait.
>
> Could we clear the register before polling, or wait for a specific bit instead?
I guess check val != 0 is enough since we reset the FE block and defualt
register value is 0 for both REG_PPE_PPE_FLOW_CFG(0) and
REG_PPE_PPE_FLOW_CFG(1).
Regards,
Lorenzo
>
> > + if (err)
> > + goto error_npu_put;
> > +
> > ppe_num_stats_entries = airoha_ppe_get_total_num_stats_entries(ppe);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
From: patchwork-bot+netdevbpf @ 2026-04-14 13:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 12 Apr 2026 10:43:26 +0200 you wrote:
> Add the following PPE configuration in airoha_ppe_hw_init routine:
> - 6RD hw offloading is currently not supported by Netfilter flowtable.
> Disable explicitly PPE 6RD offloading in order to prevent PPE to learn
> 6RD flows and eventually interrupt the traffic.
> - Add missing PPE bind rate configuration for L3 and L2 traffic.
> PPE bind rate configuration specifies the pps threshold to move a PPE
> entry state from UNBIND to BIND. Without this configuration this value
> is random.
> - Set ageing thresholds to the values used in the vendor SDK in order to
> improve connection stability under load and avoid packet loss caused by
> fast aging.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()
https://git.kernel.org/netdev/net/c/b9d8b856689d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré @ 2026-04-14 13:24 UTC (permalink / raw)
To: Andrey Konovalov, Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZf-o8tiv_tX9YB5eBUGx17OpztKZsEB6Awjw3WAqBAiUw@mail.gmail.com>
On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote:
> On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:
>>
>> Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
>> KASAN (Kernel Address Sanitizer) memory access checks for JIT-compiled
>> BPF programs, when both KASAN and JIT compiler are enabled. When
>> enabled, the JIT compiler will emit shadow memory checks before memory
>> loads and stores to detect use-after-free, out-of-bounds, and other
>> memory safety bugs at runtime. The option is gated behind
>> HAVE_EBPF_JIT_KASAN, as it needs proper arch-specific implementation.
>>
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>> ---
>> kernel/bpf/Kconfig | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> index eb3de35734f0..28392adb3d7e 100644
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>> @@ -17,6 +17,10 @@ config HAVE_CBPF_JIT
>> config HAVE_EBPF_JIT
>> bool
>>
>> +# KASAN support for JIT compiler
>> +config HAVE_EBPF_JIT_KASAN
>> + bool
>> +
>> # Used by archs to tell that they want the BPF JIT compiler enabled by
>> # default for kernels that were compiled with BPF JIT support.
>> config ARCH_WANT_DEFAULT_BPF_JIT
>> @@ -101,4 +105,9 @@ config BPF_LSM
>>
>> If you are unsure how to answer this question, answer N.
>>
>> +config BPF_JIT_KASAN
>> + bool
>> + depends on HAVE_EBPF_JIT_KASAN
>> + default y if BPF_JIT && KASAN_GENERIC
>
> Should this be "depends on KASAN && KASAN_GENERIC"?
Meaning, making it an explicit user-selectable option ?
If so, the current design choice is voluntary and based on the feedback
received on the original RFC, where I have been suggested to
automatically enable the KASAN instrumentation in BPF programs if KASAN
support is enabled in the kernel ([1]). But if a user-selectable toggle
is eventually a better solution, I'm fine with changing it.
[1] https://lore.kernel.org/bpf/CAADnVQLX7RSnOqQuU32Cgq-e0MVqyeNrtCQSBbk0W2xGkE-ZNw@mail.gmail.com/
>
>
>> +
>> endmenu # "BPF subsystem"
>>
>> --
>> 2.53.0
>>
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v1 0/2] arm_mpam: resctrl: mpam resctrl glue code fixes
From: Ben Horgan @ 2026-04-14 13:27 UTC (permalink / raw)
To: ben.horgan
Cc: Dan Carpenter, Dan Carpenter, James Morse, Reinette Chatre,
Fenghua Yu, lkml, linux-arm-kernel
A couple of minor fixes for the new mpam resctrl glue code. These fix
a sparse warning and and use of an unitialized variable in an
unexpected error case.
Thanks for the bug reports.
Based on arm64 for-next/mpam.
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/mpam
Ben Horgan (2):
arm_mpam: resctrl: Fix the check for no monitor components found
arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
drivers/resctrl/mpam_resctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.43.0
^ 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