When we get nanoMIPS support we'll be introducing the p32
ABI, and there's a reasonable chance that the equivalent
p64 ABI may come along in the future. Using 'n64' now would
avoid confusion in that case where we may have 2 different
64-bit ABIs.
Suggested-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Firoz Khan <firoz.khan@linaro.org>
[paul.burton@mips.com:
- Remove UAPI macro renaming, github code search shows at least the
chromium project uses __NR_64_Linux & __NR_64_Linux_syscalls.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: y2038@lists.linaro.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: arnd@arndb.de
Cc: deepa.kernel@gmail.com
Cc: marcin.juszkiewicz@linaro.org
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_32BIT) += scall32-o32.o
-obj-$(CONFIG_64BIT) += scall64-64.o
+obj-$(CONFIG_64BIT) += scall64-n64.o
obj-$(CONFIG_MIPS32_COMPAT) += linux32.o ptrace32.o signal32.o
obj-$(CONFIG_MIPS32_N32) += binfmt_elfn32.o scall64-n32.o signal_n32.o
obj-$(CONFIG_MIPS32_O32) += binfmt_elfo32.o scall64-o32.o signal_o32.o