From: Marc Zyngier <maz@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
broonie@kernel.org, danielmentz@google.com, saravanak@google.com,
kernel-team@android.com
Subject: [PATCH v2 5/9] arm64: Allow the idreg override to deal with variable field width
Date: Thu, 30 Jun 2022 17:04:56 +0100 [thread overview]
Message-ID: <20220630160500.1536744-6-maz@kernel.org> (raw)
In-Reply-To: <20220630160500.1536744-1-maz@kernel.org>
Currently, the override mechanism can only deal with 4bit fields,
which is the most common case. However, we now have a bunch of
ID registers that have more diverse field widths, such as
ID_AA64SMFR0_EL1, which has fields that are a single bit wide.
Add the support for variable width, and a macro that encodes
a feature width of 4 for all existing override.
No functional change.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/idreg-override.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 03185bc46d69..1e5f3dba3f01 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -27,10 +27,13 @@ struct ftr_set_desc {
struct {
char name[FTR_DESC_FIELD_LEN];
u8 shift;
+ u8 width;
bool (*filter)(u64 val);
} fields[];
};
+#define FIELD(n, s, f) { .name = n, .shift = s, .width = 4, .filter = f }
+
static bool __init mmfr1_vh_filter(u64 val)
{
/*
@@ -47,7 +50,7 @@ static const struct ftr_set_desc mmfr1 __initconst = {
.name = "id_aa64mmfr1",
.override = &id_aa64mmfr1_override,
.fields = {
- { "vh", ID_AA64MMFR1_VHE_SHIFT, mmfr1_vh_filter },
+ FIELD("vh", ID_AA64MMFR1_VHE_SHIFT, mmfr1_vh_filter),
{}
},
};
@@ -56,8 +59,8 @@ static const struct ftr_set_desc pfr1 __initconst = {
.name = "id_aa64pfr1",
.override = &id_aa64pfr1_override,
.fields = {
- { "bt", ID_AA64PFR1_BT_SHIFT },
- { "mte", ID_AA64PFR1_MTE_SHIFT},
+ FIELD("bt", ID_AA64PFR1_BT_SHIFT, NULL),
+ FIELD("mte", ID_AA64PFR1_MTE_SHIFT, NULL),
{}
},
};
@@ -66,10 +69,10 @@ static const struct ftr_set_desc isar1 __initconst = {
.name = "id_aa64isar1",
.override = &id_aa64isar1_override,
.fields = {
- { "gpi", ID_AA64ISAR1_GPI_SHIFT },
- { "gpa", ID_AA64ISAR1_GPA_SHIFT },
- { "api", ID_AA64ISAR1_API_SHIFT },
- { "apa", ID_AA64ISAR1_APA_SHIFT },
+ FIELD("gpi", ID_AA64ISAR1_GPI_SHIFT, NULL),
+ FIELD("gpa", ID_AA64ISAR1_GPA_SHIFT, NULL),
+ FIELD("api", ID_AA64ISAR1_API_SHIFT, NULL),
+ FIELD("apa", ID_AA64ISAR1_APA_SHIFT, NULL),
{}
},
};
@@ -78,8 +81,8 @@ static const struct ftr_set_desc isar2 __initconst = {
.name = "id_aa64isar2",
.override = &id_aa64isar2_override,
.fields = {
- { "gpa3", ID_AA64ISAR2_GPA3_SHIFT },
- { "apa3", ID_AA64ISAR2_APA3_SHIFT },
+ FIELD("gpa3", ID_AA64ISAR2_GPA3_SHIFT, NULL),
+ FIELD("apa3", ID_AA64ISAR2_APA3_SHIFT, NULL),
{}
},
};
@@ -92,7 +95,7 @@ static const struct ftr_set_desc kaslr __initconst = {
.override = &kaslr_feature_override,
#endif
.fields = {
- { "disabled", 0 },
+ FIELD("disabled", 0, NULL),
{}
},
};
@@ -147,7 +150,8 @@ static void __init match_options(const char *cmdline)
for (f = 0; strlen(regs[i]->fields[f].name); f++) {
u64 shift = regs[i]->fields[f].shift;
- u64 mask = 0xfUL << shift;
+ u64 width = regs[i]->fields[f].width ?: 4;
+ u64 mask = GENMASK_ULL(shift + width - 1, shift);
u64 v;
if (find_field(cmdline, regs[i], f, &v))
@@ -155,7 +159,7 @@ static void __init match_options(const char *cmdline)
/*
* If an override gets filtered out, advertise
- * it by setting the value to 0xf, but
+ * it by setting the value to the all-ones while
* clearing the mask... Yes, this is fragile.
*/
if (regs[i]->fields[f].filter &&
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-30 16:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 16:04 [PATCH v2 0/9] arm64: Disabling SVE/SME from the command-line Marc Zyngier
2022-06-30 16:04 ` [PATCH v2 1/9] arm64: Rename the VHE switch to "finalise_el2" Marc Zyngier
2022-06-30 16:04 ` [PATCH v2 2/9] arm64: Save state of HCR_EL2.E2H before switch to EL1 Marc Zyngier
2022-06-30 16:04 ` [PATCH v2 3/9] arm64: Allow sticky E2H when entering EL1 Marc Zyngier
2022-06-30 16:04 ` [PATCH v2 4/9] arm64: Factor out checking of a feature against the override into a macro Marc Zyngier
2022-06-30 16:04 ` Marc Zyngier [this message]
2022-07-01 14:00 ` [PATCH v2 5/9] arm64: Allow the idreg override to deal with variable field width Mark Brown
2022-06-30 16:04 ` [PATCH v2 6/9] arm64: Expose a __check_override primitive for oddball features Marc Zyngier
2022-07-01 14:03 ` Mark Brown
2022-06-30 16:04 ` [PATCH v2 7/9] arm64: Add the arm64.nosme command line option Marc Zyngier
2022-07-01 13:44 ` Mark Brown
2022-06-30 16:04 ` [PATCH v2 8/9] arm64: Add the arm64.nosve " Marc Zyngier
2022-07-01 13:45 ` Mark Brown
2022-06-30 16:05 ` [PATCH v2 9/9] arm64: Add an override for ID_AA64SMFR0_EL1.FA64 Marc Zyngier
2022-07-01 13:52 ` Mark Brown
2022-07-01 15:41 ` [PATCH v2 0/9] arm64: Disabling SVE/SME from the command-line Will Deacon
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=20220630160500.1536744-6-maz@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=danielmentz@google.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=saravanak@google.com \
--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.