OrgACRN
/
acrn-kernel
mirror of https://github.com/projectacrn/acrn-kernel.git
1
0
Fork 0
Code Issues Releases Wiki Activity
acrn-kernel/arch/mips/include/uapi/asm/hwcap.h

23 lines
715 B
C
Raw Normal View History

License cleanup: add SPDX license identifier to uapi header files with no license Many user space API headers are missing licensing information, which makes it hard for compliance tools to determine the correct license. By default are files without license information under the default license of the kernel, which is GPLV2. Marking them GPLV2 would exclude them from being included in non GPLV2 code, which is obviously not intended. The user space API headers fall under the syscall exception which is in the kernels COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". otherwise syscall usage would not be possible. Update the files which contain no license information with an SPDX license identifier. The chosen identifier is 'GPL-2.0 WITH Linux-syscall-note' which is the officially assigned identifier for the Linux syscall exception. SPDX license identifiers are a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. See the previous patch in this series for the methodology of how this patch was researched. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:08:43 +08:00
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
MIPS: AT_HWCAP aux vector infrastructure In order for userland to determine whether various features are safe to use, it will need to know both that the hardware supports those features and that the kernel is recent enough & configured appropriately to support them. For example under the O32 modeless FP proposal the dynamic linker & ifunc resolvers will need this information. The kernel is the only thing in a position to know availability accurately, so the kernel needs to provide the information to userland. This patch introduces the infrastructure to provide the AT_HWCAP aux vector to userland in order to provide that information. It also defines the 2 currently specified flags, which indicate MIPSr6 & MSA support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Guenter Roeck <linux@roeck-us.net> Cc: Matthew Fortune <matthew.fortune@imgtec.com> Cc: Kees Cook <keescook@chromium.org> Cc: Huacai Chen <chenhc@lemote.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: linux-kernel@vger.kernel.org Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Ingo Molnar <mingo@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/10797/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-28 03:58:23 +08:00
#ifndef _UAPI_ASM_HWCAP_H
#define _UAPI_ASM_HWCAP_H
/* HWCAP flags */
#define HWCAP_MIPS_R6 (1 << 0)
#define HWCAP_MIPS_MSA (1 << 1)
MIPS: Add crc instruction support flag to elf_hwcap Indicate that CRC32 and CRC32C instuctions are supported by the CPU through elf_hwcap flags. This will be used by a follow-up commit that introduces crc32(c) crypto acceleration modules and is required by GENERIC_CPU_AUTOPROBE feature. Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com> Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18600/
2018-02-10 06:11:05 +08:00
#define HWCAP_MIPS_CRC32 (1 << 2)
MIPS: elf_hwcap: Export userspace ASEs A Golang developer reported MIPS hwcap isn't reflecting instructions that the processor actually supported so programs can't apply optimized code at runtime. Thus we export the ASEs that can be used in userspace programs. Reported-by: Meng Zhuo <mengzhuo1203@gmail.com> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org Cc: Paul Burton <paul.burton@mips.com> Cc: <stable@vger.kernel.org> # 4.14+ Signed-off-by: Paul Burton <paul.burton@mips.com>
2019-10-10 23:01:57 +08:00
#define HWCAP_MIPS_MIPS16 (1 << 3)
#define HWCAP_MIPS_MDMX (1 << 4)
#define HWCAP_MIPS_MIPS3D (1 << 5)
#define HWCAP_MIPS_SMARTMIPS (1 << 6)
#define HWCAP_MIPS_DSP (1 << 7)
#define HWCAP_MIPS_DSP2 (1 << 8)
#define HWCAP_MIPS_DSP3 (1 << 9)
#define HWCAP_MIPS_MIPS16E2 (1 << 10)
#define HWCAP_LOONGSON_MMI (1 << 11)
#define HWCAP_LOONGSON_EXT (1 << 12)
#define HWCAP_LOONGSON_EXT2 (1 << 13)
MIPS: Expose Loongson CPUCFG availability via HWCAP The point is to allow userspace to probe for CPUCFG without possibly triggering invalid instructions. In addition to that, future Loongson feature bits could all be stuffed into CPUCFG bit fields (or "leaves" in x86-speak) if Loongson does not make mistakes, so ELF HWCAP bits are conserved. Userspace can determine native CPUCFG availability by checking the LCSRP (Loongson CSR Present) bit in CPUCFG output after seeing CPUCFG bit in HWCAP. Native CPUCFG always sets the LCSRP bit, as CPUCFG is part of the Loongson CSR ASE, while the emulation intentionally leaves this bit clear. The other existing Loongson-specific HWCAP bits are, to my best knowledge, unused, as (1) they are fairly recent additions, (2) Loongson never back-ported the patch into their kernel fork, and (3) Loongson's existing installed base rarely upgrade, if ever; However, they are still considered userspace ABI, hence unfortunately unremovable. But hopefully at least we could stop adding new Loongson HWCAP bits in the future. Cc: Paul Burton <paulburton@kernel.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Huacai Chen <chenhc@lemote.com> Signed-off-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-30 15:32:42 +08:00
#define HWCAP_LOONGSON_CPUCFG (1 << 14)
MIPS: AT_HWCAP aux vector infrastructure In order for userland to determine whether various features are safe to use, it will need to know both that the hardware supports those features and that the kernel is recent enough & configured appropriately to support them. For example under the O32 modeless FP proposal the dynamic linker & ifunc resolvers will need this information. The kernel is the only thing in a position to know availability accurately, so the kernel needs to provide the information to userland. This patch introduces the infrastructure to provide the AT_HWCAP aux vector to userland in order to provide that information. It also defines the 2 currently specified flags, which indicate MIPSr6 & MSA support. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Guenter Roeck <linux@roeck-us.net> Cc: Matthew Fortune <matthew.fortune@imgtec.com> Cc: Kees Cook <keescook@chromium.org> Cc: Huacai Chen <chenhc@lemote.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: linux-kernel@vger.kernel.org Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Ingo Molnar <mingo@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/10797/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-28 03:58:23 +08:00
#endif /* _UAPI_ASM_HWCAP_H */