All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 0/8] arm64: Automatic system register definition generation
@ 2022-04-19 10:43 Mark Brown
  2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
                   ` (8 more replies)
  0 siblings, 9 replies; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

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 series introduces a
script which describes registers and the fields within them in a format
that is easy to cross reference with the architecture reference manual
and uses them to generate the constants we use in a standard format:

| #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                   ARM64_SYSREG_BITMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
| #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
| #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
| #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)

This should be particularly useful for the ID registers where we will be
able to specify just the register and field for more of the bitfield
information, simplifying ARM64_FTR_BITS() and providing helpers for use
in struct arm64_cpu_capabilities or for hwcaps.

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 could also be extended to cover more
information such as the FTR_SIGNED/FTR_UNSIGNED distinction. There is
also currently no support for registers which change layout at runtime,
for example based on virtualisation settings - these could be manually
handled for the time being, or the script extended.

At the present time (especially given how near we are to the merge
window) this is as much about getting feedback on the general approach
and how to move forward if we want to move forward. Rather than
attempting to convert every register at once the current series converts
a few sample registers to provide some concrete examples but allow for
easier updating during review of the file format and the script.
Handling a register at a time should also make review less taxing so it
seems like a sensible approach in general.

The generation script was originally written by Mark Rutland and
subsequently improved and integrated into the kernel build by me.

v4:
 - Rebase onto v5.18-rc3.
v3:
 - Rebase onto v5.18-rc1.
v2:
 - Fix issue with building bounds.s in an O= build by renaming the
   generated header.

Mark Brown (7):
  arm64/mte: Move shift from definition of TCF0 enumeration values
  arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names
  arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI
  arm64/sysreg: Enable automatic generation of system register
    definitions
  arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1
  arm64/sysreg: Generate definitions for TTBRn_EL1
  arm64/sysreg: Generate definitions for SCTLR_EL1

Mark Rutland (1):
  arm64: Add sysreg header generation scripting

 arch/arm64/include/asm/Kbuild                 |   1 +
 arch/arm64/include/asm/archrandom.h           |   2 +-
 arch/arm64/include/asm/sysreg.h               |  61 +----
 arch/arm64/kernel/cpufeature.c                |  70 +++---
 arch/arm64/kernel/mte.c                       |   6 +-
 .../arm64/kvm/hyp/include/nvhe/fixed_config.h |  28 +--
 arch/arm64/tools/Makefile                     |   8 +-
 arch/arm64/tools/gen-sysreg.awk               | 213 ++++++++++++++++++
 arch/arm64/tools/sysreg                       | 183 +++++++++++++++
 9 files changed, 466 insertions(+), 106 deletions(-)
 create mode 100755 arch/arm64/tools/gen-sysreg.awk
 create mode 100644 arch/arm64/tools/sysreg


base-commit: b2d229d4ddb17db541098b83524d901257e93845
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:33   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

In preparation for automatic generation of SCTLR_EL1 register definitions
move the shifting of the enumeration values for the TCF0 field from the
defines in the header to the point where they are used.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 8 ++++----
 arch/arm64/kernel/mte.c         | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index fbf5f8bb9055..ff7693902686 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -678,10 +678,10 @@
 #define SCTLR_EL1_ATA0		(BIT(42))
 
 #define SCTLR_EL1_TCF0_SHIFT	38
-#define SCTLR_EL1_TCF0_NONE	(UL(0x0) << SCTLR_EL1_TCF0_SHIFT)
-#define SCTLR_EL1_TCF0_SYNC	(UL(0x1) << SCTLR_EL1_TCF0_SHIFT)
-#define SCTLR_EL1_TCF0_ASYNC	(UL(0x2) << SCTLR_EL1_TCF0_SHIFT)
-#define SCTLR_EL1_TCF0_ASYMM	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
+#define SCTLR_EL1_TCF0_NONE	UL(0x0)
+#define SCTLR_EL1_TCF0_SYNC	UL(0x1)
+#define SCTLR_EL1_TCF0_ASYNC	UL(0x2)
+#define SCTLR_EL1_TCF0_ASYMM	UL(0x3)
 #define SCTLR_EL1_TCF0_MASK	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
 
 #define SCTLR_EL1_BT1		(BIT(36))
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index 78b3e0f8e997..77614f8bc463 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -216,11 +216,11 @@ static void mte_update_sctlr_user(struct task_struct *task)
 	 * default order.
 	 */
 	if (resolved_mte_tcf & MTE_CTRL_TCF_ASYMM)
-		sctlr |= SCTLR_EL1_TCF0_ASYMM;
+		sctlr |= SCTLR_EL1_TCF0_ASYMM << SCTLR_EL1_TCF0_SHIFT;
 	else if (resolved_mte_tcf & MTE_CTRL_TCF_ASYNC)
-		sctlr |= SCTLR_EL1_TCF0_ASYNC;
+		sctlr |= SCTLR_EL1_TCF0_ASYNC << SCTLR_EL1_TCF0_SHIFT;
 	else if (resolved_mte_tcf & MTE_CTRL_TCF_SYNC)
-		sctlr |= SCTLR_EL1_TCF0_SYNC;
+		sctlr |= SCTLR_EL1_TCF0_SYNC << SCTLR_EL1_TCF0_SHIFT;
 	task->thread.sctlr_user = sctlr;
 }
 
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
  2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:35   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

The macros for accessing fields in ID_AA64ISAR0_EL1 omit the _EL1 from the
name of the register. In preparation for converting this register to be
automatically generated update the names to include an _EL1, there should
be no functional change.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/archrandom.h           |  2 +-
 arch/arm64/include/asm/sysreg.h               | 34 ++++-----
 arch/arm64/kernel/cpufeature.c                | 70 +++++++++----------
 .../arm64/kvm/hyp/include/nvhe/fixed_config.h | 28 ++++----
 4 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/archrandom.h b/arch/arm64/include/asm/archrandom.h
index d1bb5e71df25..3a6b6d38c5b8 100644
--- a/arch/arm64/include/asm/archrandom.h
+++ b/arch/arm64/include/asm/archrandom.h
@@ -142,7 +142,7 @@ static inline bool __init __early_cpu_has_rndr(void)
 {
 	/* Open code as we run prior to the first call to cpufeature. */
 	unsigned long ftr = read_sysreg_s(SYS_ID_AA64ISAR0_EL1);
-	return (ftr >> ID_AA64ISAR0_RNDR_SHIFT) & 0xf;
+	return (ftr >> ID_AA64ISAR0_EL1_RNDR_SHIFT) & 0xf;
 }
 
 static inline bool __init __must_check
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index ff7693902686..1911f36773e5 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -729,23 +729,23 @@
 #define MAIR_ATTRIDX(attr, idx)		((attr) << ((idx) * 8))
 
 /* id_aa64isar0 */
-#define ID_AA64ISAR0_RNDR_SHIFT		60
-#define ID_AA64ISAR0_TLB_SHIFT		56
-#define ID_AA64ISAR0_TS_SHIFT		52
-#define ID_AA64ISAR0_FHM_SHIFT		48
-#define ID_AA64ISAR0_DP_SHIFT		44
-#define ID_AA64ISAR0_SM4_SHIFT		40
-#define ID_AA64ISAR0_SM3_SHIFT		36
-#define ID_AA64ISAR0_SHA3_SHIFT		32
-#define ID_AA64ISAR0_RDM_SHIFT		28
-#define ID_AA64ISAR0_ATOMICS_SHIFT	20
-#define ID_AA64ISAR0_CRC32_SHIFT	16
-#define ID_AA64ISAR0_SHA2_SHIFT		12
-#define ID_AA64ISAR0_SHA1_SHIFT		8
-#define ID_AA64ISAR0_AES_SHIFT		4
-
-#define ID_AA64ISAR0_TLB_RANGE_NI	0x0
-#define ID_AA64ISAR0_TLB_RANGE		0x2
+#define ID_AA64ISAR0_EL1_RNDR_SHIFT		60
+#define ID_AA64ISAR0_EL1_TLB_SHIFT		56
+#define ID_AA64ISAR0_EL1_TS_SHIFT		52
+#define ID_AA64ISAR0_EL1_FHM_SHIFT		48
+#define ID_AA64ISAR0_EL1_DP_SHIFT		44
+#define ID_AA64ISAR0_EL1_SM4_SHIFT		40
+#define ID_AA64ISAR0_EL1_SM3_SHIFT		36
+#define ID_AA64ISAR0_EL1_SHA3_SHIFT		32
+#define ID_AA64ISAR0_EL1_RDM_SHIFT		28
+#define ID_AA64ISAR0_EL1_ATOMICS_SHIFT		20
+#define ID_AA64ISAR0_EL1_CRC32_SHIFT		16
+#define ID_AA64ISAR0_EL1_SHA2_SHIFT		12
+#define ID_AA64ISAR0_EL1_SHA1_SHIFT		8
+#define ID_AA64ISAR0_EL1_AES_SHIFT		4
+
+#define ID_AA64ISAR0_EL1_TLB_RANGE_NI		0x0
+#define ID_AA64ISAR0_EL1_TLB_RANGE		0x2
 
 /* id_aa64isar1 */
 #define ID_AA64ISAR1_I8MM_SHIFT		52
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d72c4b4d389c..863a510d8944 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -191,20 +191,20 @@ static bool __system_matches_cap(unsigned int n);
  * sync with the documentation of the CPU feature register ABI.
  */
 static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TLB_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TS_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA3_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_RNDR_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_TLB_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_TS_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_FHM_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_DP_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SM4_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SM3_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA3_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_RDM_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_ATOMICS_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_CRC32_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA1_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_AES_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -2013,7 +2013,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_cpuid_feature,
 		.sys_reg = SYS_ID_AA64ISAR0_EL1,
-		.field_pos = ID_AA64ISAR0_ATOMICS_SHIFT,
+		.field_pos = ID_AA64ISAR0_EL1_ATOMICS_SHIFT,
 		.field_width = 4,
 		.sign = FTR_UNSIGNED,
 		.min_field_value = 2,
@@ -2195,10 +2195,10 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_cpuid_feature,
 		.sys_reg = SYS_ID_AA64ISAR0_EL1,
-		.field_pos = ID_AA64ISAR0_TLB_SHIFT,
+		.field_pos = ID_AA64ISAR0_EL1_TLB_SHIFT,
 		.field_width = 4,
 		.sign = FTR_UNSIGNED,
-		.min_field_value = ID_AA64ISAR0_TLB_RANGE,
+		.min_field_value = ID_AA64ISAR0_EL1_TLB_RANGE,
 	},
 #ifdef CONFIG_ARM64_HW_AFDBM
 	{
@@ -2227,7 +2227,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_cpuid_feature,
 		.sys_reg = SYS_ID_AA64ISAR0_EL1,
-		.field_pos = ID_AA64ISAR0_CRC32_SHIFT,
+		.field_pos = ID_AA64ISAR0_EL1_CRC32_SHIFT,
 		.field_width = 4,
 		.min_field_value = 1,
 	},
@@ -2382,7 +2382,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
 		.matches = has_cpuid_feature,
 		.sys_reg = SYS_ID_AA64ISAR0_EL1,
-		.field_pos = ID_AA64ISAR0_RNDR_SHIFT,
+		.field_pos = ID_AA64ISAR0_EL1_RNDR_SHIFT,
 		.field_width = 4,
 		.sign = FTR_UNSIGNED,
 		.min_field_value = 1,
@@ -2514,22 +2514,22 @@ static const struct arm64_cpu_capabilities ptr_auth_hwcap_gen_matches[] = {
 #endif
 
 static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_FLAGM2),
-	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RNDR_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_RNG),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_AES_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_AES_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA1_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_CRC32_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_ATOMICS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_RDM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SM3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SM4_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_DP_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_FHM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_TS_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_TS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_FLAGM2),
+	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_RNDR_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_RNG),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, 4, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_FP),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, 4, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FPHP),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, 4, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_ASIMD),
diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
index 5ad626527d41..6cda33d23287 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
@@ -159,20 +159,20 @@
  * No restrictions on instructions implemented in AArch64.
  */
 #define PVM_ID_AA64ISAR0_ALLOW (\
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_AES) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA1) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA2) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_CRC32) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_ATOMICS) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_RDM) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA3) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_SM3) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_SM4) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_DP) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_FHM) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_TS) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_TLB) | \
-	ARM64_FEATURE_MASK(ID_AA64ISAR0_RNDR) \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_AES) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA1) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA2) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_CRC32) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_ATOMICS) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_RDM) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA3) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SM3) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SM4) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_DP) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_FHM) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_TS) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_TLB) | \
+	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_RNDR) \
 	)
 
 #define PVM_ID_AA64ISAR1_ALLOW (\
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
  2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
  2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:36   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

We already use lower case in some defines in sysreg.h, for consistency with
the architecture definition do so for SCTLR_EL1.nTWE and SCTLR_EL1.nTWI.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 1911f36773e5..f300c49d6281 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -689,8 +689,8 @@
 #define SCTLR_EL1_UCI		(BIT(26))
 #define SCTLR_EL1_E0E		(BIT(24))
 #define SCTLR_EL1_SPAN		(BIT(23))
-#define SCTLR_EL1_NTWE		(BIT(18))
-#define SCTLR_EL1_NTWI		(BIT(16))
+#define SCTLR_EL1_nTWE		(BIT(18))
+#define SCTLR_EL1_nTWI		(BIT(16))
 #define SCTLR_EL1_UCT		(BIT(15))
 #define SCTLR_EL1_DZE		(BIT(14))
 #define SCTLR_EL1_UMA		(BIT(9))
@@ -714,7 +714,7 @@
 #define INIT_SCTLR_EL1_MMU_ON \
 	(SCTLR_ELx_M    | SCTLR_ELx_C    | SCTLR_ELx_SA   | SCTLR_EL1_SA0   | \
 	 SCTLR_EL1_SED  | SCTLR_ELx_I    | SCTLR_EL1_DZE  | SCTLR_EL1_UCT   | \
-	 SCTLR_EL1_NTWE | SCTLR_ELx_IESB | SCTLR_EL1_SPAN | SCTLR_ELx_ITFSB | \
+	 SCTLR_EL1_nTWE | SCTLR_ELx_IESB | SCTLR_EL1_SPAN | SCTLR_ELx_ITFSB | \
 	 ENDIAN_SET_EL1 | SCTLR_EL1_UCI  | SCTLR_EL1_EPAN | SCTLR_EL1_RES1)
 
 /* MAIR_ELx memory attributes (used by Linux) */
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (2 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:47   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

From: Mark Rutland <mark.rutland@arm.com>

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                   ARM64_SYSREG_BITMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)
| #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
| #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
| #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
| #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(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.

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>
---
 arch/arm64/tools/gen-sysreg.awk | 213 ++++++++++++++++++++++++++++++++
 arch/arm64/tools/sysreg         |  34 +++++
 2 files changed, 247 insertions(+)
 create mode 100755 arch/arm64/tools/gen-sysreg.awk
 create mode 100644 arch/arm64/tools/sysreg

diff --git a/arch/arm64/tools/gen-sysreg.awk b/arch/arm64/tools/gen-sysreg.awk
new file mode 100755
index 000000000000..4be092372b16
--- /dev/null
+++ b/arch/arm64/tools/gen-sysreg.awk
@@ -0,0 +1,213 @@
+#!/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+# gen-sysreg.awk: arm64 sysreg header generator
+#
+# Usage: awk -f gen-sysreg.awk sysregs.txt
+
+# Log an error and terminate
+function fatal(msg) {
+	print "Error at " NR ": " msg > "/dev/stderr"
+	exit 1
+}
+
+# Sanity check that the start or end of a block makes sense at this point in
+# the file. If not, produce an error and terminate.
+#
+# @this - the $Block or $EndBlock
+# @prev - the only valid block to already be in (value of @block)
+# @new - the new value of @block
+function change_block(this, prev, new) {
+	if (block != prev)
+		fatal("unexpected " this " (inside " block ")")
+
+	block = new
+}
+
+# Sanity check the number of records for a field makes sense. If not, produce
+# an error and terminate.
+function expect_fields(nf) {
+	if (NF != nf)
+		fatal(NF " fields found where " nf " expected")
+}
+
+# Print a CPP macro definition, padded with spaces so that the macro bodies
+# line up in a column
+function define(name, val) {
+	printf "%-48s%s\n", "#define " name, val
+}
+
+# Print standard BITMASK/SHIFT/WIDTH CPP definitions for a field
+function define_field(reg, field, msb, lsb) {
+	define(reg "_" field, "GENMASK_ULL(" msb ", " lsb ")")
+	define(reg "_" field "_MASK", "GENMASK_ULL(" msb ", " lsb ")")
+	define(reg "_" field "_SHIFT", lsb)
+	define(reg "_" field "_WIDTH", msb - lsb + 1)
+}
+
+# Parse a "<msb>[:<lsb>]" string into the global variables @msb and @lsb
+function parse_bitdef(reg, field, bitdef, _bits)
+{
+	if (bitdef ~ /^[0-9]+$/) {
+		msb = bitdef
+		lsb = bitdef
+	} else if (split(bitdef, _bits, ":") == 2) {
+		msb = _bits[1]
+		lsb = _bits[2]
+	} else {
+		fatal("invalid bit-range definition '" bitdef "'")
+	}
+
+
+	if (msb != next_bit)
+		fatal(reg "." field " starts at " msb " not " next_bit)
+	if (63 < msb || msb < 0)
+		fatal(reg "." field " invalid high bit in '" bitdef "'")
+	if (63 < lsb || lsb < 0)
+		fatal(reg "." field " invalid low bit in '" bitdef "'")
+	if (msb < lsb)
+		fatal(reg "." field " invalid bit-range '" bitdef "'")
+	if (low > high)
+		fatal(reg "." field " has invalid range " high "-" low)
+
+	next_bit = lsb - 1
+}
+
+BEGIN {
+	print "#ifndef __ASM_SYSREG_GEN_H"
+	print "#define __ASM_SYSREG_GEN_H"
+	print ""
+	print "/* Generated file - do not edit */"
+
+	block = "None"
+}
+
+END {
+	print "#endif /* __ASM_SYSREG_GEN_H */"
+}
+
+# skip blank lines and comment lines
+/^$/ { next }
+/^#/ { next }
+
+/^Sysreg/ {
+	change_block("Sysreg", "None", "Sysreg")
+	expect_fields(7)
+
+	reg = $2
+	op0 = $3
+	op1 = $4
+	crn = $5
+	crm = $6
+	op2 = $7
+
+	res0 = "UL(0)"
+	res1 = "UL(0)"
+
+	define("REG_" reg, "S" op0 "_" op1 "_C" crn "_C" crm "_" op2)
+	define("SYS_" reg, "sys_reg(" op0 ", " op1 ", " crn ", " crm ", " op2 ")")
+
+	define("SYS_" reg "_Op0", op0)
+	define("SYS_" reg "_Op1", op1)
+	define("SYS_" reg "_CRn", crn)
+	define("SYS_" reg "_CRm", crm)
+	define("SYS_" reg "_Op2", op2)
+
+	print ""
+
+	next_bit = 63
+
+	next
+}
+
+/^EndSysreg/ {
+	if (next_bit > 0)
+		fatal("Unspecified bits in " reg)
+
+	change_block("EndSysreg", "Sysreg", "None")
+
+	define(reg "_RES0", "(" res0 ")")
+	define(reg "_RES1", "(" res1 ")")
+	print ""
+
+	reg = null
+	op0 = null
+	op1 = null
+	crn = null
+	crm = null
+	op2 = null
+	res0 = null
+	res1 = null
+
+	next
+}
+
+/^Res0/ && block = "Sysreg" {
+	expect_fields(2)
+	parse_bitdef(reg, "RES0", $2)
+	field = "RES0_" msb "_" lsb
+
+	define_field(reg, field, msb, lsb)
+	print ""
+
+	res0 = res0 " | " reg "_" field
+
+	next
+}
+
+/^Res1/ && block = "Sysreg" {
+	expect_fields(2)
+	parse_bitdef(reg, "RES1", $2)
+	field = "RES1_" msb "_" lsb
+
+	define_field(reg, field, msb, lsb)
+	print ""
+
+	res1 = res1 " | " reg "_" field
+
+	next
+}
+
+/^Field/ && block = "Sysreg" {
+	expect_fields(3)
+	field = $3
+	parse_bitdef(reg, field, $2)
+
+	define_field(reg, field, msb, lsb)
+	print ""
+
+	next
+}
+
+/^Enum/ {
+	change_block("Enum", "Sysreg", "Enum")
+	expect_fields(3)
+	field = $3
+	parse_bitdef(reg, field, $2)
+
+	define_field(reg, field, msb, lsb)
+
+	next
+}
+
+/^EndEnum/ {
+	change_block("EndEnum", "Enum", "Sysreg")
+	field = null
+	msb = null
+	lsb = null
+	print ""
+	next
+}
+
+/0b[01]+/ && block = "Enum" {
+	expect_fields(2)
+	val = $1
+	name = $2
+
+	define(reg "_" field "_" name, "ULL(" val ")")
+	next
+}
+
+# Any lines not handled by previous rules are unexpected
+{
+	fatal("unhandled statement")
+}
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
new file mode 100644
index 000000000000..3595c68b9a0b
--- /dev/null
+++ b/arch/arm64/tools/sysreg
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# System register metadata
+
+# Each System register is described by a Sysreg block:
+
+# Sysreg 	<name>	<op0> 	<op1>	<crn>	<crm>	<op2>
+# <field>
+# ...
+# EndSysreg
+
+# Within a Sysreg block, each field can be described as one of:
+
+# Res0	<msb>[:<lsb>]
+
+# Res1	<msb>[:<lsb>]
+
+# Field	<msb>[:<lsb>]	<name>
+
+# Enum	<msb>[:<lsb>]	<name>
+#	<enumval>	<enumname>
+#	...
+# EndEnum
+
+# For ID registers we adopt a few conventions for translating the
+# language in the ARM into defines:
+#
+# NI  - Not implemented
+# IMP - Implemented
+#
+# In general it is recommended that new enumeration items be named for the
+# feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
+# item ACCDATA) though it may be more taseful to do something else.
+
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (3 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:52   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

Now that we have a script for generating system registers hook it up to the
build system similarly to cpucaps. Since we don't currently have any actual
register information in the input file this should produce no change in the
built kernel. For ease of review the register information will be converted
in separate patches.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/Kbuild   | 1 +
 arch/arm64/include/asm/sysreg.h | 8 ++++++++
 arch/arm64/tools/Makefile       | 8 +++++++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 345fe98605ba..1eac9aa6fa2e 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -7,3 +7,4 @@ generic-y += parport.h
 generic-y += user.h
 
 generated-y += cpucaps.h
+generated-y += sysreg-gen.h
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f300c49d6281..11bf3636c741 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -114,6 +114,14 @@
 #define SYS_DC_CSW			sys_insn(1, 0, 7, 10, 2)
 #define SYS_DC_CISW			sys_insn(1, 0, 7, 14, 2)
 
+/*
+ * Automatically generated definitions for system registers, the
+ * manual encodings below are in the process of being converted to
+ * come from here. The header relies on the definition of sys_reg()
+ * earlier in this file.
+ */
+#include "asm/sysreg-gen.h"
+
 /*
  * System registers, organised loosely by encoding but grouped together
  * where the architected name contains an index. e.g. ID_MMFR<n>_EL1.
diff --git a/arch/arm64/tools/Makefile b/arch/arm64/tools/Makefile
index cf1307188150..8d2d38858a0d 100644
--- a/arch/arm64/tools/Makefile
+++ b/arch/arm64/tools/Makefile
@@ -3,7 +3,7 @@
 gen := arch/$(ARCH)/include/generated
 kapi := $(gen)/asm
 
-kapi-hdrs-y := $(kapi)/cpucaps.h
+kapi-hdrs-y := $(kapi)/cpucaps.h $(kapi)/sysreg-gen.h
 
 targets += $(addprefix ../../../, $(kapi-hdrs-y))
 
@@ -14,5 +14,11 @@ kapi:   $(kapi-hdrs-y)
 quiet_cmd_gen_cpucaps = GEN     $@
       cmd_gen_cpucaps = mkdir -p $(dir $@); $(AWK) -f $(real-prereqs) > $@
 
+quiet_cmd_gen_sysreg = GEN     $@
+      cmd_gen_sysreg = mkdir -p $(dir $@); $(AWK) -f $(real-prereqs) > $@
+
 $(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE
 	$(call if_changed,gen_cpucaps)
+
+$(kapi)/sysreg-gen.h: $(src)/gen-sysreg.awk $(src)/sysreg FORCE
+	$(call if_changed,gen_sysreg)
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (4 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:58   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
                   ` (2 subsequent siblings)
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

Remove the manual definitions for ID_AA64ISAR0_EL1 in favour of automatic
generation. There should be no functional change. Other notable changes:

 - 27:24 TME is defined rather than RES0 reflecting DDI0487H.a.
 - 23:20 Atomic is named "atomics" reflecting existing usage.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 20 ----------
 arch/arm64/tools/sysreg         | 67 +++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 11bf3636c741..2b5cc67b3bc3 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -196,7 +196,6 @@
 #define SYS_ID_AA64AFR0_EL1		sys_reg(3, 0, 0, 5, 4)
 #define SYS_ID_AA64AFR1_EL1		sys_reg(3, 0, 0, 5, 5)
 
-#define SYS_ID_AA64ISAR0_EL1		sys_reg(3, 0, 0, 6, 0)
 #define SYS_ID_AA64ISAR1_EL1		sys_reg(3, 0, 0, 6, 1)
 #define SYS_ID_AA64ISAR2_EL1		sys_reg(3, 0, 0, 6, 2)
 
@@ -736,25 +735,6 @@
 /* Position the attr at the correct index */
 #define MAIR_ATTRIDX(attr, idx)		((attr) << ((idx) * 8))
 
-/* id_aa64isar0 */
-#define ID_AA64ISAR0_EL1_RNDR_SHIFT		60
-#define ID_AA64ISAR0_EL1_TLB_SHIFT		56
-#define ID_AA64ISAR0_EL1_TS_SHIFT		52
-#define ID_AA64ISAR0_EL1_FHM_SHIFT		48
-#define ID_AA64ISAR0_EL1_DP_SHIFT		44
-#define ID_AA64ISAR0_EL1_SM4_SHIFT		40
-#define ID_AA64ISAR0_EL1_SM3_SHIFT		36
-#define ID_AA64ISAR0_EL1_SHA3_SHIFT		32
-#define ID_AA64ISAR0_EL1_RDM_SHIFT		28
-#define ID_AA64ISAR0_EL1_ATOMICS_SHIFT		20
-#define ID_AA64ISAR0_EL1_CRC32_SHIFT		16
-#define ID_AA64ISAR0_EL1_SHA2_SHIFT		12
-#define ID_AA64ISAR0_EL1_SHA1_SHIFT		8
-#define ID_AA64ISAR0_EL1_AES_SHIFT		4
-
-#define ID_AA64ISAR0_EL1_TLB_RANGE_NI		0x0
-#define ID_AA64ISAR0_EL1_TLB_RANGE		0x2
-
 /* id_aa64isar1 */
 #define ID_AA64ISAR1_I8MM_SHIFT		52
 #define ID_AA64ISAR1_DGH_SHIFT		48
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 3595c68b9a0b..040745387528 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -32,3 +32,70 @@
 # feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
 # item ACCDATA) though it may be more taseful to do something else.
 
+Sysreg	ID_AA64ISAR0_EL1	3	0	0	6	0
+Enum	63:60	RNDR
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	59:56	TLB
+	0b0000	NI
+	0b0001	OS
+	0b0010	RANGE
+EndEnum
+Enum	55:52	TS
+	0b0000	NI
+	0b0001	FLAGM
+	0b0010	FLAGM2
+EndEnum
+Enum	51:48	FHM
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	47:44	DP
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	43:40	SM4
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	39:36	SM3
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	35:32	SHA3
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	31:28	RDM
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	27:24	TME
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	23:20	ATOMICS
+	0b0000	NI
+	0b0010	IMP
+EndEnum
+Enum	19:16	CRC32
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	15:12	SHA2
+	0b0000	NI
+	0b0001	SHA256
+	0b0010	SHA512
+EndEnum
+Enum	11:8	SHA1
+	0b0000	NI
+	0b0001	IMP
+EndEnum
+Enum	7:4	AES
+	0b0000	NI
+	0b0001	AES
+	0b0010	PMULL
+EndEnum
+Res0	3:0
+EndSysreg
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (5 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21  9:59   ` Mark Rutland
  2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
  2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

Automatically generate definitions for accessing the TTBR0_EL1 registers,
no functional change.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/sysreg.h |  2 --
 arch/arm64/tools/sysreg         | 12 ++++++++++++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 2b5cc67b3bc3..b9023797a5b9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -212,8 +212,6 @@
 #define SYS_ZCR_EL1			sys_reg(3, 0, 1, 2, 0)
 #define SYS_TRFCR_EL1			sys_reg(3, 0, 1, 2, 1)
 
-#define SYS_TTBR0_EL1			sys_reg(3, 0, 2, 0, 0)
-#define SYS_TTBR1_EL1			sys_reg(3, 0, 2, 0, 1)
 #define SYS_TCR_EL1			sys_reg(3, 0, 2, 0, 2)
 
 #define SYS_APIAKEYLO_EL1		sys_reg(3, 0, 2, 1, 0)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 040745387528..f6195ccbf9b8 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -99,3 +99,15 @@ Enum	7:4	AES
 EndEnum
 Res0	3:0
 EndSysreg
+
+Sysreg	TTBR0_EL1	3	0	2	0	0
+Field	63:48	ASID
+Field	47:1	BADDR
+Field	0	CnP
+EndSysreg
+
+Sysreg	TTBR1_EL1	3	0	2	0	1
+Field	63:48	ASID
+Field	47:1	BADDR
+Field	0	CnP
+EndSysreg
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (6 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
@ 2022-04-19 10:43 ` Mark Brown
  2022-04-21 10:05   ` Mark Rutland
  2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-19 10:43 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Suzuki K Poulose, linux-arm-kernel,
	Mark Brown

Automatically generate register definitions for SCTLR_EL1. No functional
change.

Several fields which are defined in the current revision of DDI0487 but
which are not yet used by the kernel are left as RES1 in order to ensure
that the SCTLR_EL1_RES1 mask used for early initialisation of SCTLR_EL1 is
not changed. These are LSMAOE, nTLSMD, EIS, TSCXT and EOS.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 29 --------------
 arch/arm64/tools/sysreg         | 70 +++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index b9023797a5b9..63b545260e62 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -203,7 +203,6 @@
 #define SYS_ID_AA64MMFR1_EL1		sys_reg(3, 0, 0, 7, 1)
 #define SYS_ID_AA64MMFR2_EL1		sys_reg(3, 0, 0, 7, 2)
 
-#define SYS_SCTLR_EL1			sys_reg(3, 0, 1, 0, 0)
 #define SYS_ACTLR_EL1			sys_reg(3, 0, 1, 0, 1)
 #define SYS_CPACR_EL1			sys_reg(3, 0, 1, 0, 2)
 #define SYS_RGSR_EL1			sys_reg(3, 0, 1, 0, 5)
@@ -679,34 +678,6 @@
 	(SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
 
 /* SCTLR_EL1 specific flags. */
-#define SCTLR_EL1_EPAN		(BIT(57))
-#define SCTLR_EL1_ATA0		(BIT(42))
-
-#define SCTLR_EL1_TCF0_SHIFT	38
-#define SCTLR_EL1_TCF0_NONE	UL(0x0)
-#define SCTLR_EL1_TCF0_SYNC	UL(0x1)
-#define SCTLR_EL1_TCF0_ASYNC	UL(0x2)
-#define SCTLR_EL1_TCF0_ASYMM	UL(0x3)
-#define SCTLR_EL1_TCF0_MASK	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
-
-#define SCTLR_EL1_BT1		(BIT(36))
-#define SCTLR_EL1_BT0		(BIT(35))
-#define SCTLR_EL1_UCI		(BIT(26))
-#define SCTLR_EL1_E0E		(BIT(24))
-#define SCTLR_EL1_SPAN		(BIT(23))
-#define SCTLR_EL1_nTWE		(BIT(18))
-#define SCTLR_EL1_nTWI		(BIT(16))
-#define SCTLR_EL1_UCT		(BIT(15))
-#define SCTLR_EL1_DZE		(BIT(14))
-#define SCTLR_EL1_UMA		(BIT(9))
-#define SCTLR_EL1_SED		(BIT(8))
-#define SCTLR_EL1_ITD		(BIT(7))
-#define SCTLR_EL1_CP15BEN	(BIT(5))
-#define SCTLR_EL1_SA0		(BIT(4))
-
-#define SCTLR_EL1_RES1	((BIT(11)) | (BIT(20)) | (BIT(22)) | (BIT(28)) | \
-			 (BIT(29)))
-
 #ifdef CONFIG_CPU_BIG_ENDIAN
 #define ENDIAN_SET_EL1		(SCTLR_EL1_E0E | SCTLR_ELx_EE)
 #else
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index f6195ccbf9b8..6248cfbf5288 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -100,6 +100,76 @@ EndEnum
 Res0	3:0
 EndSysreg
 
+Sysreg	SCTLR_EL1	3	0	1	9	9
+Field	63	TIDCP
+Field	62	SPINMASK
+Field	61	NMI
+Field	60	EnTP2
+Res0	59:58
+Field	57	EPAN
+Field	56	EnALS
+Field	55	EnAS0
+Field	54	EnASR
+Field	53	TME
+Field	52	TME0
+Field	51	TMT
+Field	50	TMT0
+Field	49:46	TWEDEL
+Field	45	TWEDEn
+Field	44	DSSBS
+Field	43	ATA
+Field	42	ATA0
+Enum	41:40	TCF
+	0b00	NONE
+	0b01	SYNC
+	0b10	ASYNC
+	0b11	ASYMM
+EndEnum
+Enum	39:38	TCF0
+	0b00	NONE
+	0b01	SYNC
+	0b10	ASYNC
+	0b11	ASYMM
+EndEnum
+Field	37	ITFSB
+Field	36	BT1
+Field	35	BT0
+Res0	34
+Field	33	MSCEn
+Field	32	CMOW
+Field	31	EnIA
+Field	30	EnIB
+Res1	29:28
+Field	27	EnDA
+Field	26	UCI
+Field	25	EE
+Field	24	E0E
+Field	23	SPAN
+Res1	22
+Field	21	IESB
+Res1	20
+Field	19	WXN
+Field	18	nTWE
+Res0	17
+Field	16	nTWI
+Field	15	UCT
+Field	14	DZE
+Field	13	EnDB
+Field	12	I
+Res1	11
+Field	10	EnRCTX
+Field	9	UMA
+Field	8	SED
+Field	7	ITD
+Field	6	nAA
+Field	5	CP15BEN
+Field	4	SA0
+Field	3	SA
+Field	2	C
+Field	1	A
+Field	0	M
+EndSysreg
+
 Sysreg	TTBR0_EL1	3	0	2	0	0
 Field	63:48	ASID
 Field	47:1	BADDR
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values
  2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
@ 2022-04-21  9:33   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:33 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

Hi Mark,

I've obviously in favour of scripting, and the changes below look sound to me, so:

Acked-by: Mark Rutland <mark.rutland@arm.com>

I have a couple of minor comments on the commit message, and one suggestion on
the actual code, but the ack stands either way.

On Tue, Apr 19, 2022 at 11:43:22AM +0100, Mark Brown wrote:
> In preparation for automatic generation of SCTLR_EL1 register definitions
> move the shifting of the enumeration values for the TCF0 field from the
> defines in the header to the point where they are used.

It might be worth saying explicitly that this is because the scripting
consistently define enum values *without* shifting.

Likewise saying that the MASK definition is deliberately left shifted as that
defines the bit position of the field, and can be used with FIELD_GET() /
FIELD_PREP().

You can also add something like:

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

... to make it clear that this is just a refactoring.

> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/sysreg.h | 8 ++++----
>  arch/arm64/kernel/mte.c         | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index fbf5f8bb9055..ff7693902686 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -678,10 +678,10 @@
>  #define SCTLR_EL1_ATA0		(BIT(42))
>  
>  #define SCTLR_EL1_TCF0_SHIFT	38
> -#define SCTLR_EL1_TCF0_NONE	(UL(0x0) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_SYNC	(UL(0x1) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_ASYNC	(UL(0x2) << SCTLR_EL1_TCF0_SHIFT)
> -#define SCTLR_EL1_TCF0_ASYMM	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
> +#define SCTLR_EL1_TCF0_NONE	UL(0x0)
> +#define SCTLR_EL1_TCF0_SYNC	UL(0x1)
> +#define SCTLR_EL1_TCF0_ASYNC	UL(0x2)
> +#define SCTLR_EL1_TCF0_ASYMM	UL(0x3)
>  #define SCTLR_EL1_TCF0_MASK	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
>  
>  #define SCTLR_EL1_BT1		(BIT(36))
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 78b3e0f8e997..77614f8bc463 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -216,11 +216,11 @@ static void mte_update_sctlr_user(struct task_struct *task)
>  	 * default order.
>  	 */
>  	if (resolved_mte_tcf & MTE_CTRL_TCF_ASYMM)
> -		sctlr |= SCTLR_EL1_TCF0_ASYMM;
> +		sctlr |= SCTLR_EL1_TCF0_ASYMM << SCTLR_EL1_TCF0_SHIFT;

Generally we should probably use FIELD_PREP()/FIELD_GET() in C code, so maybe
we should make this:

		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, SCTLR_EL1_TCF0_ASYMM);

Going forward, it might be worth having some helpers that allow us to avoid the
redundant bits, and save humans having to care about how we namespace the
definitions, e.g.

		sctlr |= SYS_FIELD_PREP(SCTLR_EL1, TCF0, 0x0);
	is:
		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, 0x0);


		sctlr |= SYS_FIELD_PREP_ENUM(SCTLR_EL1, TCF0, ASYMM);
	is
		sctlr |= FIELD_PREP(SCTLR_EL1_TCF0_MASK, SCTLR_EL1_TCF0_ASYMM);

Thanks,
Mark.

>  	else if (resolved_mte_tcf & MTE_CTRL_TCF_ASYNC)
> -		sctlr |= SCTLR_EL1_TCF0_ASYNC;
> +		sctlr |= SCTLR_EL1_TCF0_ASYNC << SCTLR_EL1_TCF0_SHIFT;
>  	else if (resolved_mte_tcf & MTE_CTRL_TCF_SYNC)
> -		sctlr |= SCTLR_EL1_TCF0_SYNC;
> +		sctlr |= SCTLR_EL1_TCF0_SYNC << SCTLR_EL1_TCF0_SHIFT;
>  	task->thread.sctlr_user = sctlr;
>  }
>  
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names
  2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
@ 2022-04-21  9:35   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:35 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:23AM +0100, Mark Brown wrote:
> The macros for accessing fields in ID_AA64ISAR0_EL1 omit the _EL1 from the
> name of the register. In preparation for converting this register to be
> automatically generated update the names to include an _EL1, there should
> be no functional change.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

Doing this consistently makes sense to me, so FWIW:

Acked-by: Mark RUtland <mark.rutland@arm.com>

Thanks,
Mark.

> ---
>  arch/arm64/include/asm/archrandom.h           |  2 +-
>  arch/arm64/include/asm/sysreg.h               | 34 ++++-----
>  arch/arm64/kernel/cpufeature.c                | 70 +++++++++----------
>  .../arm64/kvm/hyp/include/nvhe/fixed_config.h | 28 ++++----
>  4 files changed, 67 insertions(+), 67 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/archrandom.h b/arch/arm64/include/asm/archrandom.h
> index d1bb5e71df25..3a6b6d38c5b8 100644
> --- a/arch/arm64/include/asm/archrandom.h
> +++ b/arch/arm64/include/asm/archrandom.h
> @@ -142,7 +142,7 @@ static inline bool __init __early_cpu_has_rndr(void)
>  {
>  	/* Open code as we run prior to the first call to cpufeature. */
>  	unsigned long ftr = read_sysreg_s(SYS_ID_AA64ISAR0_EL1);
> -	return (ftr >> ID_AA64ISAR0_RNDR_SHIFT) & 0xf;
> +	return (ftr >> ID_AA64ISAR0_EL1_RNDR_SHIFT) & 0xf;
>  }
>  
>  static inline bool __init __must_check
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index ff7693902686..1911f36773e5 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -729,23 +729,23 @@
>  #define MAIR_ATTRIDX(attr, idx)		((attr) << ((idx) * 8))
>  
>  /* id_aa64isar0 */
> -#define ID_AA64ISAR0_RNDR_SHIFT		60
> -#define ID_AA64ISAR0_TLB_SHIFT		56
> -#define ID_AA64ISAR0_TS_SHIFT		52
> -#define ID_AA64ISAR0_FHM_SHIFT		48
> -#define ID_AA64ISAR0_DP_SHIFT		44
> -#define ID_AA64ISAR0_SM4_SHIFT		40
> -#define ID_AA64ISAR0_SM3_SHIFT		36
> -#define ID_AA64ISAR0_SHA3_SHIFT		32
> -#define ID_AA64ISAR0_RDM_SHIFT		28
> -#define ID_AA64ISAR0_ATOMICS_SHIFT	20
> -#define ID_AA64ISAR0_CRC32_SHIFT	16
> -#define ID_AA64ISAR0_SHA2_SHIFT		12
> -#define ID_AA64ISAR0_SHA1_SHIFT		8
> -#define ID_AA64ISAR0_AES_SHIFT		4
> -
> -#define ID_AA64ISAR0_TLB_RANGE_NI	0x0
> -#define ID_AA64ISAR0_TLB_RANGE		0x2
> +#define ID_AA64ISAR0_EL1_RNDR_SHIFT		60
> +#define ID_AA64ISAR0_EL1_TLB_SHIFT		56
> +#define ID_AA64ISAR0_EL1_TS_SHIFT		52
> +#define ID_AA64ISAR0_EL1_FHM_SHIFT		48
> +#define ID_AA64ISAR0_EL1_DP_SHIFT		44
> +#define ID_AA64ISAR0_EL1_SM4_SHIFT		40
> +#define ID_AA64ISAR0_EL1_SM3_SHIFT		36
> +#define ID_AA64ISAR0_EL1_SHA3_SHIFT		32
> +#define ID_AA64ISAR0_EL1_RDM_SHIFT		28
> +#define ID_AA64ISAR0_EL1_ATOMICS_SHIFT		20
> +#define ID_AA64ISAR0_EL1_CRC32_SHIFT		16
> +#define ID_AA64ISAR0_EL1_SHA2_SHIFT		12
> +#define ID_AA64ISAR0_EL1_SHA1_SHIFT		8
> +#define ID_AA64ISAR0_EL1_AES_SHIFT		4
> +
> +#define ID_AA64ISAR0_EL1_TLB_RANGE_NI		0x0
> +#define ID_AA64ISAR0_EL1_TLB_RANGE		0x2
>  
>  /* id_aa64isar1 */
>  #define ID_AA64ISAR1_I8MM_SHIFT		52
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index d72c4b4d389c..863a510d8944 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -191,20 +191,20 @@ static bool __system_matches_cap(unsigned int n);
>   * sync with the documentation of the CPU feature register ABI.
>   */
>  static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TLB_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_TS_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA3_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> -	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_RNDR_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_TLB_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_TS_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_FHM_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_DP_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SM4_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SM3_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA3_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_RDM_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_ATOMICS_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_CRC32_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_SHA1_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_EL1_AES_SHIFT, 4, 0),
>  	ARM64_FTR_END,
>  };
>  
> @@ -2013,7 +2013,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  		.matches = has_cpuid_feature,
>  		.sys_reg = SYS_ID_AA64ISAR0_EL1,
> -		.field_pos = ID_AA64ISAR0_ATOMICS_SHIFT,
> +		.field_pos = ID_AA64ISAR0_EL1_ATOMICS_SHIFT,
>  		.field_width = 4,
>  		.sign = FTR_UNSIGNED,
>  		.min_field_value = 2,
> @@ -2195,10 +2195,10 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  		.matches = has_cpuid_feature,
>  		.sys_reg = SYS_ID_AA64ISAR0_EL1,
> -		.field_pos = ID_AA64ISAR0_TLB_SHIFT,
> +		.field_pos = ID_AA64ISAR0_EL1_TLB_SHIFT,
>  		.field_width = 4,
>  		.sign = FTR_UNSIGNED,
> -		.min_field_value = ID_AA64ISAR0_TLB_RANGE,
> +		.min_field_value = ID_AA64ISAR0_EL1_TLB_RANGE,
>  	},
>  #ifdef CONFIG_ARM64_HW_AFDBM
>  	{
> @@ -2227,7 +2227,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  		.matches = has_cpuid_feature,
>  		.sys_reg = SYS_ID_AA64ISAR0_EL1,
> -		.field_pos = ID_AA64ISAR0_CRC32_SHIFT,
> +		.field_pos = ID_AA64ISAR0_EL1_CRC32_SHIFT,
>  		.field_width = 4,
>  		.min_field_value = 1,
>  	},
> @@ -2382,7 +2382,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>  		.matches = has_cpuid_feature,
>  		.sys_reg = SYS_ID_AA64ISAR0_EL1,
> -		.field_pos = ID_AA64ISAR0_RNDR_SHIFT,
> +		.field_pos = ID_AA64ISAR0_EL1_RNDR_SHIFT,
>  		.field_width = 4,
>  		.sign = FTR_UNSIGNED,
>  		.min_field_value = 1,
> @@ -2514,22 +2514,22 @@ static const struct arm64_cpu_capabilities ptr_auth_hwcap_gen_matches[] = {
>  #endif
>  
>  static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_TS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_FLAGM2),
> -	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RNDR_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_RNG),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_AES_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_PMULL),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_AES_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AES),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA1_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA1),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA2),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA2_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_SHA512),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_CRC32_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_CRC32),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_ATOMICS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_ATOMICS),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_RDM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDRDM),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SHA3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SHA3),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SM3_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM3),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_SM4_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_SM4),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_DP_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDDP),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_FHM_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ASIMDFHM),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_TS_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FLAGM),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_TS_SHIFT, 4, FTR_UNSIGNED, 2, CAP_HWCAP, KERNEL_HWCAP_FLAGM2),
> +	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_EL1_RNDR_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_RNG),
>  	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, 4, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_FP),
>  	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, 4, FTR_SIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_FPHP),
>  	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, 4, FTR_SIGNED, 0, CAP_HWCAP, KERNEL_HWCAP_ASIMD),
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> index 5ad626527d41..6cda33d23287 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> @@ -159,20 +159,20 @@
>   * No restrictions on instructions implemented in AArch64.
>   */
>  #define PVM_ID_AA64ISAR0_ALLOW (\
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_AES) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA1) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA2) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_CRC32) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_ATOMICS) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_RDM) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_SHA3) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_SM3) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_SM4) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_DP) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_FHM) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_TS) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_TLB) | \
> -	ARM64_FEATURE_MASK(ID_AA64ISAR0_RNDR) \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_AES) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA1) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA2) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_CRC32) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_ATOMICS) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_RDM) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SHA3) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SM3) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_SM4) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_DP) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_FHM) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_TS) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_TLB) | \
> +	ARM64_FEATURE_MASK(ID_AA64ISAR0_EL1_RNDR) \
>  	)
>  
>  #define PVM_ID_AA64ISAR1_ALLOW (\
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI
  2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
@ 2022-04-21  9:36   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:36 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:24AM +0100, Mark Brown wrote:
> We already use lower case in some defines in sysreg.h, for consistency with
> the architecture definition do so for SCTLR_EL1.nTWE and SCTLR_EL1.nTWI.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

I have no strong feelings either way as to whether we should keep this all caps
or match the architectural CamelCase, so:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> ---
>  arch/arm64/include/asm/sysreg.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 1911f36773e5..f300c49d6281 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -689,8 +689,8 @@
>  #define SCTLR_EL1_UCI		(BIT(26))
>  #define SCTLR_EL1_E0E		(BIT(24))
>  #define SCTLR_EL1_SPAN		(BIT(23))
> -#define SCTLR_EL1_NTWE		(BIT(18))
> -#define SCTLR_EL1_NTWI		(BIT(16))
> +#define SCTLR_EL1_nTWE		(BIT(18))
> +#define SCTLR_EL1_nTWI		(BIT(16))
>  #define SCTLR_EL1_UCT		(BIT(15))
>  #define SCTLR_EL1_DZE		(BIT(14))
>  #define SCTLR_EL1_UMA		(BIT(9))
> @@ -714,7 +714,7 @@
>  #define INIT_SCTLR_EL1_MMU_ON \
>  	(SCTLR_ELx_M    | SCTLR_ELx_C    | SCTLR_ELx_SA   | SCTLR_EL1_SA0   | \
>  	 SCTLR_EL1_SED  | SCTLR_ELx_I    | SCTLR_EL1_DZE  | SCTLR_EL1_UCT   | \
> -	 SCTLR_EL1_NTWE | SCTLR_ELx_IESB | SCTLR_EL1_SPAN | SCTLR_ELx_ITFSB | \
> +	 SCTLR_EL1_nTWE | SCTLR_ELx_IESB | SCTLR_EL1_SPAN | SCTLR_ELx_ITFSB | \
>  	 ENDIAN_SET_EL1 | SCTLR_EL1_UCI  | SCTLR_EL1_EPAN | SCTLR_EL1_RES1)
>  
>  /* MAIR_ELx memory attributes (used by Linux) */
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
@ 2022-04-21  9:47   ` Mark Rutland
  2022-04-21 13:00     ` Mark Brown
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

Hi Mark,

Thanks for picking this up; it's nice to see this moving forward!

On Tue, Apr 19, 2022 at 11:43:25AM +0100, Mark Brown wrote:
> From: Mark Rutland <mark.rutland@arm.com>
> 
> 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                   ARM64_SYSREG_BITMASK(63, 60)
> | #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)

I think this got missed when s/ARM64_SYSREG_BITMASK()/GENMASK_ULL()/ happened.

> | #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
> | #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
> | #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
> | #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)

Just to check, was there a reason for going for ULL() and GENMASK_ULL() rather
than UL() and GENMASK()?

We generally use UL() today, since we treat `unsigned long` as the native
register size.

> 
> 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.

It would be good to see an example of how we'd handle one of those, in case
that means we need to play around with naming or structure of the definitions a
bit.

Regardless, this looks good to me.

Thanks,
Mark.

> 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>
> ---
>  arch/arm64/tools/gen-sysreg.awk | 213 ++++++++++++++++++++++++++++++++
>  arch/arm64/tools/sysreg         |  34 +++++
>  2 files changed, 247 insertions(+)
>  create mode 100755 arch/arm64/tools/gen-sysreg.awk
>  create mode 100644 arch/arm64/tools/sysreg
> 
> diff --git a/arch/arm64/tools/gen-sysreg.awk b/arch/arm64/tools/gen-sysreg.awk
> new file mode 100755
> index 000000000000..4be092372b16
> --- /dev/null
> +++ b/arch/arm64/tools/gen-sysreg.awk
> @@ -0,0 +1,213 @@
> +#!/bin/awk -f
> +# SPDX-License-Identifier: GPL-2.0
> +# gen-sysreg.awk: arm64 sysreg header generator
> +#
> +# Usage: awk -f gen-sysreg.awk sysregs.txt
> +
> +# Log an error and terminate
> +function fatal(msg) {
> +	print "Error at " NR ": " msg > "/dev/stderr"
> +	exit 1
> +}
> +
> +# Sanity check that the start or end of a block makes sense at this point in
> +# the file. If not, produce an error and terminate.
> +#
> +# @this - the $Block or $EndBlock
> +# @prev - the only valid block to already be in (value of @block)
> +# @new - the new value of @block
> +function change_block(this, prev, new) {
> +	if (block != prev)
> +		fatal("unexpected " this " (inside " block ")")
> +
> +	block = new
> +}
> +
> +# Sanity check the number of records for a field makes sense. If not, produce
> +# an error and terminate.
> +function expect_fields(nf) {
> +	if (NF != nf)
> +		fatal(NF " fields found where " nf " expected")
> +}
> +
> +# Print a CPP macro definition, padded with spaces so that the macro bodies
> +# line up in a column
> +function define(name, val) {
> +	printf "%-48s%s\n", "#define " name, val
> +}
> +
> +# Print standard BITMASK/SHIFT/WIDTH CPP definitions for a field
> +function define_field(reg, field, msb, lsb) {
> +	define(reg "_" field, "GENMASK_ULL(" msb ", " lsb ")")
> +	define(reg "_" field "_MASK", "GENMASK_ULL(" msb ", " lsb ")")
> +	define(reg "_" field "_SHIFT", lsb)
> +	define(reg "_" field "_WIDTH", msb - lsb + 1)
> +}
> +
> +# Parse a "<msb>[:<lsb>]" string into the global variables @msb and @lsb
> +function parse_bitdef(reg, field, bitdef, _bits)
> +{
> +	if (bitdef ~ /^[0-9]+$/) {
> +		msb = bitdef
> +		lsb = bitdef
> +	} else if (split(bitdef, _bits, ":") == 2) {
> +		msb = _bits[1]
> +		lsb = _bits[2]
> +	} else {
> +		fatal("invalid bit-range definition '" bitdef "'")
> +	}
> +
> +
> +	if (msb != next_bit)
> +		fatal(reg "." field " starts at " msb " not " next_bit)
> +	if (63 < msb || msb < 0)
> +		fatal(reg "." field " invalid high bit in '" bitdef "'")
> +	if (63 < lsb || lsb < 0)
> +		fatal(reg "." field " invalid low bit in '" bitdef "'")
> +	if (msb < lsb)
> +		fatal(reg "." field " invalid bit-range '" bitdef "'")
> +	if (low > high)
> +		fatal(reg "." field " has invalid range " high "-" low)
> +
> +	next_bit = lsb - 1
> +}
> +
> +BEGIN {
> +	print "#ifndef __ASM_SYSREG_GEN_H"
> +	print "#define __ASM_SYSREG_GEN_H"
> +	print ""
> +	print "/* Generated file - do not edit */"
> +
> +	block = "None"
> +}
> +
> +END {
> +	print "#endif /* __ASM_SYSREG_GEN_H */"
> +}
> +
> +# skip blank lines and comment lines
> +/^$/ { next }
> +/^#/ { next }
> +
> +/^Sysreg/ {
> +	change_block("Sysreg", "None", "Sysreg")
> +	expect_fields(7)
> +
> +	reg = $2
> +	op0 = $3
> +	op1 = $4
> +	crn = $5
> +	crm = $6
> +	op2 = $7
> +
> +	res0 = "UL(0)"
> +	res1 = "UL(0)"
> +
> +	define("REG_" reg, "S" op0 "_" op1 "_C" crn "_C" crm "_" op2)
> +	define("SYS_" reg, "sys_reg(" op0 ", " op1 ", " crn ", " crm ", " op2 ")")
> +
> +	define("SYS_" reg "_Op0", op0)
> +	define("SYS_" reg "_Op1", op1)
> +	define("SYS_" reg "_CRn", crn)
> +	define("SYS_" reg "_CRm", crm)
> +	define("SYS_" reg "_Op2", op2)
> +
> +	print ""
> +
> +	next_bit = 63
> +
> +	next
> +}
> +
> +/^EndSysreg/ {
> +	if (next_bit > 0)
> +		fatal("Unspecified bits in " reg)
> +
> +	change_block("EndSysreg", "Sysreg", "None")
> +
> +	define(reg "_RES0", "(" res0 ")")
> +	define(reg "_RES1", "(" res1 ")")
> +	print ""
> +
> +	reg = null
> +	op0 = null
> +	op1 = null
> +	crn = null
> +	crm = null
> +	op2 = null
> +	res0 = null
> +	res1 = null
> +
> +	next
> +}
> +
> +/^Res0/ && block = "Sysreg" {
> +	expect_fields(2)
> +	parse_bitdef(reg, "RES0", $2)
> +	field = "RES0_" msb "_" lsb
> +
> +	define_field(reg, field, msb, lsb)
> +	print ""
> +
> +	res0 = res0 " | " reg "_" field
> +
> +	next
> +}
> +
> +/^Res1/ && block = "Sysreg" {
> +	expect_fields(2)
> +	parse_bitdef(reg, "RES1", $2)
> +	field = "RES1_" msb "_" lsb
> +
> +	define_field(reg, field, msb, lsb)
> +	print ""
> +
> +	res1 = res1 " | " reg "_" field
> +
> +	next
> +}
> +
> +/^Field/ && block = "Sysreg" {
> +	expect_fields(3)
> +	field = $3
> +	parse_bitdef(reg, field, $2)
> +
> +	define_field(reg, field, msb, lsb)
> +	print ""
> +
> +	next
> +}
> +
> +/^Enum/ {
> +	change_block("Enum", "Sysreg", "Enum")
> +	expect_fields(3)
> +	field = $3
> +	parse_bitdef(reg, field, $2)
> +
> +	define_field(reg, field, msb, lsb)
> +
> +	next
> +}
> +
> +/^EndEnum/ {
> +	change_block("EndEnum", "Enum", "Sysreg")
> +	field = null
> +	msb = null
> +	lsb = null
> +	print ""
> +	next
> +}
> +
> +/0b[01]+/ && block = "Enum" {
> +	expect_fields(2)
> +	val = $1
> +	name = $2
> +
> +	define(reg "_" field "_" name, "ULL(" val ")")
> +	next
> +}
> +
> +# Any lines not handled by previous rules are unexpected
> +{
> +	fatal("unhandled statement")
> +}
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> new file mode 100644
> index 000000000000..3595c68b9a0b
> --- /dev/null
> +++ b/arch/arm64/tools/sysreg
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# System register metadata
> +
> +# Each System register is described by a Sysreg block:
> +
> +# Sysreg 	<name>	<op0> 	<op1>	<crn>	<crm>	<op2>
> +# <field>
> +# ...
> +# EndSysreg
> +
> +# Within a Sysreg block, each field can be described as one of:
> +
> +# Res0	<msb>[:<lsb>]
> +
> +# Res1	<msb>[:<lsb>]
> +
> +# Field	<msb>[:<lsb>]	<name>
> +
> +# Enum	<msb>[:<lsb>]	<name>
> +#	<enumval>	<enumname>
> +#	...
> +# EndEnum
> +
> +# For ID registers we adopt a few conventions for translating the
> +# language in the ARM into defines:
> +#
> +# NI  - Not implemented
> +# IMP - Implemented
> +#
> +# In general it is recommended that new enumeration items be named for the
> +# feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
> +# item ACCDATA) though it may be more taseful to do something else.
> +
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions
  2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
@ 2022-04-21  9:52   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:52 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:26AM +0100, Mark Brown wrote:
> Now that we have a script for generating system registers hook it up to the
> build system similarly to cpucaps. Since we don't currently have any actual
> register information in the input file this should produce no change in the
> built kernel. For ease of review the register information will be converted
> in separate patches.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/Kbuild   | 1 +
>  arch/arm64/include/asm/sysreg.h | 8 ++++++++
>  arch/arm64/tools/Makefile       | 8 +++++++-
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
> index 345fe98605ba..1eac9aa6fa2e 100644
> --- a/arch/arm64/include/asm/Kbuild
> +++ b/arch/arm64/include/asm/Kbuild
> @@ -7,3 +7,4 @@ generic-y += parport.h
>  generic-y += user.h
>  
>  generated-y += cpucaps.h
> +generated-y += sysreg-gen.h
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index f300c49d6281..11bf3636c741 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -114,6 +114,14 @@
>  #define SYS_DC_CSW			sys_insn(1, 0, 7, 10, 2)
>  #define SYS_DC_CISW			sys_insn(1, 0, 7, 14, 2)
>  
> +/*
> + * Automatically generated definitions for system registers, the
> + * manual encodings below are in the process of being converted to
> + * come from here. The header relies on the definition of sys_reg()
> + * earlier in this file.
> + */
> +#include "asm/sysreg-gen.h"

Super trivial, but could we name that something like sysreg-defs.h? The fact
it's generated is implciit in it being placed under include/generated/asm/.

Otherwise, this looks good to me; my only vague concern is that as we add more
sysregs generating the header might take a while (which was a problem for the
atomic scripting, but not for the cpucap generation), so that's somethign to
keep an eye on as we convert more definitions over.

Regardless:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

> +
>  /*
>   * System registers, organised loosely by encoding but grouped together
>   * where the architected name contains an index. e.g. ID_MMFR<n>_EL1.
> diff --git a/arch/arm64/tools/Makefile b/arch/arm64/tools/Makefile
> index cf1307188150..8d2d38858a0d 100644
> --- a/arch/arm64/tools/Makefile
> +++ b/arch/arm64/tools/Makefile
> @@ -3,7 +3,7 @@
>  gen := arch/$(ARCH)/include/generated
>  kapi := $(gen)/asm
>  
> -kapi-hdrs-y := $(kapi)/cpucaps.h
> +kapi-hdrs-y := $(kapi)/cpucaps.h $(kapi)/sysreg-gen.h
>  
>  targets += $(addprefix ../../../, $(kapi-hdrs-y))
>  
> @@ -14,5 +14,11 @@ kapi:   $(kapi-hdrs-y)
>  quiet_cmd_gen_cpucaps = GEN     $@
>        cmd_gen_cpucaps = mkdir -p $(dir $@); $(AWK) -f $(real-prereqs) > $@
>  
> +quiet_cmd_gen_sysreg = GEN     $@
> +      cmd_gen_sysreg = mkdir -p $(dir $@); $(AWK) -f $(real-prereqs) > $@
> +
>  $(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE
>  	$(call if_changed,gen_cpucaps)
> +
> +$(kapi)/sysreg-gen.h: $(src)/gen-sysreg.awk $(src)/sysreg FORCE
> +	$(call if_changed,gen_sysreg)
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1
  2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
@ 2022-04-21  9:58   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:58 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:27AM +0100, Mark Brown wrote:
> Remove the manual definitions for ID_AA64ISAR0_EL1 in favour of automatic
> generation. There should be no functional change. Other notable changes:
> 
>  - 27:24 TME is defined rather than RES0 reflecting DDI0487H.a.

Nice!

>  - 23:20 Atomic is named "atomics" reflecting existing usage.

Can we fix the "Atomic" field to match the architectural name with a
preparatory patch? That'd be a nice cleanup regardless of the scripting, since
the matching name will make it easier to search for in the ARM ARM, and it
looks like that's simple enough that we could get that through now (ahead of
even adding the _EL1 part to the name).

With that additional fix:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/sysreg.h | 20 ----------
>  arch/arm64/tools/sysreg         | 67 +++++++++++++++++++++++++++++++++
>  2 files changed, 67 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 11bf3636c741..2b5cc67b3bc3 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -196,7 +196,6 @@
>  #define SYS_ID_AA64AFR0_EL1		sys_reg(3, 0, 0, 5, 4)
>  #define SYS_ID_AA64AFR1_EL1		sys_reg(3, 0, 0, 5, 5)
>  
> -#define SYS_ID_AA64ISAR0_EL1		sys_reg(3, 0, 0, 6, 0)
>  #define SYS_ID_AA64ISAR1_EL1		sys_reg(3, 0, 0, 6, 1)
>  #define SYS_ID_AA64ISAR2_EL1		sys_reg(3, 0, 0, 6, 2)
>  
> @@ -736,25 +735,6 @@
>  /* Position the attr at the correct index */
>  #define MAIR_ATTRIDX(attr, idx)		((attr) << ((idx) * 8))
>  
> -/* id_aa64isar0 */
> -#define ID_AA64ISAR0_EL1_RNDR_SHIFT		60
> -#define ID_AA64ISAR0_EL1_TLB_SHIFT		56
> -#define ID_AA64ISAR0_EL1_TS_SHIFT		52
> -#define ID_AA64ISAR0_EL1_FHM_SHIFT		48
> -#define ID_AA64ISAR0_EL1_DP_SHIFT		44
> -#define ID_AA64ISAR0_EL1_SM4_SHIFT		40
> -#define ID_AA64ISAR0_EL1_SM3_SHIFT		36
> -#define ID_AA64ISAR0_EL1_SHA3_SHIFT		32
> -#define ID_AA64ISAR0_EL1_RDM_SHIFT		28
> -#define ID_AA64ISAR0_EL1_ATOMICS_SHIFT		20
> -#define ID_AA64ISAR0_EL1_CRC32_SHIFT		16
> -#define ID_AA64ISAR0_EL1_SHA2_SHIFT		12
> -#define ID_AA64ISAR0_EL1_SHA1_SHIFT		8
> -#define ID_AA64ISAR0_EL1_AES_SHIFT		4
> -
> -#define ID_AA64ISAR0_EL1_TLB_RANGE_NI		0x0
> -#define ID_AA64ISAR0_EL1_TLB_RANGE		0x2
> -
>  /* id_aa64isar1 */
>  #define ID_AA64ISAR1_I8MM_SHIFT		52
>  #define ID_AA64ISAR1_DGH_SHIFT		48
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 3595c68b9a0b..040745387528 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -32,3 +32,70 @@
>  # feature that introduces them (eg, FEAT_LS64_ACCDATA introduces enumeration
>  # item ACCDATA) though it may be more taseful to do something else.
>  
> +Sysreg	ID_AA64ISAR0_EL1	3	0	0	6	0
> +Enum	63:60	RNDR
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	59:56	TLB
> +	0b0000	NI
> +	0b0001	OS
> +	0b0010	RANGE
> +EndEnum
> +Enum	55:52	TS
> +	0b0000	NI
> +	0b0001	FLAGM
> +	0b0010	FLAGM2
> +EndEnum
> +Enum	51:48	FHM
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	47:44	DP
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	43:40	SM4
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	39:36	SM3
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	35:32	SHA3
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	31:28	RDM
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	27:24	TME
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	23:20	ATOMICS
> +	0b0000	NI
> +	0b0010	IMP
> +EndEnum
> +Enum	19:16	CRC32
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	15:12	SHA2
> +	0b0000	NI
> +	0b0001	SHA256
> +	0b0010	SHA512
> +EndEnum
> +Enum	11:8	SHA1
> +	0b0000	NI
> +	0b0001	IMP
> +EndEnum
> +Enum	7:4	AES
> +	0b0000	NI
> +	0b0001	AES
> +	0b0010	PMULL
> +EndEnum
> +Res0	3:0
> +EndSysreg
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1
  2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
@ 2022-04-21  9:59   ` Mark Rutland
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Rutland @ 2022-04-21  9:59 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:28AM +0100, Mark Brown wrote:
> Automatically generate definitions for accessing the TTBR0_EL1 registers,
> no functional change.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

> ---
>  arch/arm64/include/asm/sysreg.h |  2 --
>  arch/arm64/tools/sysreg         | 12 ++++++++++++
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 2b5cc67b3bc3..b9023797a5b9 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -212,8 +212,6 @@
>  #define SYS_ZCR_EL1			sys_reg(3, 0, 1, 2, 0)
>  #define SYS_TRFCR_EL1			sys_reg(3, 0, 1, 2, 1)
>  
> -#define SYS_TTBR0_EL1			sys_reg(3, 0, 2, 0, 0)
> -#define SYS_TTBR1_EL1			sys_reg(3, 0, 2, 0, 1)
>  #define SYS_TCR_EL1			sys_reg(3, 0, 2, 0, 2)
>  
>  #define SYS_APIAKEYLO_EL1		sys_reg(3, 0, 2, 1, 0)
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 040745387528..f6195ccbf9b8 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -99,3 +99,15 @@ Enum	7:4	AES
>  EndEnum
>  Res0	3:0
>  EndSysreg
> +
> +Sysreg	TTBR0_EL1	3	0	2	0	0
> +Field	63:48	ASID
> +Field	47:1	BADDR
> +Field	0	CnP
> +EndSysreg
> +
> +Sysreg	TTBR1_EL1	3	0	2	0	1
> +Field	63:48	ASID
> +Field	47:1	BADDR
> +Field	0	CnP
> +EndSysreg
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
  2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
@ 2022-04-21 10:05   ` Mark Rutland
  2022-04-22 12:14     ` Mark Brown
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-21 10:05 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Tue, Apr 19, 2022 at 11:43:29AM +0100, Mark Brown wrote:
> Automatically generate register definitions for SCTLR_EL1. No functional
> change.
> 
> Several fields which are defined in the current revision of DDI0487 but
> which are not yet used by the kernel are left as RES1 in order to ensure
> that the SCTLR_EL1_RES1 mask used for early initialisation of SCTLR_EL1 is
> not changed. These are LSMAOE, nTLSMD, EIS, TSCXT and EOS.

I think that going forward we'll hit similar issues when adding new fields, so
we probably want to distinguish "architecturally RESx" and "The kernel wants to
treat these as RESx".

I suspect we should add those fields to the scripting, but (manually) add a
definition to a header with both the architectural RES1 bits and the bits we're
treating as RES1 even though they're now been allocated a purpose.

I'm not sure how to name that clearly, though.

Otherwise, this looks good to me.

Thanks,
Mark.

> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/sysreg.h | 29 --------------
>  arch/arm64/tools/sysreg         | 70 +++++++++++++++++++++++++++++++++
>  2 files changed, 70 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index b9023797a5b9..63b545260e62 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -203,7 +203,6 @@
>  #define SYS_ID_AA64MMFR1_EL1		sys_reg(3, 0, 0, 7, 1)
>  #define SYS_ID_AA64MMFR2_EL1		sys_reg(3, 0, 0, 7, 2)
>  
> -#define SYS_SCTLR_EL1			sys_reg(3, 0, 1, 0, 0)
>  #define SYS_ACTLR_EL1			sys_reg(3, 0, 1, 0, 1)
>  #define SYS_CPACR_EL1			sys_reg(3, 0, 1, 0, 2)
>  #define SYS_RGSR_EL1			sys_reg(3, 0, 1, 0, 5)
> @@ -679,34 +678,6 @@
>  	(SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
>  
>  /* SCTLR_EL1 specific flags. */
> -#define SCTLR_EL1_EPAN		(BIT(57))
> -#define SCTLR_EL1_ATA0		(BIT(42))
> -
> -#define SCTLR_EL1_TCF0_SHIFT	38
> -#define SCTLR_EL1_TCF0_NONE	UL(0x0)
> -#define SCTLR_EL1_TCF0_SYNC	UL(0x1)
> -#define SCTLR_EL1_TCF0_ASYNC	UL(0x2)
> -#define SCTLR_EL1_TCF0_ASYMM	UL(0x3)
> -#define SCTLR_EL1_TCF0_MASK	(UL(0x3) << SCTLR_EL1_TCF0_SHIFT)
> -
> -#define SCTLR_EL1_BT1		(BIT(36))
> -#define SCTLR_EL1_BT0		(BIT(35))
> -#define SCTLR_EL1_UCI		(BIT(26))
> -#define SCTLR_EL1_E0E		(BIT(24))
> -#define SCTLR_EL1_SPAN		(BIT(23))
> -#define SCTLR_EL1_nTWE		(BIT(18))
> -#define SCTLR_EL1_nTWI		(BIT(16))
> -#define SCTLR_EL1_UCT		(BIT(15))
> -#define SCTLR_EL1_DZE		(BIT(14))
> -#define SCTLR_EL1_UMA		(BIT(9))
> -#define SCTLR_EL1_SED		(BIT(8))
> -#define SCTLR_EL1_ITD		(BIT(7))
> -#define SCTLR_EL1_CP15BEN	(BIT(5))
> -#define SCTLR_EL1_SA0		(BIT(4))
> -
> -#define SCTLR_EL1_RES1	((BIT(11)) | (BIT(20)) | (BIT(22)) | (BIT(28)) | \
> -			 (BIT(29)))
> -
>  #ifdef CONFIG_CPU_BIG_ENDIAN
>  #define ENDIAN_SET_EL1		(SCTLR_EL1_E0E | SCTLR_ELx_EE)
>  #else
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index f6195ccbf9b8..6248cfbf5288 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -100,6 +100,76 @@ EndEnum
>  Res0	3:0
>  EndSysreg
>  
> +Sysreg	SCTLR_EL1	3	0	1	9	9
> +Field	63	TIDCP
> +Field	62	SPINMASK
> +Field	61	NMI
> +Field	60	EnTP2
> +Res0	59:58
> +Field	57	EPAN
> +Field	56	EnALS
> +Field	55	EnAS0
> +Field	54	EnASR
> +Field	53	TME
> +Field	52	TME0
> +Field	51	TMT
> +Field	50	TMT0
> +Field	49:46	TWEDEL
> +Field	45	TWEDEn
> +Field	44	DSSBS
> +Field	43	ATA
> +Field	42	ATA0
> +Enum	41:40	TCF
> +	0b00	NONE
> +	0b01	SYNC
> +	0b10	ASYNC
> +	0b11	ASYMM
> +EndEnum
> +Enum	39:38	TCF0
> +	0b00	NONE
> +	0b01	SYNC
> +	0b10	ASYNC
> +	0b11	ASYMM
> +EndEnum
> +Field	37	ITFSB
> +Field	36	BT1
> +Field	35	BT0
> +Res0	34
> +Field	33	MSCEn
> +Field	32	CMOW
> +Field	31	EnIA
> +Field	30	EnIB
> +Res1	29:28
> +Field	27	EnDA
> +Field	26	UCI
> +Field	25	EE
> +Field	24	E0E
> +Field	23	SPAN
> +Res1	22
> +Field	21	IESB
> +Res1	20
> +Field	19	WXN
> +Field	18	nTWE
> +Res0	17
> +Field	16	nTWI
> +Field	15	UCT
> +Field	14	DZE
> +Field	13	EnDB
> +Field	12	I
> +Res1	11
> +Field	10	EnRCTX
> +Field	9	UMA
> +Field	8	SED
> +Field	7	ITD
> +Field	6	nAA
> +Field	5	CP15BEN
> +Field	4	SA0
> +Field	3	SA
> +Field	2	C
> +Field	1	A
> +Field	0	M
> +EndSysreg
> +
>  Sysreg	TTBR0_EL1	3	0	2	0	0
>  Field	63:48	ASID
>  Field	47:1	BADDR
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 0/8] arm64: Automatic system register definition generation
  2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
                   ` (7 preceding siblings ...)
  2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
@ 2022-04-21 10:15 ` Mark Rutland
  2022-04-21 15:14   ` Mark Brown
  8 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-21 10:15 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

Hi Mark,

I'm obviously in favour of this series. Overall I think the general approach
looks good, and I've commented on the bits I'm not sure about.

The only things that I'm really not sure about is what we do for registers
whose structure changes, or where a register has multiple names (like some
GICv3 ICV regs), and it would be nice if we could see an example of those.

Otherwise, I think we just need to agree upon the naming/structure we want to
generate. With that we can do some preparatory renaming (and any strucutral
changes for things like shifts) ahead of a bulk conversion to generated
definitions.

Does that sound about right to you, or is there any concern that I've missed
that we should consider?

Thanks,
Mark.

On Tue, Apr 19, 2022 at 11:43:21AM +0100, Mark Brown wrote:
> 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 series introduces a
> script which describes registers and the fields within them in a format
> that is easy to cross reference with the architecture reference manual
> and uses them to generate the constants we use in a standard format:
> 
> | #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                   ARM64_SYSREG_BITMASK(63, 60)
> | #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)
> | #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
> | #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
> | #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
> | #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)
> 
> This should be particularly useful for the ID registers where we will be
> able to specify just the register and field for more of the bitfield
> information, simplifying ARM64_FTR_BITS() and providing helpers for use
> in struct arm64_cpu_capabilities or for hwcaps.
> 
> 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 could also be extended to cover more
> information such as the FTR_SIGNED/FTR_UNSIGNED distinction. There is
> also currently no support for registers which change layout at runtime,
> for example based on virtualisation settings - these could be manually
> handled for the time being, or the script extended.
> 
> At the present time (especially given how near we are to the merge
> window) this is as much about getting feedback on the general approach
> and how to move forward if we want to move forward. Rather than
> attempting to convert every register at once the current series converts
> a few sample registers to provide some concrete examples but allow for
> easier updating during review of the file format and the script.
> Handling a register at a time should also make review less taxing so it
> seems like a sensible approach in general.
> 
> The generation script was originally written by Mark Rutland and
> subsequently improved and integrated into the kernel build by me.
> 
> v4:
>  - Rebase onto v5.18-rc3.
> v3:
>  - Rebase onto v5.18-rc1.
> v2:
>  - Fix issue with building bounds.s in an O= build by renaming the
>    generated header.
> 
> Mark Brown (7):
>   arm64/mte: Move shift from definition of TCF0 enumeration values
>   arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names
>   arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI
>   arm64/sysreg: Enable automatic generation of system register
>     definitions
>   arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1
>   arm64/sysreg: Generate definitions for TTBRn_EL1
>   arm64/sysreg: Generate definitions for SCTLR_EL1
> 
> Mark Rutland (1):
>   arm64: Add sysreg header generation scripting
> 
>  arch/arm64/include/asm/Kbuild                 |   1 +
>  arch/arm64/include/asm/archrandom.h           |   2 +-
>  arch/arm64/include/asm/sysreg.h               |  61 +----
>  arch/arm64/kernel/cpufeature.c                |  70 +++---
>  arch/arm64/kernel/mte.c                       |   6 +-
>  .../arm64/kvm/hyp/include/nvhe/fixed_config.h |  28 +--
>  arch/arm64/tools/Makefile                     |   8 +-
>  arch/arm64/tools/gen-sysreg.awk               | 213 ++++++++++++++++++
>  arch/arm64/tools/sysreg                       | 183 +++++++++++++++
>  9 files changed, 466 insertions(+), 106 deletions(-)
>  create mode 100755 arch/arm64/tools/gen-sysreg.awk
>  create mode 100644 arch/arm64/tools/sysreg
> 
> 
> base-commit: b2d229d4ddb17db541098b83524d901257e93845
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-21  9:47   ` Mark Rutland
@ 2022-04-21 13:00     ` Mark Brown
  2022-04-21 14:16       ` Mark Rutland
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-21 13:00 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1884 bytes --]

On Thu, Apr 21, 2022 at 10:47:42AM +0100, Mark Rutland wrote:
> On Tue, Apr 19, 2022 at 11:43:25AM +0100, Mark Brown wrote:

> > | #define ID_AA64ISAR0_EL1_RNDR                   ARM64_SYSREG_BITMASK(63, 60)
> > | #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)

> I think this got missed when s/ARM64_SYSREG_BITMASK()/GENMASK_ULL()/ happened.

Yes.

> > | #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
> > | #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
> > | #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
> > | #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)

> Just to check, was there a reason for going for ULL() and GENMASK_ULL() rather
> than UL() and GENMASK()?

> We generally use UL() today, since we treat `unsigned long` as the native
> register size.

That's not been updated from what you originally had had, I think I'd
just been under the impression that there was a good reason for it that
wasn't apparent to me.

> > 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.

> It would be good to see an example of how we'd handle one of those, in case
> that means we need to play around with naming or structure of the definitions a
> bit.

My thinking here was that we might not want to handle those registers
through the automated stuff at all.  I haven't yet come up with
something that seems tasteful and viable for them, if I had a firm idea
for what that should look like I'd probably have implemented it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-21 13:00     ` Mark Brown
@ 2022-04-21 14:16       ` Mark Rutland
  2022-04-21 14:50         ` Mark Brown
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-21 14:16 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Thu, Apr 21, 2022 at 02:00:17PM +0100, Mark Brown wrote:
> On Thu, Apr 21, 2022 at 10:47:42AM +0100, Mark Rutland wrote:
> > On Tue, Apr 19, 2022 at 11:43:25AM +0100, Mark Brown wrote:
> 
> > > | #define ID_AA64ISAR0_EL1_RNDR                   ARM64_SYSREG_BITMASK(63, 60)
> > > | #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)
> 
> > I think this got missed when s/ARM64_SYSREG_BITMASK()/GENMASK_ULL()/ happened.
> 
> Yes.
> 
> > > | #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
> > > | #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
> > > | #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
> > > | #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)
> 
> > Just to check, was there a reason for going for ULL() and GENMASK_ULL() rather
> > than UL() and GENMASK()?
> 
> > We generally use UL() today, since we treat `unsigned long` as the native
> > register size.
> 
> That's not been updated from what you originally had had

I think it was? The version in my arm64/sysreg-scripting branch doesn't
use either UL() or ULL(), and its example has:

| #define ID_AA64ISAR1_EL1_I8MM                   BITMASK(55, 52)
| #define ID_AA64ISAR1_EL1_I8MM_SHIFT             52
| #define ID_AA64ISAR1_EL1_I8MM_WIDTH             4
| #define ID_AA64ISAR1_EL1_I8MM_NI                0b0000
| #define ID_AA64ISAR1_EL1_I8MM_SUPPORTED         0b0001

> , I think I'd just been under the impression that there was a good
> reason for it that wasn't apparent to me.

FWIW, I have no strong opinion either way, so I'm happy for that to stay
as ULL and GENMASK_ULL(); I just wanted to check if there was a
rationale I'd missed.

> > > 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.
> 
> > It would be good to see an example of how we'd handle one of those, in case
> > that means we need to play around with naming or structure of the definitions a
> > bit.
> 
> My thinking here was that we might not want to handle those registers
> through the automated stuff at all.  I haven't yet come up with
> something that seems tasteful and viable for them, if I had a firm idea
> for what that should look like I'd probably have implemented it.

Sure, and I'm not expecting that we automate all of that, just that we
have an idea of how the manual bits would work with the automatic bits.
If the odd cases looks simple enough, we might be able to get away with
a couple of small additions to the scripting.

For example, for ESR_EL{1,2,3} today we define ESR_ELx_field
definitions rather than duplicate ESR_EL1_field / ESR_EL2_field /
ESR_EL3_field definitions. If the scripting has a mechanism to handle
that, then that might be good enough for the other odd cases.

For example, I think we could do something like:

# Define a set of fields without a specific register encoding, using the
# name `ESR_ELx`
SysregFields	ESR_ELx
	Res0	63:37
	Field	36:32	ISS2
	Field	31:26	EC
	Field	25	IL
	Field	24:0	ISS
EndSysregFields

# This could instead be SysregEncoding
Sysreg	ESR_EL1		3	0	5	2	0
	Comment		"See ESR_ELx for fields"
	# Don't create any field definitions for this reg, and don't
	# bother with the associated sanity checks
	NoFields	
EndSysreg

Sysreg	ESR_EL2		3	4	5	2	0
	Comment		"See ESR_ELx for fields"
	NoFields
EndSysreg

Sysreg	ESR_EL12	3	5	5	2	0
	Comment		"See ESR_ELx for fields"
	NoFields
EndSysreg

... and the `SysregFields` `NoFields`, and `Comment` mechanisms might be
good enough to cover the other odd cases we have (e.g. aliased
GIC registers, or different "views" for the same register).

Does that make sense, or have I misunderstood the point you were making?

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-21 14:16       ` Mark Rutland
@ 2022-04-21 14:50         ` Mark Brown
  2022-04-21 15:35           ` Mark Rutland
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-21 14:50 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 3437 bytes --]

On Thu, Apr 21, 2022 at 03:16:52PM +0100, Mark Rutland wrote:
> On Thu, Apr 21, 2022 at 02:00:17PM +0100, Mark Brown wrote:

> > > > 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.

> > > It would be good to see an example of how we'd handle one of those, in case
> > > that means we need to play around with naming or structure of the definitions a
> > > bit.

> > My thinking here was that we might not want to handle those registers
> > through the automated stuff at all.  I haven't yet come up with
> > something that seems tasteful and viable for them, if I had a firm idea
> > for what that should look like I'd probably have implemented it.

> Sure, and I'm not expecting that we automate all of that, just that we
> have an idea of how the manual bits would work with the automatic bits.
> If the odd cases looks simple enough, we might be able to get away with
> a couple of small additions to the scripting.

> For example, for ESR_EL{1,2,3} today we define ESR_ELx_field
> definitions rather than duplicate ESR_EL1_field / ESR_EL2_field /
> ESR_EL3_field definitions. If the scripting has a mechanism to handle
> that, then that might be good enough for the other odd cases.

Ah, that's a separate issue to the registers which change layout which
was what was being mentioned above.

> For example, I think we could do something like:

> # Define a set of fields without a specific register encoding, using the
> # name `ESR_ELx`
> SysregFields	ESR_ELx
> 	Res0	63:37
> 	Field	36:32	ISS2
> 	Field	31:26	EC
> 	Field	25	IL
> 	Field	24:0	ISS
> EndSysregFields

Yes, I'd been thinking of something like this - it seemed an obvious
enough extension.

> # This could instead be SysregEncoding
> Sysreg	ESR_EL1		3	0	5	2	0
> 	Comment		"See ESR_ELx for fields"
> 	# Don't create any field definitions for this reg, and don't
> 	# bother with the associated sanity checks
> 	NoFields	
> EndSysreg

I think we're going to end up wanting to still generate the numbered
versions for use in macros so we should probably have that comment and
NoFields be a SharedLayout (or whatever bikeshedded name) statement.
Until we need it that can just be equivalent to a comment, ready to kick
in once someone needs it.  I can update the existing (trivial but meh)
TTBRn register conversion to do that.

> ... and the `SysregFields` `NoFields`, and `Comment` mechanisms might be
> good enough to cover the other odd cases we have (e.g. aliased
> GIC registers, or different "views" for the same register).

> Does that make sense, or have I misunderstood the point you were making?

I was talking about a completely different issue, things like CPTR_EL2
where the register layout changes depending on some runtime
configuration.  You'd need two separate register layouts within a single
Sysreg which isn't too bad until you get to the point of having to name
things like RES0/RES1 and any name collisons in fields (I don't *think*
we have name collisons...).

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 0/8] arm64: Automatic system register definition generation
  2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
@ 2022-04-21 15:14   ` Mark Brown
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-04-21 15:14 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]

On Thu, Apr 21, 2022 at 11:15:24AM +0100, Mark Rutland wrote:

> The only things that I'm really not sure about is what we do for registers
> whose structure changes, or where a register has multiple names (like some
> GICv3 ICV regs), and it would be nice if we could see an example of those.

I replied elsewhere about the structure changing registers - I think the
general shape of what to do is relatively obvious there, how concretely
to achieve that is more of an issue.  For multiple names I think that's
something that we should just treat it as sharing the same layout and
punt to higher levels to work out that it's actually the same underlying
register, that seems like a higher level issue.

> Otherwise, I think we just need to agree upon the naming/structure we want to
> generate. With that we can do some preparatory renaming (and any strucutral
> changes for things like shifts) ahead of a bulk conversion to generated
> definitions.

Hopefully there's enough examples in this subset for the naming and
structure if people agree to it.  I was thinking it would be more
digestable to go through in small groups of registers rather than try to
do a bulk conversion - there's a lot of registers and probably going to
be a fair number of preparatory changes needed which could easily add up
to be a lot to digest in one sitting, which will be magnified for
resends.

> Does that sound about right to you, or is there any concern that I've missed
> that we should consider?

I think that about covers it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-21 14:50         ` Mark Brown
@ 2022-04-21 15:35           ` Mark Rutland
  2022-04-21 15:46             ` Mark Brown
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-21 15:35 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Thu, Apr 21, 2022 at 03:50:41PM +0100, Mark Brown wrote:
> On Thu, Apr 21, 2022 at 03:16:52PM +0100, Mark Rutland wrote:
> > On Thu, Apr 21, 2022 at 02:00:17PM +0100, Mark Brown wrote:
> 
> > > > > 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.
> 
> > > > It would be good to see an example of how we'd handle one of those, in case
> > > > that means we need to play around with naming or structure of the definitions a
> > > > bit.
> 
> > > My thinking here was that we might not want to handle those registers
> > > through the automated stuff at all.  I haven't yet come up with
> > > something that seems tasteful and viable for them, if I had a firm idea
> > > for what that should look like I'd probably have implemented it.
> 
> > Sure, and I'm not expecting that we automate all of that, just that we
> > have an idea of how the manual bits would work with the automatic bits.
> > If the odd cases looks simple enough, we might be able to get away with
> > a couple of small additions to the scripting.
> 
> > For example, for ESR_EL{1,2,3} today we define ESR_ELx_field
> > definitions rather than duplicate ESR_EL1_field / ESR_EL2_field /
> > ESR_EL3_field definitions. If the scripting has a mechanism to handle
> > that, then that might be good enough for the other odd cases.
> 
> Ah, that's a separate issue to the registers which change layout which
> was what was being mentioned above.

Sure; what I was getting at is that the same mechanism might help there
too -- see below.

> > For example, I think we could do something like:
> 
> > # Define a set of fields without a specific register encoding, using the
> > # name `ESR_ELx`
> > SysregFields	ESR_ELx
> > 	Res0	63:37
> > 	Field	36:32	ISS2
> > 	Field	31:26	EC
> > 	Field	25	IL
> > 	Field	24:0	ISS
> > EndSysregFields
> 
> Yes, I'd been thinking of something like this - it seemed an obvious
> enough extension.
> 
> > # This could instead be SysregEncoding
> > Sysreg	ESR_EL1		3	0	5	2	0
> > 	Comment		"See ESR_ELx for fields"
> > 	# Don't create any field definitions for this reg, and don't
> > 	# bother with the associated sanity checks
> > 	NoFields	
> > EndSysreg
> 
> I think we're going to end up wanting to still generate the numbered
> versions for use in macros so we should probably have that comment and
> NoFields be a SharedLayout (or whatever bikeshedded name) statement.

That's fair. My point was just that we *don't* do that today for ESR_ELx
and having this might simplify the conversion and/or avoid repetition.

Naming wise I'm fine with NoFields/SharedLayout/WhateverYouWant, and
structurally I'm fine with doing other things, I just think we need to
have an idea of what our get-out-of-jail-free-card looks like.

> Until we need it that can just be equivalent to a comment, ready to kick
> in once someone needs it.  I can update the existing (trivial but meh)
> TTBRn register conversion to do that.

FWIW, I'm happy either way (i.e. TTBRn to staty as-is, or be converted),
given the duplication is trivial.

> > ... and the `SysregFields` `NoFields`, and `Comment` mechanisms might be
> > good enough to cover the other odd cases we have (e.g. aliased
> > GIC registers, or different "views" for the same register).
> 
> > Does that make sense, or have I misunderstood the point you were making?
> 
> I was talking about a completely different issue, things like CPTR_EL2
> where the register layout changes depending on some runtime
> configuration.  You'd need two separate register layouts within a single
> Sysreg which isn't too bad until you get to the point of having to name
> things like RES0/RES1 and any name collisons in fields (I don't *think*
> we have name collisons...).

I understood that was a distinct problem; what I was suggesting is the
same mechanism might help there, as e.g. it would allow us to do:

	# Creates CPTR_EL2__E2H1_RES0, etc
	SysregFields	CPTR_EL2__E2H1
		Comment	"CPTR_EL2 layout when HCR_EL2.E2H == 1"
		...
	EndSysregFields

	# Creates CPTR_EL2__E2H0_RES0, etc
	SysregFields	CPTR_EL2__E2H0
		Comment	"CPTR_EL2 layout when HCR_EL2.E2H == 0"
		...
	EndSysregFields

	# Doesn't create CPTR_EL2_RES0, etc
	Sysreg	CPTR_EL2	3	0	1	0	2
		Comment "See CPTR_EL2__E2H1_* and CPTR_EL2__E2H0_*"
		NoFields
	EndSysreg


... or where we have two names for the same register encoding (which is
really silly, but does exist):

	Sysreg	ICV_EOIR0_EL1	3	0	12	8	1
		Comment	"See ICx_EOIR0_EL1_*"
		NoFields
	EndSysreg

	Sysreg	ICH_EOIR0_EL1	3	0	12	8	1
		Comment	"See ICx_EOIR0_EL1_*"
		NoFields
	EndSysreg

	SysregFields	ICx_EOIR0_EL1
		Comment	"Shared layout for ICV_EOIR0_EL1 and ICH_EOIR0_EL1"
		Res0	63:24
		Field	23:0	INTID
	EndSysregFields

I can believe there are problems with that, and/or maybe it's too ugly.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 4/8] arm64: Add sysreg header generation scripting
  2022-04-21 15:35           ` Mark Rutland
@ 2022-04-21 15:46             ` Mark Brown
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-04-21 15:46 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 2514 bytes --]

On Thu, Apr 21, 2022 at 04:35:14PM +0100, Mark Rutland wrote:
> On Thu, Apr 21, 2022 at 03:50:41PM +0100, Mark Brown wrote:

> > Until we need it that can just be equivalent to a comment, ready to kick
> > in once someone needs it.  I can update the existing (trivial but meh)
> > TTBRn register conversion to do that.

> FWIW, I'm happy either way (i.e. TTBRn to staty as-is, or be converted),
> given the duplication is trivial.

Yes, I don't think it's particularly *useful* to do this for TTBRn, but
it does demonstrate the mechanism which can then be applied to other
more interesting registers.

> > I was talking about a completely different issue, things like CPTR_EL2
> > where the register layout changes depending on some runtime
> > configuration.  You'd need two separate register layouts within a single
> > Sysreg which isn't too bad until you get to the point of having to name
> > things like RES0/RES1 and any name collisons in fields (I don't *think*
> > we have name collisons...).

> I understood that was a distinct problem; what I was suggesting is the
> same mechanism might help there, as e.g. it would allow us to do:

> 	# Creates CPTR_EL2__E2H1_RES0, etc
> 	SysregFields	CPTR_EL2__E2H1
> 		Comment	"CPTR_EL2 layout when HCR_EL2.E2H == 1"
> 		...
> 	EndSysregFields

...

> ... or where we have two names for the same register encoding (which is
> really silly, but does exist):

Right, that'd work but it has the disadvantage that we can't then
blindly use CPTR_EL2_ZEN_MASK or whatever.  That might be fine, it's a
small number of registers and could help someone spot being in the wrong
mode, but perhaps not.  The alternative is to teach the script about
multiple layouts for a single register.  I don't have a particularly
strong opinion there, and I think it's reasonable to punt until
converting the affected registers so people can look at concrete
suggestions and their impact on the relevant code.

> 	Sysreg	ICV_EOIR0_EL1	3	0	12	8	1
> 		Comment	"See ICx_EOIR0_EL1_*"
> 		NoFields
> 	EndSysreg
> 
> 	Sysreg	ICH_EOIR0_EL1	3	0	12	8	1
> 		Comment	"See ICx_EOIR0_EL1_*"
> 		NoFields
> 	EndSysreg
> 
> 	SysregFields	ICx_EOIR0_EL1
> 		Comment	"Shared layout for ICV_EOIR0_EL1 and ICH_EOIR0_EL1"
> 		Res0	63:24
> 		Field	23:0	INTID
> 	EndSysregFields

> I can believe there are problems with that, and/or maybe it's too ugly.

TBH that seems fine to me, at the level of generating the defines it's
just a shared layout.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
  2022-04-21 10:05   ` Mark Rutland
@ 2022-04-22 12:14     ` Mark Brown
  2022-04-22 13:42       ` Mark Rutland
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Brown @ 2022-04-22 12:14 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1299 bytes --]

On Thu, Apr 21, 2022 at 11:05:27AM +0100, Mark Rutland wrote:
> On Tue, Apr 19, 2022 at 11:43:29AM +0100, Mark Brown wrote:

> > Several fields which are defined in the current revision of DDI0487 but
> > which are not yet used by the kernel are left as RES1 in order to ensure
> > that the SCTLR_EL1_RES1 mask used for early initialisation of SCTLR_EL1 is
> > not changed. These are LSMAOE, nTLSMD, EIS, TSCXT and EOS.

> I think that going forward we'll hit similar issues when adding new fields, so
> we probably want to distinguish "architecturally RESx" and "The kernel wants to
> treat these as RESx".

> I suspect we should add those fields to the scripting, but (manually) add a
> definition to a header with both the architectural RES1 bits and the bits we're
> treating as RES1 even though they're now been allocated a purpose.

> I'm not sure how to name that clearly, though.

I think I'd come to a similar conclusion but as you say the naming is
annoying and in cases like these ones there's so few users and they're
oring in other bits so it might be more sensible to just or in these now
defined RES1 bits in the user, skipping out on the naming question
entirely - in this case the usage is in INIT_SCTLR_EL2_MMU_*.  Looking
at it again now I'm inclined to go that way for this one.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
  2022-04-22 12:14     ` Mark Brown
@ 2022-04-22 13:42       ` Mark Rutland
  2022-04-22 13:50         ` Mark Brown
  0 siblings, 1 reply; 27+ messages in thread
From: Mark Rutland @ 2022-04-22 13:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel

On Fri, Apr 22, 2022 at 01:14:51PM +0100, Mark Brown wrote:
> On Thu, Apr 21, 2022 at 11:05:27AM +0100, Mark Rutland wrote:
> > On Tue, Apr 19, 2022 at 11:43:29AM +0100, Mark Brown wrote:
> 
> > > Several fields which are defined in the current revision of DDI0487 but
> > > which are not yet used by the kernel are left as RES1 in order to ensure
> > > that the SCTLR_EL1_RES1 mask used for early initialisation of SCTLR_EL1 is
> > > not changed. These are LSMAOE, nTLSMD, EIS, TSCXT and EOS.
> 
> > I think that going forward we'll hit similar issues when adding new fields, so
> > we probably want to distinguish "architecturally RESx" and "The kernel wants to
> > treat these as RESx".
> 
> > I suspect we should add those fields to the scripting, but (manually) add a
> > definition to a header with both the architectural RES1 bits and the bits we're
> > treating as RES1 even though they're now been allocated a purpose.
> 
> > I'm not sure how to name that clearly, though.
> 
> I think I'd come to a similar conclusion but as you say the naming is
> annoying and in cases like these ones there's so few users and they're
> oring in other bits so it might be more sensible to just or in these now
> defined RES1 bits in the user, skipping out on the naming question
> entirely - in this case the usage is in INIT_SCTLR_EL2_MMU_*.  Looking
> at it again now I'm inclined to go that way for this one.

FWIW, I'm perfectly happy with adding those bits explicitly in the
`INIT_SCTLR_EL*` definitions. The key thing I wanted is that as a
policy, `<regname>_RES1` is purely the architecturally RES1 bits.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1
  2022-04-22 13:42       ` Mark Rutland
@ 2022-04-22 13:50         ` Mark Brown
  0 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-04-22 13:50 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Suzuki K Poulose,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 973 bytes --]

On Fri, Apr 22, 2022 at 02:42:30PM +0100, Mark Rutland wrote:
> On Fri, Apr 22, 2022 at 01:14:51PM +0100, Mark Brown wrote:

> > I think I'd come to a similar conclusion but as you say the naming is
> > annoying and in cases like these ones there's so few users and they're
> > oring in other bits so it might be more sensible to just or in these now
> > defined RES1 bits in the user, skipping out on the naming question
> > entirely - in this case the usage is in INIT_SCTLR_EL2_MMU_*.  Looking
> > at it again now I'm inclined to go that way for this one.

> FWIW, I'm perfectly happy with adding those bits explicitly in the
> `INIT_SCTLR_EL*` definitions. The key thing I wanted is that as a
> policy, `<regname>_RES1` is purely the architecturally RES1 bits.

Yes, I agree on that policy - I just happened to refer to an older
version of the architecture in an attempt to avoid this series getting
caught up on the discussion about where exactly to account for them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2022-04-22 13:51 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
2022-04-21  9:33   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
2022-04-21  9:35   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
2022-04-21  9:36   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
2022-04-21  9:47   ` Mark Rutland
2022-04-21 13:00     ` Mark Brown
2022-04-21 14:16       ` Mark Rutland
2022-04-21 14:50         ` Mark Brown
2022-04-21 15:35           ` Mark Rutland
2022-04-21 15:46             ` Mark Brown
2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
2022-04-21  9:52   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
2022-04-21  9:58   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
2022-04-21  9:59   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
2022-04-21 10:05   ` Mark Rutland
2022-04-22 12:14     ` Mark Brown
2022-04-22 13:42       ` Mark Rutland
2022-04-22 13:50         ` Mark Brown
2022-04-21 10:15 ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Rutland
2022-04-21 15:14   ` Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.