From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk
Cc: Ard Biesheuvel <ardb@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
Peter Zijlstra <peterz@infradead.org>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH v3 1/4] ARM: vfp: Pass thread_info pointer to vfp_support_entry
Date: Thu, 16 Mar 2023 09:20:04 +0100 [thread overview]
Message-ID: <20230316082007.652669-2-ardb@kernel.org> (raw)
In-Reply-To: <20230316082007.652669-1-ardb@kernel.org>
Instead of dereferencing thread_info in do_vfp, pass the thread_info
pointer to vfp_support_entry via R1. That way, we only use a single
caller save register, which makes it easier to convert do_vfp to C code
in a subsequent patch.
Note that, unlike the CPU number, which can change due to preemption,
passing the thread_info pointer can safely be done with preemption
enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
---
arch/arm/vfp/entry.S | 5 +----
arch/arm/vfp/vfphw.S | 10 +++++++---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
index 9a89264cdcc0b46e..cfedc2a3dbd68f1c 100644
--- a/arch/arm/vfp/entry.S
+++ b/arch/arm/vfp/entry.S
@@ -22,15 +22,12 @@
@ IRQs enabled.
@
ENTRY(do_vfp)
- local_bh_disable r10, r4
+ mov r1, r10
ldr r4, .LCvfp
- ldr r11, [r10, #TI_CPU] @ CPU number
- add r10, r10, #TI_VFPSTATE @ r10 = workspace
ldr pc, [r4] @ call VFP entry point
ENDPROC(do_vfp)
ENTRY(vfp_null_entry)
- local_bh_enable_ti r10, r4
ret lr
ENDPROC(vfp_null_entry)
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 26c4f61ecfa39638..6d056d810e4868c2 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -6,9 +6,9 @@
* Written by Deep Blue Solutions Limited.
*
* This code is called from the kernel's undefined instruction trap.
+ * r1 holds the thread_info pointer
* r9 holds the return address for successful handling.
* lr holds the return address for unrecognised instructions.
- * r10 points at the start of the private FP workspace in the thread structure
* sp points to a struct pt_regs (as defined in include/asm/proc/ptrace.h)
*/
#include <linux/init.h>
@@ -69,13 +69,17 @@
@ VFP hardware support entry point.
@
@ r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+@ r1 = thread_info pointer
@ r2 = PC value to resume execution after successful emulation
@ r9 = normal "successful" return address
-@ r10 = vfp_state union
-@ r11 = CPU number
@ lr = unrecognised instruction return address
@ IRQs enabled.
ENTRY(vfp_support_entry)
+ local_bh_disable r1, r4
+
+ ldr r11, [r1, #TI_CPU] @ CPU number
+ add r10, r1, #TI_VFPSTATE @ r10 = workspace
+
DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
.fpu vfpv2
--
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-03-16 8:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 8:20 [PATCH v3 0/4] ARM: vfp: Switch to C API to en/disable softirqs Ard Biesheuvel
2023-03-16 8:20 ` Ard Biesheuvel [this message]
2023-03-16 8:20 ` [PATCH v3 2/4] ARM: vfp: Pass successful return address via register R3 Ard Biesheuvel
2023-03-16 8:20 ` [PATCH v3 3/4] ARM: vfp: Fix broken softirq handling with instrumentation enabled Ard Biesheuvel
2023-03-16 8:20 ` [PATCH v3 4/4] ARM: vfp: Reimplement VFP exception entry in C code Ard Biesheuvel
2023-03-16 8:59 ` Linus Walleij
2023-03-18 16:20 ` Ard Biesheuvel
2023-03-17 0:23 ` [PATCH v3 0/4] ARM: vfp: Switch to C API to en/disable softirqs Guenter Roeck
2023-03-17 0:24 ` Guenter Roeck
2023-03-17 8:55 ` 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=20230316082007.652669-2-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=frederic@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linux@roeck-us.net \
--cc=peterz@infradead.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.