All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Mark Brown <broonie@kernel.org>
Subject: [PATCH v1 01/12] arm64/fp: Make SVE and SME length register definition match architecture
Date: Tue, 10 May 2022 17:11:57 +0100	[thread overview]
Message-ID: <20220510161208.631259-2-broonie@kernel.org> (raw)
In-Reply-To: <20220510161208.631259-1-broonie@kernel.org>

Currently (as of DDI0487H.a) the architecture defines the vector length
control field in ZCR and SMCR as being 4 bits wide with an additional 5
bits reserved above it marked as RAZ/WI for future expansion. The kernel
currently attempts to anticipate such expansion by treating these extra
bits as part of the LEN field but this will be inconvenient when we start
generating the defines and would cause problems in the event that the
architecture goes a different direction with these fields. Let's instead
change the defines to reflect the currently defined architecture, we can
update in future as needed.

No change in behaviour should be seen in any system, even emulated systems
using the maximum allowed vector length for the current architecture.

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

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 422741ca5631..4d78b6aeebb4 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -1113,26 +1113,16 @@
 #define DCZID_DZP_SHIFT			4
 #define DCZID_BS_SHIFT			0
 
-/*
- * The ZCR_ELx_LEN_* definitions intentionally include bits [8:4] which
- * are reserved by the SVE architecture for future expansion of the LEN
- * field, with compatible semantics.
- */
 #define ZCR_ELx_LEN_SHIFT	0
-#define ZCR_ELx_LEN_SIZE	9
-#define ZCR_ELx_LEN_MASK	0x1ff
+#define ZCR_ELx_LEN_SIZE	4
+#define ZCR_ELx_LEN_MASK	0xf
 
 #define SMCR_ELx_FA64_SHIFT	31
 #define SMCR_ELx_FA64_MASK	(1 << SMCR_ELx_FA64_SHIFT)
 
-/*
- * The SMCR_ELx_LEN_* definitions intentionally include bits [8:4] which
- * are reserved by the SME architecture for future expansion of the LEN
- * field, with compatible semantics.
- */
 #define SMCR_ELx_LEN_SHIFT	0
-#define SMCR_ELx_LEN_SIZE	9
-#define SMCR_ELx_LEN_MASK	0x1ff
+#define SMCR_ELx_LEN_SIZE	4
+#define SMCR_ELx_LEN_MASK	0xf
 
 #define CPACR_EL1_FPEN_EL1EN	(BIT(20)) /* enable EL1 access */
 #define CPACR_EL1_FPEN_EL0EN	(BIT(21)) /* enable EL0 access, if EL1EN set */
-- 
2.30.2


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

  reply	other threads:[~2022-05-10 16:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 16:11 [PATCH v1 00/12] arm64/fp: Generate definitons for floating point system registers Mark Brown
2022-05-10 16:11 ` Mark Brown [this message]
2022-05-10 16:11 ` [PATCH v1 02/12] arm64/fp: Rename SVE and SME LEN field name to _WIDTH Mark Brown
2022-05-10 16:11 ` [PATCH v1 03/12] arm64/sme: Drop SYS_ from SMIDR_EL1 defines Mark Brown
2022-05-10 16:12 ` [PATCH v1 04/12] arm64/sme: Standardise bitfield names for SVCR Mark Brown
2022-05-10 16:12 ` [PATCH v1 05/12] arm64/sme: Remove _EL0 from name of SVCR - FIXME sysreg.h Mark Brown
2022-05-13 14:16   ` Mark Rutland
2022-05-13 19:39     ` Mark Brown
2022-05-10 16:12 ` [PATCH v1 06/12] arm64/sysreg: Support generation of RAZ fields Mark Brown
2022-05-13 14:18   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 07/12] arm64/sme: Automatically generate defines for SMCR Mark Brown
2022-05-13 14:31   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 08/12] arm64/sme: Automatically generate SMIDR_EL1 defines Mark Brown
2022-05-13 14:35   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 09/12] arm64/sme: Automatically generate SMPRIMAP_EL2 definitions Mark Brown
2022-05-13 14:38   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 10/12] arm64/sme: Generate SMPRI_EL1 definitions Mark Brown
2022-05-13 14:39   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 11/12] arm64/sme: Generate defintions for SVCR Mark Brown
2022-05-13 14:41   ` Mark Rutland
2022-05-10 16:12 ` [PATCH v1 12/12] arm64/sve: Generate ZCR definitions Mark Brown
2022-05-13 14:46   ` Mark Rutland
2022-05-16 19:08 ` [PATCH v1 00/12] arm64/fp: Generate definitons for floating point system registers Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220510161208.631259-2-broonie@kernel.org \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.