From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>
Subject: [PATCH v2 2/8] ARM: vfp: Remove workaround for Feroceon CPUs
Date: Wed, 17 May 2023 23:28:02 +0200 [thread overview]
Message-ID: <20230517212808.3895190-3-ardb@kernel.org> (raw)
In-Reply-To: <20230517212808.3895190-1-ardb@kernel.org>
Feroceon CPUs have a non-standard implementation of VFP which reports
synchronous VFP exceptions using the async VFP flag. This requires a
workaround which is difficult to reconcile with other implementations,
making it tricky to support both versions in a single image.
Since this is a v5 CPU, it is not supported by armhf and so the
likelihood that anybody is using this with recent distros/kernels and
rely on the VFP at the same time is extremely low. So let's just disable
VFP support on these cores, so we can remove the workaround.
This will help future development to support v5 and v6 CPUs with a
single kernel image.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm/mm/proc-feroceon.S | 4 ++++
arch/arm/vfp/vfphw.S | 4 ----
arch/arm/vfp/vfpmodule.c | 8 +++++---
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S
index 61ce82aca6f0d603..072ff9b451f846bf 100644
--- a/arch/arm/mm/proc-feroceon.S
+++ b/arch/arm/mm/proc-feroceon.S
@@ -56,6 +56,10 @@ ENTRY(cpu_feroceon_proc_init)
movne r2, r2, lsr #2 @ turned into # of sets
sub r2, r2, #(1 << 5)
stmia r1, {r2, r3}
+#ifdef CONFIG_VFP
+ mov r1, #1 @ disable quirky VFP
+ str_l r1, VFP_arch_feroceon, r2
+#endif
ret lr
/*
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index a4610d0f321527cc..0aeb60ac3b5376a8 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -110,7 +110,6 @@ ENTRY(vfp_support_entry)
beq vfp_reload_hw @ then the hw state needs reloading
VFPFSTMIA r4, r5 @ save the working registers
VFPFMRX r5, FPSCR @ current status
-#ifndef CONFIG_CPU_FEROCEON
tst r1, #FPEXC_EX @ is there additional state to save?
beq 1f
VFPFMRX r6, FPINST @ FPINST (only if FPEXC.EX is set)
@@ -118,7 +117,6 @@ ENTRY(vfp_support_entry)
beq 1f
VFPFMRX r8, FPINST2 @ FPINST2 if needed (and present)
1:
-#endif
stmia r4, {r1, r5, r6, r8} @ save FPEXC, FPSCR, FPINST, FPINST2
vfp_reload_hw:
@@ -153,7 +151,6 @@ vfp_reload_hw:
VFPFLDMIA r10, r5 @ reload the working registers while
@ FPEXC is in a safe state
ldmia r10, {r1, r5, r6, r8} @ load FPEXC, FPSCR, FPINST, FPINST2
-#ifndef CONFIG_CPU_FEROCEON
tst r1, #FPEXC_EX @ is there additional state to restore?
beq 1f
VFPFMXR FPINST, r6 @ restore FPINST (only if FPEXC.EX is set)
@@ -161,7 +158,6 @@ vfp_reload_hw:
beq 1f
VFPFMXR FPINST2, r8 @ FPINST2 if needed (and present)
1:
-#endif
VFPFMXR FPSCR, r5 @ restore status
@ The context stored in the VFP hardware is up to date with this thread
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 08d5dfcf70796eea..95628e57807b1e79 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -42,7 +42,11 @@ static bool have_vfp __ro_after_init;
* Used in startup: set to non-zero if VFP checks fail
* After startup, holds VFP architecture
*/
-static unsigned int __initdata VFP_arch;
+static unsigned int VFP_arch;
+
+#ifdef CONFIG_CPU_FEROCEON
+extern unsigned int VFP_arch_feroceon __alias(VFP_arch);
+#endif
/*
* The pointer to the vfpstate structure of the thread which currently
@@ -357,14 +361,12 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs)
}
if (fpexc & FPEXC_EX) {
-#ifndef CONFIG_CPU_FEROCEON
/*
* Asynchronous exception. The instruction is read from FPINST
* and the interrupted instruction has to be restarted.
*/
trigger = fmrx(FPINST);
regs->ARM_pc -= 4;
-#endif
} else if (!(fpexc & FPEXC_DEX)) {
/*
* Illegal combination of bits. It can be caused by an
--
2.39.2
_______________________________________________
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:[~2023-05-17 21:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 21:28 [PATCH v2 0/8] ARM: vfp: Reimplement dispatch and support logic in C Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 1/8] ARM: vfp: Record VFP bounces as perf emulation faults Ard Biesheuvel
2023-05-17 21:28 ` Ard Biesheuvel [this message]
2023-05-17 21:28 ` [PATCH v2 3/8] ARM: vfp: Reimplement VFP exception entry in C code Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 4/8] ARM: kernel: Get rid of thread_info::used_cp[] array Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 5/8] ARM: vfp: Use undef hook for handling VFP exceptions Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 6/8] ARM: entry: Disregard Thumb undef exception in coproc dispatch Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 7/8] ARM: iwmmxt: Use undef hook to enable coprocessor for task Ard Biesheuvel
2023-05-17 21:28 ` [PATCH v2 8/8] ARM: entry: Make asm coproc dispatch code NWFPE only Ard Biesheuvel
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=20230517212808.3895190-3-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=nico@fluxnic.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).