History log of /linux-master/arch/arm64/tools/gen-sysreg.awk
Revision Date Author Comments
# 013ecd44 06-Mar-2023 Mark Rutland <mark.rutland@arm.com>

arm64/sysreg: allow *Enum blocks in SysregFields blocks

We'd like to support Enum/SignedEnum/UnsignedEnum blocks within
SysregFields blocks, so that we can define enumerations for sets of
registers. This isn't currently supported by gen-sysreg.awk due to the
way we track the active block, which can't handle more than a single
layer of nesting, which imposes an awkward requirement that when ending
a block we know what the parent block is when calling change_block()

Make this nicer by using a stack of active blocks, with block_push() to
start a block, and block_pop() to end a block. Doing so means that we
only need to check the active block at the start of parsing a line: for
the start of a block we can check the parent is valid, and for the end
of a block we check that the active block is valid.

This structure makes the block parsing simpler and makes it easy to
permit a block to live under several potential parents (e.g. by
permitting Enum to start when the active block is Sysreg or
SysregFields). It also permits further nesting, if we need that in
future.

To aid debugging, the stack of active blocks is reported for fatal
errors, and an error is raised if the file is terminated without ending
the active block. For clarity I've renamed the top-level element from
"None" to "Root".

The Fields element it intended only for use within Sysreg blocks, and
does not make sense within SysregFields blocks, and so remains forbidden
within a SysregFields block.

I've verified using sha1sum that this patch does not change the
current generated contents of <asm/sysreg-defs.h>.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230306114836.2575432-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>


# e2c0b51f 11-Jan-2023 Marc Zyngier <maz@kernel.org>

arm64: Allow the definition of UNKNOWN system register fields

The CCSIDR_EL1 register contains an UNKNOWN field (which replaces
fields that were actually defined in previous revisions of the
architecture).

Define an 'Unkn' field type modeled after the Res0/Res1 types
to allow such description. This allows the generation of

#define CCSIDR_EL1_UNKN (UL(0) | GENMASK_ULL(31, 28))

which may have its use one day. Hopefully the architecture doesn't
add too many of those in the future.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230112023852.42012-2-akihiko.odaki@daynix.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>


# a55d1425 30-Jan-2023 Mark Brown <broonie@kernel.org>

arm64/sysreg: Allow enumerations to be declared as signed or unsigned

Many of our enumerations follow a standard scheme where the values can be
treated as signed however there are some where the value must be treated
as signed and others that are simple enumerations where there is no clear
ordering to the values. Provide new field types SignedEnum and
UnsignedEnum which allows the signedness to be specified in the sysreg
definition and emit a REG_FIELD_SIGNED define for these which is a
boolean corresponding to our current FTR_UNSIGNED and FTR_SIGNED macros.

Existing Enums will need to be converted, since these do not have a
define generated anyone wishing to use the sign of one of these will
need to explicitly annotate that field so nothing should start going
wrong by default.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221207-arm64-sysreg-helpers-v4-1-25b6b3fb9d18@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 7587cdef 30-Nov-2022 James Morse <james.morse@arm.com>

arm64/sysreg: Extend the maximum width of a register and symbol name

32bit has multiple values for its id registers, as extra properties
were added to the CPUs. Some of these end up having long names, which
exceed the fixed 48 character column that the sysreg awk script generates.

For example, the ID_MMFR1_EL1.L1Hvd field has an encoding whose natural
name would be 'invalidate Iside only'. Using this causes compile errors
as the script generates the following:
#define ID_MMFR1_EL1_L1Hvd_INVALIDATE_ISIDE_ONLYUL(0b0001)

Add a few extra characters.

Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-17-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>


# f43ff286 04-Jul-2022 Mark Brown <broonie@kernel.org>

arm64/sysreg: Allow leading blanks on comments in sysreg file

Currently we only accept comments where the # is placed at the start of a
line, allow leading blanks so we can format comments inside definitions in
a more pleasing manner.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220704170302.2609529-4-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>


# ce253b85 09-Jun-2022 Alejandro Tafalla <atafalla@dnyon.com>

arm64/sysreg: Fix typo in Enum element regex

In the awk script, there was a typo with the comparison operator when
checking if the matched pattern is inside an Enum block.
This prevented the generation of the whole sysreg-defs.h header.

Fixes: 66847e0618d7 ("arm64: Add sysreg header generation scripting")
Signed-off-by: Alejandro Tafalla <atafalla@dnyon.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220609204220.12112-1-atafalla@dnyon.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 9e2c0819 10-May-2022 Mark Brown <broonie@kernel.org>

arm64/sysreg: Support generation of RAZ fields

Add a statement for RAZ bitfields to the automatic register generation
script. Nothing is emitted to the header for these fields.

Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20220510161208.631259-7-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 5005d1db 13-May-2022 Mark Rutland <mark.rutland@arm.com>

arm64/sysreg: fix odd line spacing

Between the header and the definitions, there's no line gap, and in a
couple of places a double line gap for no semantic reason, which makes
the output look a little odd.

Fix this so blocks are consistently separated with a single line gap:

* Add a newline after the "Generated file" comment line, so this is
clearly split from whatever the first definition in the file is.

* At the start of a SysregFields block there's no need for a newline as
we haven't output any sysreg encoding details prior to this.

* At the end of a Sysreg block there's no need for a newline if we
have no RES0 or RES1 fields, as there will be a line gap after the
previous element (e.g. a Fields line).

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20220513174118.266966-3-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 82bf5900 13-May-2022 Mark Rutland <mark.rutland@arm.com>

arm64/sysreg: improve comment for regs without fields

Currently for registers without fields we create a comment pointing at
the common definitions, e.g.

| #define REG_TTBR0_EL1 S3_0_C2_C0_0
| #define SYS_TTBR0_EL1 sys_reg(3, 0, 2, 0, 0)
| #define SYS_TTBR0_EL1_Op0 3
| #define SYS_TTBR0_EL1_Op1 0
| #define SYS_TTBR0_EL1_CRn 2
| #define SYS_TTBR0_EL1_CRm 0
| #define SYS_TTBR0_EL1_Op2 0
|
| /* See TTBRx_EL1 */

It would be slightly nicer if the comment said what we should be looking
for, e.g.

| #define REG_TTBR0_EL1 S3_0_C2_C0_0
| #define SYS_TTBR0_EL1 sys_reg(3, 0, 2, 0, 0)
| #define SYS_TTBR0_EL1_Op0 3
| #define SYS_TTBR0_EL1_Op1 0
| #define SYS_TTBR0_EL1_CRn 2
| #define SYS_TTBR0_EL1_CRm 0
| #define SYS_TTBR0_EL1_Op2 0
|
| /* For TTBR0_EL1 fields see TTBRx_EL1 */

Update the comment generation accordingly.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20220513174118.266966-2-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 66847e06 03-May-2022 Mark Rutland <mark.rutland@arm.com>

arm64: Add sysreg header generation scripting

The arm64 kernel requires some metadata for each system register it may
need to access. Currently we have:

* A SYS_<regname> definition which sorresponds to a sys_reg() macro.
This is used both to look up a sysreg by encoding (e.g. in KVM), and
also to generate code to access a sysreg where the assembler is
unaware of the specific sysreg encoding.

Where assemblers support the S3_<op1>_C<crn>_C<crm>_<op2> syntax for
system registers, we could use this rather than manually assembling
the instructions. However, we don't have consistent definitions for
these and we currently still need to handle toolchains that lack this
feature.

* A set of <regname>_<fieldname>_SHIFT and <regname>_<fieldname>_MASK
definitions, which can be used to extract fields from the register, or
to construct a register from a set of fields.

These do not follow the convention used by <linux/bitfield.h>, and the
masks are not shifted into place, preventing their use in FIELD_PREP()
and FIELD_GET(). We require the SHIFT definitions for inline assembly
(and WIDTH definitions would be helpful for UBFX/SBFX), so we cannot
only define a shifted MASK. Defining a SHIFT, WIDTH, shifted MASK and
unshifted MASK is tedious and error-prone and life is much easier when
they can be relied up to exist when writing code.

* A set of <regname>_<fieldname>_<valname> definitions for each
enumerated value a field may hold. These are used when identifying the
presence of features.

Atop of this, other code has to build up metadata at runtime (e.g. the
sets of RES0/RES1 bits in a register).

This patch adds scripting so that we can have an easier-to-manage
canonical representation of this metadata, from which we can generate
all the definitions necessary for various use-cases, e.g.

| #define REG_ID_AA64ISAR0_EL1 S3_0_C0_C6_0
| #define SYS_ID_AA64ISAR0_EL1 sys_reg(3, 0, 0, 6, 0)
| #define SYS_ID_AA64ISAR0_EL1_Op0 3
| #define SYS_ID_AA64ISAR0_EL1_Op1 0
| #define SYS_ID_AA64ISAR0_EL1_CRn 0
| #define SYS_ID_AA64ISAR0_EL1_CRm 6
| #define SYS_ID_AA64ISAR0_EL1_Op2 0

| #define ID_AA64ISAR0_EL1_RNDR GENMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_MASK GENMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_SHIFT 60
| #define ID_AA64ISAR0_EL1_RNDR_WIDTH 4
| #define ID_AA64ISAR0_EL1_RNDR_NI UL(0b0000)
| #define ID_AA64ISAR0_EL1_RNDR_IMP UL(0b0001)

The script requires that all bits in the register be specified and that
there be no overlapping fields. This helps the script spot errors in the
input but means that the few registers which change layout at runtime
depending on things like virtualisation settings will need some manual
handling. No actual register conversions are done here but a header for
the register data with some documention of the format is provided.

For cases where multiple registers share a layout (eg, when identical
controls are provided at multiple ELs) the register fields can be
defined once and referenced from the actual registers, currently we do
not generate actual defines for the individual registers.

At the moment this is only intended to express metadata from the
architecture, and does not handle policy imposed by the kernel, such as
values exposed to userspace or VMs. In future this could be extended to
express such information.

This script was mostly written by Mark Rutland but has been extended by
Mark Brown to improve validation of input and better integrate with the
kernel.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Co-Developed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220503170233.507788-9-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>