Re: [PATCH v3 06/27] arm64: Provide arm64 API for non-native architectures

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Moving the large `esr_get_class_string` function to a `static inline` definition in a widely included header causes unnecessary kernel text bloat.
--

commit f19382b1cbd1896b8ea8e1b5b65a1f8581246812
Author: Steffen Eiden <seiden@linux.ibm.com>

arm64: Provide arm64 API for non-native architectures

This commit introduces a new directory include/arch/arm64/asm to store
architecture-agnostic headers for arm64 implementors. As part of this
change, the esr_get_class_string() function and its associated string
mappings are moved from traps.c to a static inline function in esr.h.

> diff --git a/arch/arm64/include/asm/esr.h b/include/arch/arm64/asm/esr.h
> similarity index 88%
> rename from arch/arm64/include/asm/esr.h
> rename to include/arch/arm64/asm/esr.h
> index 7e86d400864e0..a7421cc966f98 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/include/arch/arm64/asm/esr.h
[ ... ]
> @@ -541,7 +542,56 @@ static inline bool esr_iss_is_eretab(unsigned long esr)
>  	return esr & ESR_ELx_ERET_ISS_ERETA;
>  }
>  
> -const char *esr_get_class_string(unsigned long esr);
> +static inline const char *esr_get_class_string(unsigned long esr)
> +{
> +	switch (ESR_ELx_EC(esr)) {
> +	case ESR_ELx_EC_UNKNOWN:	return "Unknown/Uncategorized";
> +	case ESR_ELx_EC_WFx:		return "WFI/WFE";

[Severity: Low]
Does moving this 45-case switch statement to a static inline function in a
widely included header cause unnecessary kernel text bloat?

Previously, this was implemented as a simple string array in a single
compilation unit (traps.c). By making it a static inline function, the
compiled switch statement and any compiler-generated jump tables or .rodata
string mappings might be unnecessarily duplicated in every compilation unit
that calls it.

While the performance impact is likely negligible since it is primarily called
in slow-path error handling locations, it might be better to keep the
implementation out of the header.

> +	case ESR_ELx_EC_CP15_32:	return "CP15 MCR/MRC";
> +	case ESR_ELx_EC_CP15_64:	return "CP15 MCRR/MRRC";
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529155050.2902245-1-seiden@linux.ibm.com?part=6