SAVE_ALL and RESTORE_ALL macros for !CONFIG_X86_64 were introduced in the
1a338ac32 commit (sched, x86: Optimize the preempt_schedule() call) and
were used in the ___preempt_schedule and ___preempt_schedule_context from
the  arch/x86/kernel/preempt.S. But the arch/x86/kernel/preempt.S was
removed in the 0ad6e3c5 commit (x86: Speed up ___preempt_schedule*() by
using THUNK helpers) and ___preempt_schedule/___preempt_schedule_context
are reimplemeted and not used SAVE_ALL/RESTORE_ALL anymore.

These macros have no users anymore, so we can remove it.

Changelog:

v2: Check of the CONFIG_x86_64 returned as <calling.h> provides
functionality only for the x86_64.

Signed-off-by: Alexander Kuleshov <kuleshovm...@gmail.com>
---
 arch/x86/entry/calling.h | 33 ---------------------------------
 1 file changed, 33 deletions(-)

diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index f4e6308..c009cee 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -207,37 +207,4 @@ For 32-bit we have the following conventions - kernel is 
built with
        .macro icebp
        .byte 0xf1
        .endm
-
-#else /* CONFIG_X86_64 */
-
-/*
- * For 32bit only simplified versions of SAVE_ALL/RESTORE_ALL. These
- * are different from the entry_32.S versions in not changing the segment
- * registers. So only suitable for in kernel use, not when transitioning
- * from or to user space. The resulting stack frame is not a standard
- * pt_regs frame. The main use case is calling C code from assembler
- * when all the registers need to be preserved.
- */
-
-       .macro SAVE_ALL
-       pushl %eax
-       pushl %ebp
-       pushl %edi
-       pushl %esi
-       pushl %edx
-       pushl %ecx
-       pushl %ebx
-       .endm
-
-       .macro RESTORE_ALL
-       popl %ebx
-       popl %ecx
-       popl %edx
-       popl %esi
-       popl %edi
-       popl %ebp
-       popl %eax
-       .endm
-
 #endif /* CONFIG_X86_64 */
-
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to