Re: [PATCH 01/28] arm64: sysreg: Emit RESx/UNKN values for Mapping definitions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Invalid `_RESx` macros generated for `Mapping` aliases when the target uses `Fields`.
--

commit ba830a7cd4d5bdb5ba927754ed4d1c4e3a0b4f1c
Author: Marc Zyngier <maz@kernel.org>

arm64: sysreg: Emit RESx/UNKN values for Mapping definitions

The sysreg script uses the Mapping qualifier to indicate an encoding is a
mapping to a particular register, but macro generation for RESx classes was
previously skipped. This patch relaxes that rule to emit RESx and UNKN
values for Mapping qualifiers.

> diff --git a/arch/arm64/tools/gen-sysreg.awk b/arch/arm64/tools/gen-sysreg.awk
> index 86860ab672dc7..d7f7ceb768fe5 100755
> --- a/arch/arm64/tools/gen-sysreg.awk
> +++ b/arch/arm64/tools/gen-sysreg.awk

[ ... ]

> @@ -239,9 +239,15 @@ $1 == "EndSysreg" && block_current() == "Sysreg" {
>  	print ""
>  
>  	next_bit = -1
> -	res0 = null
> -	res1 = null
> -	unkn = null
> +	if ($1 == "Mapping") {
> +		res0 = $2 "_RES0"
> +		res1 = $2 "_RES1"
> +		unkn = $2 "_UNKN"

[Severity: Low]
Does this logic generate invalid macros if the target register uses the
"Fields" directive?

If the target register itself delegates its fields using the "Fields"
directive (e.g., ZCR_EL1 using "Fields ZCR_ELx"), the script explicitly
suppresses generation of the target register's _RESx macros (setting them to
null).

As a result, would newly emitted alias macros (such as ZCR_EL12_RES0)
reference undeclared identifiers (like ZCR_EL1_RES0)? Could this cause
build failures if these mapping macros are later consumed by C code?

> +	} else {
> +		res0 = null
> +		res1 = null
> +		unkn = null
> +	}
>  
>  	next
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702160248.1377250-1-maz@kernel.org?part=1