OpenCloudOS-Kernel/arch/mips/Kconfig

3226 lines
81 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is 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. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. 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:07:57 +08:00
# SPDX-License-Identifier: GPL-2.0
config MIPS
bool
default y
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
select CPU_PM if CPU_IDLE
select GENERIC_ATOMIC64 if !64BIT
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_ISA_DMA if EISA
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_CMPDI2
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_UCMPDI2
select GENERIC_SCHED_CLOCK if !CAVIUM_OCTEON_SOC
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
MIPS: use the generic get_user_pages_fast code The mips code is mostly equivalent to the generic one, minus various bugfixes and an arch override for gup_fast_permitted. Note that this defines ARCH_HAS_PTE_SPECIAL for mips as mips has pte_special and pte_mkspecial implemented and used in the existing gup code. They are no-op stubs, though which makes me a little unsure if this is really right thing to do. Note that this also adds back a missing cpu_has_dc_aliases check for __get_user_pages_fast, which the old code was only doing for get_user_pages_fast. This clearly looks like an oversight, as any condition that makes get_user_pages_fast unsafe also applies to __get_user_pages_fast. [hch@lst.de: MIPS: don't select ARCH_HAS_PTE_SPECIAL] Link: http://lkml.kernel.org/r/20190701151818.32227-3-hch@lst.de Link: http://lkml.kernel.org/r/20190625143715.1689-5-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Miller <davem@davemloft.net> Cc: James Hogan <jhogan@kernel.org> Cc: Khalid Aziz <khalid.aziz@oracle.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Paul Burton <paul.burton@mips.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Rich Felker <dalias@libc.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-12 11:56:52 +08:00
select GUP_GET_PTE_LOW_HIGH if CPU_MIPS32 && PHYS_ADDR_T_64BIT
select HANDLE_DOMAIN_IRQ
MIPS: Workaround GCC __builtin_unreachable reordering bug Some versions of GCC for the MIPS architecture suffer from a bug which can lead to instructions from beyond an unreachable statement being incorrectly reordered into earlier branch delay slots if the unreachable statement is the only content of a case in a switch statement. This can lead to seemingly random behaviour, such as invalid memory accesses from incorrectly reordered loads or stores, and link failures on microMIPS builds. See this potential GCC fix for details: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html Runtime problems resulting from this bug were initially observed using a maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape SDK 2015.06-05 toolchain), with the result being an address exception taken after log messages about the L1 caches (during probe of the L2 cache): Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff] VPE topology {2,2} total 4 Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes <AdEL exception here> This is early enough that the kernel exception vectors are not in use, so any further output depends upon the bootloader. This is reproducible in QEMU where no further output occurs - ie. the system hangs here. Given the nature of the bug it may potentially be hit with differing symptoms. The bug is known to affect GCC versions as recent as 7.3, and it is unclear whether GCC 8 fixed it or just happens not to encounter the bug in the testcase found at the link above due to differing optimizations. This bug can be worked around by placing a volatile asm statement, which GCC is prevented from reordering past, prior to the __builtin_unreachable call. That was actually done already for other reasons by commit 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()"), but creates problems for microMIPS builds due to the lack of a .insn directive. The microMIPS ISA allows for interlinking with regular MIPS32 code by repurposing bit 0 of the program counter as an ISA mode bit. To switch modes one changes the value of this bit in the PC. However typical branch instructions encode their offsets as multiples of 2-byte instruction halfwords, which means they cannot change ISA mode - this must be done using either an indirect branch (a jump-register in MIPS terminology) or a dedicated jalx instruction. In order to ensure that regular branches don't attempt to target code in a different ISA which they can't actually switch to, the linker will check that branch targets are code in the same ISA as the branch. Unfortunately our empty asm volatile statements don't qualify as code, and the link for microMIPS builds fails with errors such as: arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode Resolve this by adding a .insn directive within the asm statement which declares that what comes next is code. This may or may not be true, since we don't really know what comes next, but as this code is in an unreachable path anyway that doesn't matter since we won't execute it. We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in order to have this included by linux/compiler_types.h after linux/compiler-gcc.h. This will result in asm/compiler.h being included in all C compilations via the -include linux/compiler_types.h argument in c_flags, which should be harmless. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()") Patchwork: https://patchwork.linux-mips.org/patch/20270/ Cc: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-mips@linux-mips.org
2018-08-21 06:36:18 +08:00
select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
select HAVE_EBPF_JIT if (!CPU_MICROMIPS)
select HAVE_CONTEXT_TRACKING
select HAVE_COPY_THREAD_TLS
select HAVE_C_RECORDMCOUNT
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_DMA_CONTIGUOUS
MIPS: Tracing: Add dynamic function tracer support With dynamic function tracer, by default, _mcount is defined as an "empty" function, it returns directly without any more action . When enabling it in user-space, it will jump to a real tracing function(ftrace_caller), and do the real job for us. Differ from the static function tracer, dynamic function tracer provides two functions ftrace_make_call()/ftrace_make_nop() to enable/disable the tracing of some indicated kernel functions(set_ftrace_filter). In the -v4 version, the implementation of this support is basically the same as X86 version does: _mcount is implemented as an empty function and ftrace_caller is implemented as a real tracing function respectively. But in this version, to support module tracing with the help of -mlong-calls in arch/mips/Makefile: MODFLAGS += -mlong-calls. The stuff becomes a little more complex. We need to cope with two different type of calling to _mcount. For the kernel part, the calling to _mcount(result of "objdump -hdr vmlinux"). is like this: 108: 03e0082d move at,ra 10c: 0c000000 jal 0 <fpcsr_pending> 10c: R_MIPS_26 _mcount 10c: R_MIPS_NONE *ABS* 10c: R_MIPS_NONE *ABS* 110: 00020021 nop For the module with -mlong-calls, it looks like this: c: 3c030000 lui v1,0x0 c: R_MIPS_HI16 _mcount c: R_MIPS_NONE *ABS* c: R_MIPS_NONE *ABS* 10: 64630000 daddiu v1,v1,0 10: R_MIPS_LO16 _mcount 10: R_MIPS_NONE *ABS* 10: R_MIPS_NONE *ABS* 14: 03e0082d move at,ra 18: 0060f809 jalr v1 In the kernel version, there is only one "_mcount" string for every kernel function, so, we just need to match this one in mcount_regex of scripts/recordmcount.pl, but in the module version, we need to choose one of the two to match. Herein, I choose the first one with "R_MIPS_HI16 _mcount". and In the kernel verion, without module tracing support, we just need to replace "jal _mcount" by "jal ftrace_caller" to do real tracing, and filter the tracing of some kernel functions via replacing it by a nop instruction. but as we have described before, the instruction "jal ftrace_caller" only left 32bit length for the address of ftrace_caller, it will fail when calling from the module space. so, herein, we must replace something else. the basic idea is loading the address of ftrace_caller to v1 via changing these two instructions: lui v1,0x0 addiu v1,v1,0 If we want to enable the tracing, we need to replace the above instructions to: lui v1, HI_16BIT_ftrace_caller addiu v1, v1, LOW_16BIT_ftrace_caller If we want to stop the tracing of the indicated kernel functions, we just need to replace the "jalr v1" to a nop instruction. but we need to replace two instructions and encode the above two instructions oursevles. Is there a simpler solution? Yes! Here it is, in this version, we put _mcount and ftrace_caller together, which means the address of _mcount and ftrace_caller is the same: _mcount: ftrace_caller: j ftrace_stub nop ...(do real tracing here)... ftrace_stub: jr ra move ra, at By default, the kernel functions call _mcount, and then jump to ftrace_stub and return. and when we want to do real tracing, we just need to remove that "j ftrace_stub", and it will run through the two "nop" instructions and then do the real tracing job. what about filtering job? we just need to do this: lui v1, hi_16bit_of_mcount <--> b 1f (0x10000004) addiu v1, v1, low_16bit_of_mcount move at, ra jalr v1 nop 1f: (rec->ip + 12) In linux-mips64, there will be some local symbols, whose name are prefixed by $L, which need to be filtered. thanks goes to Steven for writing the mips64-specific function_regex. In a conclusion, with RISC, things becomes easier with such a "stupid" trick, RISC is something like K.I.S.S, and also, there are lots of "simple" tricks in the whole ftrace support, thanks goes to Steven and the other folks for providing such a wonderful tracing framework! Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: zhangfx@lemote.com Cc: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/675/ Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 20:34:32 +08:00
select HAVE_DYNAMIC_FTRACE
select HAVE_EXIT_THREAD
select HAVE_FAST_GUP
MIPS: Tracing: Add dynamic function tracer support With dynamic function tracer, by default, _mcount is defined as an "empty" function, it returns directly without any more action . When enabling it in user-space, it will jump to a real tracing function(ftrace_caller), and do the real job for us. Differ from the static function tracer, dynamic function tracer provides two functions ftrace_make_call()/ftrace_make_nop() to enable/disable the tracing of some indicated kernel functions(set_ftrace_filter). In the -v4 version, the implementation of this support is basically the same as X86 version does: _mcount is implemented as an empty function and ftrace_caller is implemented as a real tracing function respectively. But in this version, to support module tracing with the help of -mlong-calls in arch/mips/Makefile: MODFLAGS += -mlong-calls. The stuff becomes a little more complex. We need to cope with two different type of calling to _mcount. For the kernel part, the calling to _mcount(result of "objdump -hdr vmlinux"). is like this: 108: 03e0082d move at,ra 10c: 0c000000 jal 0 <fpcsr_pending> 10c: R_MIPS_26 _mcount 10c: R_MIPS_NONE *ABS* 10c: R_MIPS_NONE *ABS* 110: 00020021 nop For the module with -mlong-calls, it looks like this: c: 3c030000 lui v1,0x0 c: R_MIPS_HI16 _mcount c: R_MIPS_NONE *ABS* c: R_MIPS_NONE *ABS* 10: 64630000 daddiu v1,v1,0 10: R_MIPS_LO16 _mcount 10: R_MIPS_NONE *ABS* 10: R_MIPS_NONE *ABS* 14: 03e0082d move at,ra 18: 0060f809 jalr v1 In the kernel version, there is only one "_mcount" string for every kernel function, so, we just need to match this one in mcount_regex of scripts/recordmcount.pl, but in the module version, we need to choose one of the two to match. Herein, I choose the first one with "R_MIPS_HI16 _mcount". and In the kernel verion, without module tracing support, we just need to replace "jal _mcount" by "jal ftrace_caller" to do real tracing, and filter the tracing of some kernel functions via replacing it by a nop instruction. but as we have described before, the instruction "jal ftrace_caller" only left 32bit length for the address of ftrace_caller, it will fail when calling from the module space. so, herein, we must replace something else. the basic idea is loading the address of ftrace_caller to v1 via changing these two instructions: lui v1,0x0 addiu v1,v1,0 If we want to enable the tracing, we need to replace the above instructions to: lui v1, HI_16BIT_ftrace_caller addiu v1, v1, LOW_16BIT_ftrace_caller If we want to stop the tracing of the indicated kernel functions, we just need to replace the "jalr v1" to a nop instruction. but we need to replace two instructions and encode the above two instructions oursevles. Is there a simpler solution? Yes! Here it is, in this version, we put _mcount and ftrace_caller together, which means the address of _mcount and ftrace_caller is the same: _mcount: ftrace_caller: j ftrace_stub nop ...(do real tracing here)... ftrace_stub: jr ra move ra, at By default, the kernel functions call _mcount, and then jump to ftrace_stub and return. and when we want to do real tracing, we just need to remove that "j ftrace_stub", and it will run through the two "nop" instructions and then do the real tracing job. what about filtering job? we just need to do this: lui v1, hi_16bit_of_mcount <--> b 1f (0x10000004) addiu v1, v1, low_16bit_of_mcount move at, ra jalr v1 nop 1f: (rec->ip + 12) In linux-mips64, there will be some local symbols, whose name are prefixed by $L, which need to be filtered. thanks goes to Steven for writing the mips64-specific function_regex. In a conclusion, with RISC, things becomes easier with such a "stupid" trick, RISC is something like K.I.S.S, and also, there are lots of "simple" tricks in the whole ftrace support, thanks goes to Steven and the other folks for providing such a wonderful tracing framework! Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: zhangfx@lemote.com Cc: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/675/ Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 20:34:32 +08:00
select HAVE_FTRACE_MCOUNT_RECORD
MIPS: Tracing: Add function graph tracer support for MIPS The implementation of function graph tracer for MIPS is a little different from X86. in MIPS, gcc(with -pg) only transfer the caller's return address(at) and the _mcount's return address(ra) to us. For the kernel part without -mlong-calls: move at, ra jal _mcount For the module part with -mlong-calls: lui v1, hi16bit_of_mcount addiu v1, v1, low16bit_of_mcount move at, ra jal _mcount Without -mlong-calls, if the function is a leaf, it will not save the return address(ra): ffffffff80101298 <au1k_wait>: ffffffff80101298: 67bdfff0 daddiu sp,sp,-16 ffffffff8010129c: ffbe0008 sd s8,8(sp) ffffffff801012a0: 03a0f02d move s8,sp ffffffff801012a4: 03e0082d move at,ra ffffffff801012a8: 0c042930 jal ffffffff8010a4c0 <_mcount> ffffffff801012ac: 00020021 nop so, we can hijack it directly in _mcount, but if the function is non-leaf, the return address is saved in the stack. ffffffff80133030 <copy_process>: ffffffff80133030: 67bdff50 daddiu sp,sp,-176 ffffffff80133034: ffbe00a0 sd s8,160(sp) ffffffff80133038: 03a0f02d move s8,sp ffffffff8013303c: ffbf00a8 sd ra,168(sp) ffffffff80133040: ffb70098 sd s7,152(sp) ffffffff80133044: ffb60090 sd s6,144(sp) ffffffff80133048: ffb50088 sd s5,136(sp) ffffffff8013304c: ffb40080 sd s4,128(sp) ffffffff80133050: ffb30078 sd s3,120(sp) ffffffff80133054: ffb20070 sd s2,112(sp) ffffffff80133058: ffb10068 sd s1,104(sp) ffffffff8013305c: ffb00060 sd s0,96(sp) ffffffff80133060: 03e0082d move at,ra ffffffff80133064: 0c042930 jal ffffffff8010a4c0 <_mcount> ffffffff80133068: 00020021 nop but we can not get the exact stack address(which saved ra) directly in _mcount, we need to search the content of at register in the stack space or search the "s{d,w} ra, offset(sp)" instruction in the text. 'Cause we can not prove there is only a match in the stack space, so, we search the text instead. as we can see, if the first instruction above "move at, ra" is not a store instruction, there should be a leaf function, so we hijack the at register directly via putting &return_to_handler into it, otherwise, we search the "s{d,w} ra, offset(sp)" instruction to get the stack offset, and then the stack address. we use the above copy_process() as an example, we at last find "ffbf00a8", 0xa8 is the stack offset, we plus it with s8(fp), that is the stack address, we hijack the content via writing the &return_to_handler in. If with -mlong-calls, since there are two more instructions above "move at, ra", so, we can move the pointer to the position above "lui v1, hi16bit_of_mcount". Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Nicholas Mc Guire <der.herr@hofr.at> Cc: zhangfx@lemote.com Cc: Wu Zhangjin <wuzhangjin@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/677/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 20:34:34 +08:00
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_IRQ_TIME_ACCOUNTING
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
select HAVE_MEMBLOCK_NODE_MAP
2012-09-28 13:01:03 +08:00
select HAVE_MOD_ARCH_SPECIFIC
printk/nmi: generic solution for safe printk in NMI printk() takes some locks and could not be used a safe way in NMI context. The chance of a deadlock is real especially when printing stacks from all CPUs. This particular problem has been addressed on x86 by the commit a9edc8809328 ("x86/nmi: Perform a safe NMI stack trace on all CPUs"). The patchset brings two big advantages. First, it makes the NMI backtraces safe on all architectures for free. Second, it makes all NMI messages almost safe on all architectures (the temporary buffer is limited. We still should keep the number of messages in NMI context at minimum). Note that there already are several messages printed in NMI context: WARN_ON(in_nmi()), BUG_ON(in_nmi()), anything being printed out from MCE handlers. These are not easy to avoid. This patch reuses most of the code and makes it generic. It is useful for all messages and architectures that support NMI. The alternative printk_func is set when entering and is reseted when leaving NMI context. It queues IRQ work to copy the messages into the main ring buffer in a safe context. __printk_nmi_flush() copies all available messages and reset the buffer. Then we could use a simple cmpxchg operations to get synchronized with writers. There is also used a spinlock to get synchronized with other flushers. We do not longer use seq_buf because it depends on external lock. It would be hard to make all supported operations safe for a lockless use. It would be confusing and error prone to make only some operations safe. The code is put into separate printk/nmi.c as suggested by Steven Rostedt. It needs a per-CPU buffer and is compiled only on architectures that call nmi_enter(). This is achieved by the new HAVE_NMI Kconfig flag. The are MN10300 and Xtensa architectures. We need to clean up NMI handling there first. Let's do it separately. The patch is heavily based on the draft from Peter Zijlstra, see https://lkml.org/lkml/2015/6/10/327 [arnd@arndb.de: printk-nmi: use %zu format string for size_t] [akpm@linux-foundation.org: min_t->min - all types are size_t here] Signed-off-by: Petr Mladek <pmladek@suse.com> Suggested-by: Peter Zijlstra <peterz@infradead.org> Suggested-by: Steven Rostedt <rostedt@goodmis.org> Cc: Jan Kara <jack@suse.cz> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> [arm part] Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jiri Kosina <jkosina@suse.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: David Miller <davem@davemloft.net> Cc: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-21 08:00:33 +08:00
select HAVE_NMI
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RSEQ
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING_GEN if 64BIT || !SMP
select IRQ_FORCED_THREADING
select ISA if EISA
select MODULES_USE_ELF_RELA if MODULES && 64BIT
select MODULES_USE_ELF_REL if MODULES
select PERF_USE_VMALLOC
select RTC_LIB
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS
menu "Machine selection"
choice
prompt "System type"
default MIPS_GENERIC
config MIPS_GENERIC
bool "Generic board-agnostic MIPS kernel"
select BOOT_RAW
select BUILTIN_DTB
select CEVT_R4K
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
select CSRC_R4K
select DMA_PERDEV_COHERENT
select HAVE_PCI
select IRQ_MIPS_CPU
select LIBFDT
select MIPS_AUTO_PFN_OFFSET
select MIPS_CPU_SCACHE
select MIPS_GIC
select MIPS_L1_CACHE_SHIFT_7
select NO_EXCEPT_FILL
select PCI_DRIVERS_GENERIC
select PINCTRL
select SMP_UP if SMP
select SWAP_IO_SPACE
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_CPU_MIPS32_R6
select SYS_HAS_CPU_MIPS64_R1
select SYS_HAS_CPU_MIPS64_R2
select SYS_HAS_CPU_MIPS64_R6
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MICROMIPS
select SYS_SUPPORTS_MIPS_CPS
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_MULTITHREADING
select SYS_SUPPORTS_RELOCATABLE
select SYS_SUPPORTS_SMARTMIPS
select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USE_OF
select UHI_BOOT
help
Select this to build a kernel which aims to support multiple boards,
generally using a flattened device tree passed from the bootloader
using the boot protocol defined in the UHI (Unified Hosting
Interface) specification.
config MIPS_ALCHEMY
bool "Alchemy processor based machines"
select PHYS_ADDR_T_64BIT
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
select DMA_MAYBE_COHERENT # Au1000,1500,1100 aren't, rest is
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_APM_EMULATION
select GPIOLIB
select SYS_SUPPORTS_ZBOOT
select COMMON_CLK
config AR7
bool "Texas Instruments AR7"
select BOOT_ELF32
select DMA_NONCOHERENT
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
select NO_EXCEPT_FILL
select SWAP_IO_SPACE
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_ZBOOT_UART16550
select GPIOLIB
select VLYNQ
select HAVE_CLK
help
Support for the Texas Instruments AR7 System-on-a-Chip
family: TNETD7100, 7200 and 7300.
config ATH25
bool "Atheros AR231x/AR531x SoC support"
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select IRQ_DOMAIN
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_HAS_EARLY_PRINTK
help
Support for Atheros AR231x and Atheros AR531x based boards
config ATH79
bool "Atheros AR71XX/AR724X/AR913X based boards"
select ARCH_HAS_RESET_CONTROLLER
select BOOT_RAW
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select GPIOLIB
select PINCTRL
select HAVE_CLK
select COMMON_CLK
select CLKDEV_LOOKUP
select IRQ_MIPS_CPU
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_ZBOOT_UART_PROM
select USE_OF
select USB_EHCI_ROOT_HUB_TT if USB_EHCI_HCD_PLATFORM
help
Support for the Atheros AR71XX/AR724X/AR913X SoCs.
config BMIPS_GENERIC
bool "Broadcom Generic BMIPS kernel"
select ARCH_HAS_SYNC_DMA_FOR_CPU_ALL
select ARCH_HAS_PHYS_TO_DMA
select BOOT_RAW
select NO_EXCEPT_FILL
select USE_OF
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K
select COMMON_CLK
select BCM6345_L1_IRQ
select BCM7038_L1_IRQ
select BCM7120_L2_IRQ
select BRCMSTB_L2_IRQ
select IRQ_MIPS_CPU
select DMA_NONCOHERENT
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_HAS_CPU_BMIPS32_3300
select SYS_HAS_CPU_BMIPS4350
select SYS_HAS_CPU_BMIPS4380
select SYS_HAS_CPU_BMIPS5000
select SWAP_IO_SPACE
select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select HARDIRQS_SW_RESEND
help
Build a generic DT-based kernel image that boots on select
BCM33xx cable modem chips, BCM63xx DSL chips, and BCM7xxx set-top
box chips. Note that CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN
must be set appropriately for your board.
config BCM47XX
bool "Broadcom BCM47XX based boards"
select BOOT_RAW
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select HAVE_PCI
select IRQ_MIPS_CPU
select SYS_HAS_CPU_MIPS32_R1
select NO_EXCEPT_FILL
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_ZBOOT
select SYS_HAS_EARLY_PRINTK
select USE_GENERIC_EARLY_PRINTK_8250
select GPIOLIB
select LEDS_GPIO_REGISTER
select BCM47XX_NVRAM
select BCM47XX_SPROM
select BCM47XX_SSB if !BCM47XX_BCMA
help
Support for BCM47XX based boards
config BCM63XX
bool "Broadcom BCM63XX based boards"
select BOOT_RAW
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_HAS_EARLY_PRINTK
select SWAP_IO_SPACE
select GPIOLIB
select HAVE_CLK
select MIPS_L1_CACHE_SHIFT_4
select CLKDEV_LOOKUP
help
Support for BCM63XX based boards
config MIPS_COBALT
bool "Cobalt Server"
select CEVT_R4K
select CSRC_R4K
select CEVT_GT641XX
select DMA_NONCOHERENT
select FORCE_PCI
select I8253
select I8259
select IRQ_MIPS_CPU
select IRQ_GT641XX
select PCI_GT64XXX_PCI0
select SYS_HAS_CPU_NEVADA
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select USE_GENERIC_EARLY_PRINTK_8250
config MACH_DECSTATION
bool "DECstations"
select BOOT_ELF32
select CEVT_DS1287
select CEVT_R4K if CPU_R4X00
select CSRC_IOASIC
select CSRC_R4K if CPU_R4X00
[MIPS] R4000/R4400 errata workarounds This is the gereric part of R4000/R4400 errata workarounds. They include compiler and assembler support as well as some source code modifications to address the problems with some combinations of multiply/divide+shift instructions as well as the daddi and daddiu instructions. Changes included are as follows: 1. New Kconfig options to select workarounds by platforms as necessary. 2. Arch top-level Makefile to pass necessary options to the compiler; also incompatible configurations are detected (-mno-sym32 unsupported as horribly intrusive for little gain). 3. Bug detection updated and shuffled -- the multiply/divide+shift problem is lethal enough that if not worked around it makes the kernel crash in time_init() because of a division by zero; the daddiu erratum might also trigger early potentially, though I have not observed it. On the other hand the daddi detection code requires the exception subsystem to have been initialised (and is there mainly for information). 4. r4k_daddiu_bug() added so that the existence of the erratum can be queried by code at the run time as necessary; useful for generated code like TLB fault and copy/clear page handlers. 5. __udelay() updated as it uses multiplication in inline assembly. Note that -mdaddi requires modified toolchain (which has been maintained by myself and available from my site for ~4years now -- versions covered are GCC 2.95.4 - 4.1.2 and binutils from 2.13 onwards). The -mfix-r4000 and -mfix-r4400 have been standard for a while though. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-10-23 19:43:11 +08:00
select CPU_DADDI_WORKAROUNDS if 64BIT
select CPU_R4000_WORKAROUNDS if 64BIT
select CPU_R4400_WORKAROUNDS if 64BIT
select DMA_NONCOHERENT
select NO_IOPORT_MAP
select IRQ_MIPS_CPU
select SYS_HAS_CPU_R3000
select SYS_HAS_CPU_R4X00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_128HZ
select SYS_SUPPORTS_256HZ
select SYS_SUPPORTS_1024HZ
select MIPS_L1_CACHE_SHIFT_4
help
This enables support for DEC's MIPS based workstations. For details
see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the
DECstation porting pages on <http://decstation.unix-ag.org/>.
If you have one of the following DECstation Models you definitely
want to choose R4xx0 for the CPU Type:
DECstation 5000/50
DECstation 5000/150
DECstation 5000/260
DECsystem 5900/260
otherwise choose R3000.
config MACH_JAZZ
bool "Jazz family of machines"
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select FW_ARC
select FW_ARC32
select ARCH_MAY_HAVE_PC_FDC
select CEVT_R4K
select CSRC_R4K
select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN
select GENERIC_ISA_DMA
select HAVE_PCSPKR_PLATFORM
select IRQ_MIPS_CPU
select I8253
select I8259
select ISA
select SYS_HAS_CPU_R4X00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_100HZ
help
This a family of machines based on the MIPS R4030 chipset which was
used by several vendors to build RISC/os and Windows NT workstations.
Members include the Acer PICA, MIPS Magnum 4000, MIPS Millennium and
Olivetti M700-10 workstations.
config MACH_INGENIC
bool "Ingenic SoC based machines"
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_ZBOOT_UART16550
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select PINCTRL
select GPIOLIB
select COMMON_CLK
select GENERIC_IRQ_CHIP
select BUILTIN_DTB if MIPS_NO_APPENDED_DTB
select USE_OF
select LIBFDT
config LANTIQ
bool "Lantiq based platforms"
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select CEVT_R4K
select CSRC_R4K
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_MULTITHREADING
MIPS: Fix undefined reference to physical_memsize Since commit d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") switched the default platform to the "generic" platform, allmodconfig has been failing with the following linker error (among other errors): arch/mips/kernel/vpe-mt.o In function `vpe_run': (.text+0x59c): undefined reference to `physical_memsize' The Lantiq platform already worked around the same issue in commit 9050d50e2244 ("MIPS: lantiq: Set physical_memsize") by declaring physical_memsize with the initial value of 0 (on the assumption that the actual memory size will be hard-coded in the loaded VPE firmware), and the Malta platform already provided physical_memsize. Since all other platforms will fail to link with the VPE loader enabled, only allow Lantiq and Malta platforms to enable it, by way of a SYS_SUPPORTS_VPE_LOADER which is selected by those two platforms and which MIPS_VPE_LOADER depends on. SYS_SUPPORTS_MULTITHREADING is now a dependency of SYS_SUPPORTS_VPE_LOADER so that Kconfig emits a warning if SYS_SUPPORTS_VPE_LOADER is selected without SYS_SUPPORTS_MULTITHREADING. Fixes: d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Tested-by: Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.linux-mips.org/patch/18453/
2018-01-16 04:54:35 +08:00
select SYS_SUPPORTS_VPE_LOADER
select SYS_HAS_EARLY_PRINTK
select GPIOLIB
select SWAP_IO_SPACE
select BOOT_RAW
select CLKDEV_LOOKUP
select USE_OF
select PINCTRL
select PINCTRL_LANTIQ
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
config LASAT
bool "LASAT Networks platforms"
select CEVT_R4K
select CRC32
select CSRC_R4K
select DMA_NONCOHERENT
select SYS_HAS_EARLY_PRINTK
select HAVE_PCI
select IRQ_MIPS_CPU
select PCI_GT64XXX_PCI0
select MIPS_NILE4
select R5000_CPU_SCACHE
select SYS_HAS_CPU_R5000
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL if BROKEN
select SYS_SUPPORTS_LITTLE_ENDIAN
config MACH_LOONGSON32
bool "Loongson-1 family of machines"
select SYS_SUPPORTS_ZBOOT
help
This enables support for the Loongson-1 family of machines.
Loongson-1 is a family of 32-bit MIPS-compatible SoCs developed by
the Institute of Computing Technology (ICT), Chinese Academy of
Sciences (CAS).
config MACH_LOONGSON64
bool "Loongson-2/3 family of machines"
select SYS_SUPPORTS_ZBOOT
help
This enables the support of Loongson-2/3 family of machines.
Loongson-2 is a family of single-core CPUs and Loongson-3 is a
family of multi-core CPUs. They are both 64-bit general-purpose
MIPS-compatible CPUs. Loongson-2/3 are developed by the Institute
of Computing Technology (ICT), Chinese Academy of Sciences (CAS)
in the People's Republic of China. The chief architect is Professor
Weiwu Hu.
config MACH_PISTACHIO
bool "IMG Pistachio SoC based boards"
select BOOT_ELF32
select BOOT_RAW
select CEVT_R4K
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CSRC_R4K
select DMA_NONCOHERENT
select GPIOLIB
select IRQ_MIPS_CPU
select LIBFDT
select MFD_SYSCON
select MIPS_CPU_SCACHE
select MIPS_GIC
select PINCTRL
select REGULATOR
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS_CPS
select SYS_SUPPORTS_MULTITHREADING
select SYS_SUPPORTS_RELOCATABLE
select SYS_SUPPORTS_ZBOOT
select SYS_HAS_EARLY_PRINTK
select USE_GENERIC_EARLY_PRINTK_8250
select USE_OF
help
This enables support for the IMG Pistachio SoC platform.
config MIPS_MALTA
bool "MIPS Malta board"
select ARCH_MAY_HAVE_PC_FDC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select BOOT_RAW
select BUILTIN_DTB
select CEVT_R4K
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CSRC_R4K
select DMA_MAYBE_COHERENT
select GENERIC_ISA_DMA
select HAVE_PCSPKR_PLATFORM
select HAVE_PCI
select I8253
select I8259
select IRQ_MIPS_CPU
select LIBFDT
select MIPS_BONITO64
select MIPS_CPU_SCACHE
select MIPS_GIC
select MIPS_L1_CACHE_SHIFT_6
select MIPS_MSC
select PCI_GT64XXX_PCI0
select SMP_UP if SMP
select SWAP_IO_SPACE
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_CPU_MIPS32_R3_5
select SYS_HAS_CPU_MIPS32_R5
select SYS_HAS_CPU_MIPS32_R6
select SYS_HAS_CPU_MIPS64_R1
select SYS_HAS_CPU_MIPS64_R2
select SYS_HAS_CPU_MIPS64_R6
select SYS_HAS_CPU_NEVADA
select SYS_HAS_CPU_RM7000
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MICROMIPS
select SYS_SUPPORTS_MIPS16
select SYS_SUPPORTS_MIPS_CMP
select SYS_SUPPORTS_MIPS_CPS
select SYS_SUPPORTS_MULTITHREADING
select SYS_SUPPORTS_RELOCATABLE
select SYS_SUPPORTS_SMARTMIPS
MIPS: Fix undefined reference to physical_memsize Since commit d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") switched the default platform to the "generic" platform, allmodconfig has been failing with the following linker error (among other errors): arch/mips/kernel/vpe-mt.o In function `vpe_run': (.text+0x59c): undefined reference to `physical_memsize' The Lantiq platform already worked around the same issue in commit 9050d50e2244 ("MIPS: lantiq: Set physical_memsize") by declaring physical_memsize with the initial value of 0 (on the assumption that the actual memory size will be hard-coded in the loaded VPE firmware), and the Malta platform already provided physical_memsize. Since all other platforms will fail to link with the VPE loader enabled, only allow Lantiq and Malta platforms to enable it, by way of a SYS_SUPPORTS_VPE_LOADER which is selected by those two platforms and which MIPS_VPE_LOADER depends on. SYS_SUPPORTS_MULTITHREADING is now a dependency of SYS_SUPPORTS_VPE_LOADER so that Kconfig emits a warning if SYS_SUPPORTS_VPE_LOADER is selected without SYS_SUPPORTS_MULTITHREADING. Fixes: d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Tested-by: Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.linux-mips.org/patch/18453/
2018-01-16 04:54:35 +08:00
select SYS_SUPPORTS_VPE_LOADER
select SYS_SUPPORTS_ZBOOT
select USE_OF
select ZONE_DMA32 if 64BIT
help
This enables support for the MIPS Technologies Malta evaluation
board.
config MACH_PIC32
bool "Microchip PIC32 Family"
help
This enables support for the Microchip PIC32 family of platforms.
Microchip PIC32 is a family of general-purpose 32 bit MIPS core
microcontrollers.
config NEC_MARKEINS
bool "NEC EMMA2RH Mark-eins board"
select SOC_EMMA2RH
select HAVE_PCI
help
This enables support for the NEC Electronics Mark-eins boards.
config MACH_VR41XX
bool "NEC VR4100 series based machines"
select CEVT_R4K
select CSRC_R4K
select SYS_HAS_CPU_VR41XX
select SYS_SUPPORTS_MIPS16
select GPIOLIB
config NXP_STB220
bool "NXP STB220 board"
select SOC_PNX833X
help
Support for NXP Semiconductors STB220 Development Board.
config NXP_STB225
bool "NXP 225 board"
select SOC_PNX833X
select SOC_PNX8335
help
Support for NXP Semiconductors STB225 Development Board.
config PMC_MSP
bool "PMC-Sierra MSP chipsets"
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select SWAP_IO_SPACE
select NO_EXCEPT_FILL
select BOOT_RAW
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_MIPS16
select IRQ_MIPS_CPU
select SERIAL_8250
select SERIAL_8250_CONSOLE
select USB_EHCI_BIG_ENDIAN_MMIO
select USB_EHCI_BIG_ENDIAN_DESC
help
This adds support for the PMC-Sierra family of Multi-Service
Processor System-On-A-Chips. These parts include a number
of integrated peripherals, interfaces and DSPs in addition to
a variety of MIPS cores.
config RALINK
bool "Ralink based machines"
select CEVT_R4K
select CSRC_R4K
select BOOT_RAW
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select USE_OF
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS16
select SYS_HAS_EARLY_PRINTK
select CLKDEV_LOOKUP
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
config SGI_IP22
bool "SGI IP22 (Indy/Indigo2)"
select FW_ARC
select FW_ARC32
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select CEVT_R4K
select CSRC_R4K
select DEFAULT_SGI_PARTITION
select DMA_NONCOHERENT
select HAVE_EISA
select I8253
select I8259
select IP22_CPU_SCACHE
select IRQ_MIPS_CPU
select GENERIC_ISA_DMA_SUPPORT_BROKEN
select SGI_HAS_I8042
select SGI_HAS_INDYDOG
select SGI_HAS_HAL2
select SGI_HAS_SEEQ
select SGI_HAS_WD93
select SGI_HAS_ZILOG
select SWAP_IO_SPACE
select SYS_HAS_CPU_R4X00
select SYS_HAS_CPU_R5000
#
# Disable EARLY_PRINTK for now since it leads to overwritten prom
# memory during early boot on some machines.
#
# See http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20091119164009.GA15038%40deprecation.cyrius.com
# for a more details discussion
#
# select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select MIPS_L1_CACHE_SHIFT_7
help
This are the SGI Indy, Challenge S and Indigo2, as well as certain
OEM variants like the Tandem CMN B006S. To compile a Linux kernel
that runs on these, say Y here.
config SGI_IP27
bool "SGI IP27 (Origin200/2000)"
select ARCH_HAS_PHYS_TO_DMA
select FW_ARC
select FW_ARC64
select BOOT_ELF64
select DEFAULT_SGI_PARTITION
select SYS_HAS_EARLY_PRINTK
select HAVE_PCI
select IRQ_MIPS_CPU
select IRQ_DOMAIN_HIERARCHY
select NR_CPUS_DEFAULT_64
select PCI_DRIVERS_GENERIC
select PCI_XTALK_BRIDGE
select SYS_HAS_CPU_R10000
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_NUMA
select SYS_SUPPORTS_SMP
select MIPS_L1_CACHE_SHIFT_7
help
This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics
workstations. To compile a Linux kernel that runs on these, say Y
here.
config SGI_IP28
bool "SGI IP28 (Indigo2 R10k)"
select FW_ARC
select FW_ARC64
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF64
select CEVT_R4K
select CSRC_R4K
select DEFAULT_SGI_PARTITION
select DMA_NONCOHERENT
select GENERIC_ISA_DMA_SUPPORT_BROKEN
select IRQ_MIPS_CPU
select HAVE_EISA
select I8253
select I8259
select SGI_HAS_I8042
select SGI_HAS_INDYDOG
select SGI_HAS_HAL2
select SGI_HAS_SEEQ
select SGI_HAS_WD93
select SGI_HAS_ZILOG
select SWAP_IO_SPACE
select SYS_HAS_CPU_R10000
#
# Disable EARLY_PRINTK for now since it leads to overwritten prom
# memory during early boot on some machines.
#
# See http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20091119164009.GA15038%40deprecation.cyrius.com
# for a more details discussion
#
# select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select MIPS_L1_CACHE_SHIFT_7
help
This is the SGI Indigo2 with R10000 processor. To compile a Linux
kernel that runs on these, say Y here.
config SGI_IP32
bool "SGI IP32 (O2)"
select ARCH_HAS_PHYS_TO_DMA
select FW_ARC
select FW_ARC32
select BOOT_ELF32
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select HAVE_PCI
select IRQ_MIPS_CPU
select R5000_CPU_SCACHE
select RM7000_CPU_SCACHE
select SYS_HAS_CPU_R5000
select SYS_HAS_CPU_R10000 if BROKEN
select SYS_HAS_CPU_RM7000
select SYS_HAS_CPU_NEVADA
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
help
If you want this kernel to run on SGI O2 workstation, say Y here.
config SIBYTE_CRHINE
bool "Sibyte BCM91120C-CRhine"
select BOOT_ELF32
select SIBYTE_BCM1120
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
config SIBYTE_CARMEL
bool "Sibyte BCM91120x-Carmel"
select BOOT_ELF32
select SIBYTE_BCM1120
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
config SIBYTE_CRHONE
bool "Sibyte BCM91125C-CRhone"
select BOOT_ELF32
select SIBYTE_BCM1125
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
config SIBYTE_RHONE
bool "Sibyte BCM91125E-Rhone"
select BOOT_ELF32
select SIBYTE_BCM1125H
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
config SIBYTE_SWARM
bool "Sibyte BCM91250A-SWARM"
select BOOT_ELF32
select HAVE_PATA_PLATFORM
select SIBYTE_SB1250
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select ZONE_DMA32 if 64BIT
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip DRAM controller that supports memory amounts of up to 16GiB, and due to how the address decoder has been wired in the SOC any memory beyond 1GiB is actually mapped starting from 4GiB physical up, that is beyond the 32-bit addressable limit[1]. Consequently if the maximum amount of memory has been installed, then it will span up to 19GiB. Many of the evaluation boards we support that are based on one of these SOCs have their memory soldered and the amount present fits in the 32-bit address range. The BCM91250A SWARM board however has actual DIMM slots and accepts, depending on the peripherals revision of the SOC, up to 4GiB or 8GiB of memory in commercially available JEDEC modules[2]. I believe this is also the case with the BCM91250C2 LittleSur board. This means that up to either 3GiB or 7GiB of memory requires 64-bit addressing to access. I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead, accepts at least as much memory, although I have no documentation or actual hardware available to verify that. Both systems have PCI slots installed for use by any PCI option boards, including ones that only support 32-bit addressing (additionally the 32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits addressing to 32-bits), and there is no IOMMU available. Therefore for PCI DMA to work in the presence of memory beyond enable swiotlb for the affected systems. All the other SOC onchip DMA devices use 40-bit addressing and therefore can address the whole memory, so only enable swiotlb if PCI support and support for DMA beyond 4GiB have been both enabled in the configuration of the kernel. This shows up as follows: Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2) Board type: SiByte BCM91250A (SWARM) Determined physical RAM map: memory: 000000000fe7fe00 @ 0000000000000000 (usable) memory: 000000001ffffe00 @ 0000000080000000 (usable) memory: 000000000ffffe00 @ 00000000c0000000 (usable) memory: 0000000087fffe00 @ 0000000100000000 (usable) software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB) in the bootstrap log and removes failures like these: defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi0: Receive buffer allocation failed fddi0: Adapter open failed! IP-Config: Failed to open fddi0 defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi1: Receive buffer allocation failed fddi1: Adapter open failed! IP-Config: Failed to open fddi1 when memory beyond 4GiB is handed out to devices that can only do 32-bit addressing. This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32."). References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom Corporation, 18 May 2004, Section 3: "Physical Description", "Supported DRAM", p. 23 Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it] Signed-off-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Patchwork: https://patchwork.linux-mips.org/patch/21108/ References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
2018-11-14 06:42:44 +08:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
config SIBYTE_LITTLESUR
bool "Sibyte BCM91250C2-LittleSur"
select BOOT_ELF32
select HAVE_PATA_PLATFORM
select SIBYTE_SB1250
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select ZONE_DMA32 if 64BIT
config SIBYTE_SENTOSA
bool "Sibyte BCM91250E-Sentosa"
select BOOT_ELF32
select SIBYTE_SB1250
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip DRAM controller that supports memory amounts of up to 16GiB, and due to how the address decoder has been wired in the SOC any memory beyond 1GiB is actually mapped starting from 4GiB physical up, that is beyond the 32-bit addressable limit[1]. Consequently if the maximum amount of memory has been installed, then it will span up to 19GiB. Many of the evaluation boards we support that are based on one of these SOCs have their memory soldered and the amount present fits in the 32-bit address range. The BCM91250A SWARM board however has actual DIMM slots and accepts, depending on the peripherals revision of the SOC, up to 4GiB or 8GiB of memory in commercially available JEDEC modules[2]. I believe this is also the case with the BCM91250C2 LittleSur board. This means that up to either 3GiB or 7GiB of memory requires 64-bit addressing to access. I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead, accepts at least as much memory, although I have no documentation or actual hardware available to verify that. Both systems have PCI slots installed for use by any PCI option boards, including ones that only support 32-bit addressing (additionally the 32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits addressing to 32-bits), and there is no IOMMU available. Therefore for PCI DMA to work in the presence of memory beyond enable swiotlb for the affected systems. All the other SOC onchip DMA devices use 40-bit addressing and therefore can address the whole memory, so only enable swiotlb if PCI support and support for DMA beyond 4GiB have been both enabled in the configuration of the kernel. This shows up as follows: Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2) Board type: SiByte BCM91250A (SWARM) Determined physical RAM map: memory: 000000000fe7fe00 @ 0000000000000000 (usable) memory: 000000001ffffe00 @ 0000000080000000 (usable) memory: 000000000ffffe00 @ 00000000c0000000 (usable) memory: 0000000087fffe00 @ 0000000100000000 (usable) software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB) in the bootstrap log and removes failures like these: defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi0: Receive buffer allocation failed fddi0: Adapter open failed! IP-Config: Failed to open fddi0 defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi1: Receive buffer allocation failed fddi1: Adapter open failed! IP-Config: Failed to open fddi1 when memory beyond 4GiB is handed out to devices that can only do 32-bit addressing. This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32."). References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom Corporation, 18 May 2004, Section 3: "Physical Description", "Supported DRAM", p. 23 Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it] Signed-off-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Patchwork: https://patchwork.linux-mips.org/patch/21108/ References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
2018-11-14 06:42:44 +08:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
config SIBYTE_BIGSUR
bool "Sibyte BCM91480B-BigSur"
select BOOT_ELF32
select NR_CPUS_DEFAULT_4
select SIBYTE_BCM1x80
select SWAP_IO_SPACE
select SYS_HAS_CPU_SB1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select ZONE_DMA32 if 64BIT
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip DRAM controller that supports memory amounts of up to 16GiB, and due to how the address decoder has been wired in the SOC any memory beyond 1GiB is actually mapped starting from 4GiB physical up, that is beyond the 32-bit addressable limit[1]. Consequently if the maximum amount of memory has been installed, then it will span up to 19GiB. Many of the evaluation boards we support that are based on one of these SOCs have their memory soldered and the amount present fits in the 32-bit address range. The BCM91250A SWARM board however has actual DIMM slots and accepts, depending on the peripherals revision of the SOC, up to 4GiB or 8GiB of memory in commercially available JEDEC modules[2]. I believe this is also the case with the BCM91250C2 LittleSur board. This means that up to either 3GiB or 7GiB of memory requires 64-bit addressing to access. I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead, accepts at least as much memory, although I have no documentation or actual hardware available to verify that. Both systems have PCI slots installed for use by any PCI option boards, including ones that only support 32-bit addressing (additionally the 32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits addressing to 32-bits), and there is no IOMMU available. Therefore for PCI DMA to work in the presence of memory beyond enable swiotlb for the affected systems. All the other SOC onchip DMA devices use 40-bit addressing and therefore can address the whole memory, so only enable swiotlb if PCI support and support for DMA beyond 4GiB have been both enabled in the configuration of the kernel. This shows up as follows: Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2) Board type: SiByte BCM91250A (SWARM) Determined physical RAM map: memory: 000000000fe7fe00 @ 0000000000000000 (usable) memory: 000000001ffffe00 @ 0000000080000000 (usable) memory: 000000000ffffe00 @ 00000000c0000000 (usable) memory: 0000000087fffe00 @ 0000000100000000 (usable) software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB) in the bootstrap log and removes failures like these: defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi0: Receive buffer allocation failed fddi0: Adapter open failed! IP-Config: Failed to open fddi0 defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0 fddi1: Receive buffer allocation failed fddi1: Adapter open failed! IP-Config: Failed to open fddi1 when memory beyond 4GiB is handed out to devices that can only do 32-bit addressing. This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32."). References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom Corporation, 18 May 2004, Section 3: "Physical Description", "Supported DRAM", p. 23 Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it] Signed-off-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Patchwork: https://patchwork.linux-mips.org/patch/21108/ References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
2018-11-14 06:42:44 +08:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
config SNI_RM
bool "SNI RM200/300/400"
select FW_ARC if CPU_LITTLE_ENDIAN
select FW_ARC32 if CPU_LITTLE_ENDIAN
select FW_SNIPROM if CPU_BIG_ENDIAN
select ARCH_MAY_HAVE_PC_FDC
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select BOOT_ELF32
select CEVT_R4K
select CSRC_R4K
select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN
select DMA_NONCOHERENT
select GENERIC_ISA_DMA
select HAVE_EISA
select HAVE_PCSPKR_PLATFORM
select HAVE_PCI
select IRQ_MIPS_CPU
select I8253
select I8259
select ISA
select SWAP_IO_SPACE if CPU_BIG_ENDIAN
select SYS_HAS_CPU_R4X00
select SYS_HAS_CPU_R5000
select SYS_HAS_CPU_R10000
select R5000_CPU_SCACHE
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
help
The SNI RM200/300/400 are MIPS-based machines manufactured by
Siemens Nixdorf Informationssysteme (SNI), parent company of Pyramid
Technology and now in turn merged with Fujitsu. Say Y here to
support this machine type.
config MACH_TX39XX
bool "Toshiba TX39 series based machines"
config MACH_TX49XX
bool "Toshiba TX49 series based machines"
config MIKROTIK_RB532
bool "Mikrotik RB532 boards"
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select HAVE_PCI
select IRQ_MIPS_CPU
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SWAP_IO_SPACE
select BOOT_RAW
select GPIOLIB
select MIPS_L1_CACHE_SHIFT_4
help
Support the Mikrotik(tm) RouterBoard 532 series,
based on the IDT RC32434 SoC.
config CAVIUM_OCTEON_SOC
bool "Cavium Networks Octeon SoC based boards"
select CEVT_R4K
select ARCH_HAS_PHYS_TO_DMA
select HAVE_RAPIDIO
select PHYS_ADDR_T_64BIT
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select EDAC_SUPPORT
EDAC: Cleanup atomic_scrub mess So first of all, this atomic_scrub() function's naming is bad. It looks like an atomic_t helper. Change it to edac_atomic_scrub(). The bigger problem is that this function is arch-specific and every new arch which doesn't necessarily need that functionality still needs to define it, otherwise EDAC doesn't compile. So instead of doing that and including arch-specific headers, have each arch define an EDAC_ATOMIC_SCRUB symbol which can be used in edac_mc.c for ifdeffery. Much cleaner. And we already are doing this with another symbol - EDAC_SUPPORT. This is also much cleaner than having CONFIG_EDAC enumerate all the arches which need/have EDAC support and drivers. This way I can kill the useless edac.h header in tile too. Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Chris Metcalf <cmetcalf@ezchip.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Doug Thompson <dougthompson@xmission.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-edac@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org Cc: "Maciej W. Rozycki" <macro@codesourcery.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Paul Mackerras <paulus@samba.org> Cc: "Steven J. Hill" <Steven.Hill@imgtec.com> Cc: x86@kernel.org Signed-off-by: Borislav Petkov <bp@suse.de>
2015-05-22 01:59:31 +08:00
select EDAC_ATOMIC_SCRUB
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HOTPLUG_CPU if CPU_BIG_ENDIAN
select SYS_HAS_EARLY_PRINTK
select SYS_HAS_CPU_CAVIUM_OCTEON
select HAVE_PCI
select ZONE_DMA32
select HOLES_IN_ZONE
select GPIOLIB
select LIBFDT
select USE_OF
select ARCH_SPARSEMEM_ENABLE
select SYS_SUPPORTS_SMP
select NR_CPUS_DEFAULT_64
select MIPS_NR_CPU_NR_MAP_1024
select BUILTIN_DTB
select MTD_COMPLEX_MAPPINGS
select SWIOTLB
select SYS_SUPPORTS_RELOCATABLE
help
This option supports all of the Octeon reference boards from Cavium
Networks. It builds a kernel that dynamically determines the Octeon
CPU type and supports all known board reference implementations.
Some of the supported boards are:
EBT3000
EBH3000
EBH3100
Thunder
Kodama
Hikari
Say Y here for most Octeon reference boards.
config NLM_XLR_BOARD
bool "Netlogic XLR/XLS based systems"
select BOOT_ELF32
select NLM_COMMON
select SYS_HAS_CPU_XLR
select SYS_SUPPORTS_SMP
select HAVE_PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select PHYS_ADDR_T_64BIT
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select NR_CPUS_DEFAULT_32
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
select ZONE_DMA32 if 64BIT
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_ZBOOT
select SYS_SUPPORTS_ZBOOT_UART16550
help
Support for systems based on Netlogic XLR and XLS processors.
Say Y here if you have a XLR or XLS based board.
config NLM_XLP_BOARD
bool "Netlogic XLP based systems"
select BOOT_ELF32
select NLM_COMMON
select SYS_HAS_CPU_XLP
select SYS_SUPPORTS_SMP
select HAVE_PCI
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select PHYS_ADDR_T_64BIT
select GPIOLIB
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select NR_CPUS_DEFAULT_32
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
select ZONE_DMA32 if 64BIT
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
select USE_OF
select SYS_SUPPORTS_ZBOOT
select SYS_SUPPORTS_ZBOOT_UART16550
help
This board is based on Netlogic XLP Processor.
Say Y here if you have a XLP based board.
config MIPS_PARAVIRT
bool "Para-Virtualized guest system"
select CEVT_R4K
select CSRC_R4K
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_SMP
select NR_CPUS_DEFAULT_4
select SYS_HAS_EARLY_PRINTK
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_CPU_MIPS64_R2
select SYS_HAS_CPU_CAVIUM_OCTEON
select HAVE_PCI
select SWAP_IO_SPACE
help
This option supports guest running under ????
endchoice
source "arch/mips/alchemy/Kconfig"
source "arch/mips/ath25/Kconfig"
source "arch/mips/ath79/Kconfig"
source "arch/mips/bcm47xx/Kconfig"
source "arch/mips/bcm63xx/Kconfig"
source "arch/mips/bmips/Kconfig"
source "arch/mips/generic/Kconfig"
source "arch/mips/jazz/Kconfig"
source "arch/mips/jz4740/Kconfig"
source "arch/mips/lantiq/Kconfig"
source "arch/mips/lasat/Kconfig"
source "arch/mips/pic32/Kconfig"
source "arch/mips/pistachio/Kconfig"
source "arch/mips/pmcs-msp71xx/Kconfig"
source "arch/mips/ralink/Kconfig"
source "arch/mips/sgi-ip27/Kconfig"
source "arch/mips/sibyte/Kconfig"
source "arch/mips/txx9/Kconfig"
source "arch/mips/vr41xx/Kconfig"
source "arch/mips/cavium-octeon/Kconfig"
source "arch/mips/loongson32/Kconfig"
source "arch/mips/loongson64/Kconfig"
source "arch/mips/netlogic/Kconfig"
source "arch/mips/paravirt/Kconfig"
endmenu
config GENERIC_HWEIGHT
bool
default y
config GENERIC_CALIBRATE_DELAY
bool
default y
config SCHED_OMIT_FRAME_POINTER
bool
default y
#
# Select some configuration options automatically based on user selections.
#
config FW_ARC
bool
config ARCH_MAY_HAVE_PC_FDC
bool
config BOOT_RAW
bool
config CEVT_BCM1480
bool
config CEVT_DS1287
bool
config CEVT_GT641XX
bool
config CEVT_R4K
bool
config CEVT_SB1250
bool
config CEVT_TXX9
bool
config CSRC_BCM1480
bool
config CSRC_IOASIC
bool
config CSRC_R4K
bool
config CSRC_SB1250
bool
MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() Add user-mode implementations of gettimeofday() and clock_gettime() to the VDSO. This is currently usable with 2 clocksources: the CP0 count register, which is accessible to user-mode via RDHWR on R2 and later cores, or the MIPS Global Interrupt Controller (GIC) timer, which provides a "user-mode visible" section containing a mirror of its counter registers. This section must be mapped into user memory, which is done below the VDSO data page. When a supported clocksource is not in use, the VDSO functions will return -ENOSYS, which causes libc to fall back on the standard syscall path. When support for neither of these clocksources is compiled into the kernel at all, the VDSO still provides clock_gettime(), as the coarse realtime/monotonic clocks can still be implemented. However, gettimeofday() is not provided in this case as nothing can be done without a suitable clocksource. This causes the symbol lookup to fail in libc and it will then always use the standard syscall path. This patch includes a workaround for a bug in QEMU which results in RDHWR on the CP0 count register always returning a constant (incorrect) value. A fix for this has been submitted, and the workaround can be removed after the fix has been in stable releases for a reasonable amount of time. A simple performance test which calls gettimeofday() 1000 times in a loop and calculates the average execution time gives the following results on a Malta + I6400 (running at 20MHz): - Syscall: ~31000 ns - VDSO (GIC): ~15000 ns - VDSO (CP0): ~9500 ns [markos.chandras@imgtec.com: - Minor code re-arrangements in order for mappings to be made in the order they appear to the process' address space. - Move do_{monotonic, realtime} outside of the MIPS_CLOCK_VSYSCALL ifdef - Use gic_get_usm_range so we can do the GIC mapping in the arch/mips/kernel/vdso instead of the GIC irqchip driver] Signed-off-by: Alex Smith <alex.smith@imgtec.com> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11338/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-21 16:57:44 +08:00
config MIPS_CLOCK_VSYSCALL
def_bool CSRC_R4K || CLKSRC_MIPS_GIC
config GPIO_TXX9
select GPIOLIB
bool
config FW_CFE
bool
config ARCH_SUPPORTS_UPROBES
bool
config DMA_MAYBE_COHERENT
select ARCH_HAS_DMA_COHERENCE_H
select DMA_NONCOHERENT
bool
config DMA_PERDEV_COHERENT
bool
select ARCH_HAS_SETUP_DMA_OPS
select DMA_NONCOHERENT
config DMA_NONCOHERENT
bool
select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_HAS_UNCACHED_SEGMENT
select NEED_DMA_MAP_STATE
select ARCH_HAS_DMA_COHERENT_TO_PFN
select DMA_NONCOHERENT_CACHE_SYNC
config SYS_HAS_EARLY_PRINTK
bool
config SYS_SUPPORTS_HOTPLUG_CPU
bool
config MIPS_BONITO64
bool
config MIPS_MSC
bool
config MIPS_NILE4
bool
config SYNC_R4K
bool
config MIPS_MACHINE
def_bool n
config NO_IOPORT_MAP
def_bool n
config GENERIC_CSUM
bool
default y if !CPU_HAS_LOAD_STORE_LR
config GENERIC_ISA_DMA
bool
select ZONE_DMA if GENERIC_ISA_DMA_SUPPORT_BROKEN=n
select ISA_DMA_API
config GENERIC_ISA_DMA_SUPPORT_BROKEN
bool
select GENERIC_ISA_DMA
config ISA_DMA_API
bool
config HOLES_IN_ZONE
bool
config SYS_SUPPORTS_RELOCATABLE
bool
help
Selected if the platform supports relocating the kernel.
The platform must provide plat_get_fdt() if it selects CONFIG_USE_OF
to allow access to command line and entropy sources.
config MIPS_CBPF_JIT
def_bool y
depends on BPF_JIT && HAVE_CBPF_JIT
config MIPS_EBPF_JIT
def_bool y
depends on BPF_JIT && HAVE_EBPF_JIT
#
# Endianness selection. Sufficiently obscure so many users don't know what to
# answer,so we try hard to limit the available choices. Also the use of a
# choice statement should be more obvious to the user.
#
choice
prompt "Endianness selection"
help
Some MIPS machines can be configured for either little or big endian
byte order. These modes require different kernels and a different
Linux distribution. In general there is one preferred byteorder for a
particular system but some systems are just as commonly used in the
one or the other endianness.
config CPU_BIG_ENDIAN
bool "Big endian"
depends on SYS_SUPPORTS_BIG_ENDIAN
config CPU_LITTLE_ENDIAN
bool "Little endian"
depends on SYS_SUPPORTS_LITTLE_ENDIAN
endchoice
config EXPORT_UASM
bool
config SYS_SUPPORTS_APM_EMULATION
bool
config SYS_SUPPORTS_BIG_ENDIAN
bool
config SYS_SUPPORTS_LITTLE_ENDIAN
bool
config SYS_SUPPORTS_HUGETLBFS
bool
depends on CPU_SUPPORTS_HUGEPAGES && 64BIT
default y
config MIPS_HUGE_TLB_SUPPORT
def_bool HUGETLB_PAGE || TRANSPARENT_HUGEPAGE
config IRQ_CPU_RM7K
bool
config IRQ_MSP_SLP
bool
config IRQ_MSP_CIC
bool
config IRQ_TXX9
bool
config IRQ_GT641XX
bool
config PCI_GT64XXX_PCI0
bool
config PCI_XTALK_BRIDGE
bool
config NO_EXCEPT_FILL
bool
config SOC_EMMA2RH
bool
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select SWAP_IO_SPACE
select SYS_HAS_CPU_R5500
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
config SOC_PNX833X
bool
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
select DMA_NONCOHERENT
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_MIPS16
select CPU_MIPSR2_IRQ_VI
config SOC_PNX8335
bool
select SOC_PNX833X
config MIPS_SPRAM
bool
config SWAP_IO_SPACE
bool
config SGI_HAS_INDYDOG
bool
config SGI_HAS_HAL2
bool
config SGI_HAS_SEEQ
bool
config SGI_HAS_WD93
bool
config SGI_HAS_ZILOG
bool
config SGI_HAS_I8042
bool
config DEFAULT_SGI_PARTITION
bool
config FW_ARC32
bool
config FW_SNIPROM
bool
config BOOT_ELF32
bool
config MIPS_L1_CACHE_SHIFT_4
bool
config MIPS_L1_CACHE_SHIFT_5
bool
config MIPS_L1_CACHE_SHIFT_6
bool
config MIPS_L1_CACHE_SHIFT_7
bool
config MIPS_L1_CACHE_SHIFT
int
default "7" if MIPS_L1_CACHE_SHIFT_7
default "6" if MIPS_L1_CACHE_SHIFT_6
default "5" if MIPS_L1_CACHE_SHIFT_5
default "4" if MIPS_L1_CACHE_SHIFT_4
default "5"
config HAVE_STD_PC_SERIAL_PORT
bool
config ARC_CONSOLE
bool "ARC console support"
depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN)
config ARC_MEMORY
bool
depends on MACH_JAZZ || SNI_RM || SGI_IP32
default y
config ARC_PROMLIB
bool
depends on MACH_JAZZ || SNI_RM || SGI_IP22 || SGI_IP28 || SGI_IP32
default y
config FW_ARC64
bool
config BOOT_ELF64
bool
menu "CPU selection"
choice
prompt "CPU type"
default CPU_R4X00
config CPU_LOONGSON3
bool "Loongson 3 CPU"
depends on SYS_HAS_CPU_LOONGSON3
select ARCH_HAS_PHYS_TO_DMA
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
select MIPS_PGD_C0_CONTEXT
select MIPS_L1_CACHE_SHIFT_6
select GPIOLIB
select SWIOTLB
help
The Loongson 3 processor implements the MIPS64R2 instruction
set with many extensions.
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1, Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB, L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast TLB refill support, etc. This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to enable those enhancements which are not probed at run time. If you want a generic kernel to run on all Loongson 3 machines, please say 'N' here. If you want a high-performance kernel to run on new Loongson 3 machines only, please say 'Y' here. Some additional explanations: 1) SFB locates between core and L1 cache, it causes memory access out of order, so writel/outl (and other similar functions) need a I/O reorder barrier. 2) Loongson 3 has a bug that di instruction can not save the irqflag, so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di at all. 3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch. Signed-off-by: Huacai Chen <chenhc@lemote.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Steven J . Hill <sjhill@realitydiluted.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12755/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 09:45:13 +08:00
config LOONGSON3_ENHANCEMENT
bool "New Loongson 3 CPU Enhancements"
default n
select CPU_MIPSR2
select CPU_HAS_PREFETCH
depends on CPU_LOONGSON3
help
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A
R1, Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as
FTLB, L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User
Local register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer),
Fast TLB refill support, etc.
This option enable those enhancements which are not probed at run
time. If you want a generic kernel to run on all Loongson 3 machines,
please say 'N' here. If you want a high-performance kernel to run on
new Loongson 3 machines only, please say 'Y' here.
MIPS: Loongson: Introduce and use loongson_llsc_mb() On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and lld/scd is very weak ordering. We should add sync instructions "before each ll/lld" and "at the branch-target between ll/sc" to workaround. Otherwise, this flaw will cause deadlock occasionally (e.g. when doing heavy load test with LTP). Below is the explaination of CPU designer: "For Loongson 3 family, when a memory access instruction (load, store, or prefetch)'s executing occurs between the execution of LL and SC, the success or failure of SC is not predictable. Although programmer would not insert memory access instructions between LL and SC, the memory instructions before LL in program-order, may dynamically executed between the execution of LL/SC, so a memory fence (SYNC) is needed before LL/LLD to avoid this situation. Since Loongson-3A R2 (3A2000), we have improved our hardware design to handle this case. But we later deduce a rarely circumstance that some speculatively executed memory instructions due to branch misprediction between LL/SC still fall into the above case, so a memory fence (SYNC) at branch-target (if its target is not between LL/SC) is needed for Loongson 3A1000, 3B1500, 3A2000 and 3A3000. Our processor is continually evolving and we aim to to remove all these workaround-SYNCs around LL/SC for new-come processor." Here is an example: Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var, this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same time('sc' return 1), and the variable is only *added by 1*, sometimes, which is wrong and unacceptable(it should be added by 2). Why disable fix-loongson3-llsc in compiler? Because compiler fix will cause problems in kernel's __ex_table section. This patch fix all the cases in kernel, but: +. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix the ll and branch-target coincidently such as atomic_sub_if_positive/ cmpxchg/xchg, just like this one. +. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch edac.h +. local_ops and cmpxchg_local should not be affected by this bug since only the owner can write. +. mips_atomic_set for syscall.c is deprecated and rarely used, just let it go Signed-off-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Huang Pei <huangpei@loongson.cn> [paul.burton@mips.com: - Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add a comment describing why it's there. - Make loongson_llsc_mb() a no-op when CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory barrier. - Add a comment describing the bug & how loongson_llsc_mb() helps in asm/barrier.h.] Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: ambrosehua@gmail.com Cc: Steven J . Hill <Steven.Hill@cavium.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: Li Xuefeng <lixuefeng@loongson.cn> Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 16:04:54 +08:00
config CPU_LOONGSON3_WORKAROUNDS
bool "Old Loongson 3 LLSC Workarounds"
default y if SMP
depends on CPU_LOONGSON3
help
Loongson 3 processors have the llsc issues which require workarounds.
Without workarounds the system may hang unexpectedly.
Newer Loongson 3 will fix these issues and no workarounds are needed.
The workarounds have no significant side effect on them but may
decrease the performance of the system so this option should be
disabled unless the kernel is intended to be run on old systems.
If unsure, please say Y.
config CPU_LOONGSON2E
bool "Loongson 2E"
depends on SYS_HAS_CPU_LOONGSON2E
select CPU_LOONGSON2
help
The Loongson 2E processor implements the MIPS III instruction set
with many extensions.
It has an internal FPGA northbridge, which is compatible to
bonito64.
config CPU_LOONGSON2F
bool "Loongson 2F"
depends on SYS_HAS_CPU_LOONGSON2F
select CPU_LOONGSON2
select GPIOLIB
help
The Loongson 2F processor implements the MIPS III instruction set
with many extensions.
Loongson2F have built-in DDR2 and PCIX controller. The PCIX controller
have a similar programming interface with FPGA northbridge used in
Loongson2E.
config CPU_LOONGSON1B
bool "Loongson 1B"
depends on SYS_HAS_CPU_LOONGSON1B
select CPU_LOONGSON1
select LEDS_GPIO_REGISTER
help
The Loongson 1B is a 32-bit SoC, which implements the MIPS32
Release 1 instruction set and part of the MIPS32 Release 2
instruction set.
config CPU_LOONGSON1C
bool "Loongson 1C"
depends on SYS_HAS_CPU_LOONGSON1C
select CPU_LOONGSON1
select LEDS_GPIO_REGISTER
help
The Loongson 1C is a 32-bit SoC, which implements the MIPS32
Release 1 instruction set and part of the MIPS32 Release 2
instruction set.
config CPU_MIPS32_R1
bool "MIPS32 Release 1"
depends on SYS_HAS_CPU_MIPS32_R1
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
help
Choose this option to build a kernel for release 1 or later of the
MIPS32 architecture. Most modern embedded systems with a 32-bit
MIPS processor are based on a MIPS32 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
Release 2 of the MIPS32 architecture is available since several
years so chances are you even have a MIPS32 Release 2 processor
in which case you should choose CPU_MIPS32_R2 instead for better
performance.
config CPU_MIPS32_R2
bool "MIPS32 Release 2"
depends on SYS_HAS_CPU_MIPS32_R2
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_MSA
select HAVE_KVM
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture. Most modern embedded systems with a 32-bit
MIPS processor are based on a MIPS32 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
config CPU_MIPS32_R6
bool "MIPS32 Release 6"
depends on SYS_HAS_CPU_MIPS32_R6
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_MSA
select HAVE_KVM
select MIPS_O32_FP64_SUPPORT
help
Choose this option to build a kernel for release 6 or later of the
MIPS32 architecture. New MIPS processors, starting with the Warrior
family, are based on a MIPS32r6 processor. If you own an older
processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
config CPU_MIPS64_R1
bool "MIPS64 Release 1"
depends on SYS_HAS_CPU_MIPS64_R1
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
help
Choose this option to build a kernel for release 1 or later of the
MIPS64 architecture. Many modern embedded systems with a 64-bit
MIPS processor are based on a MIPS64 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
Release 2 of the MIPS64 architecture is available since several
years so chances are you even have a MIPS64 Release 2 processor
in which case you should choose CPU_MIPS64_R2 instead for better
performance.
config CPU_MIPS64_R2
bool "MIPS64 Release 2"
depends on SYS_HAS_CPU_MIPS64_R2
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select CPU_SUPPORTS_MSA
select HAVE_KVM
help
Choose this option to build a kernel for release 2 or later of the
MIPS64 architecture. Many modern embedded systems with a 64-bit
MIPS processor are based on a MIPS64 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
config CPU_MIPS64_R6
bool "MIPS64 Release 6"
depends on SYS_HAS_CPU_MIPS64_R6
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select CPU_SUPPORTS_MSA
select MIPS_O32_FP64_SUPPORT if 32BIT || MIPS32_O32
select HAVE_KVM
help
Choose this option to build a kernel for release 6 or later of the
MIPS64 architecture. New MIPS processors, starting with the Warrior
family, are based on a MIPS64r6 processor. If you own an older
processor, you probably need to select MIPS64r1 or MIPS64r2 instead.
config CPU_R3000
bool "R3000"
depends on SYS_HAS_CPU_R3000
select CPU_HAS_WB
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
help
Please make sure to pick the right CPU type. Linux/MIPS is not
designed to be generic, i.e. Kernels compiled for R3000 CPUs will
*not* work on R4000 machines and vice versa. However, since most
of the supported machines have an R4000 (or similar) CPU, R4x00
might be a safe bet. If the resulting kernel does not work,
try to recompile with R3000.
config CPU_TX39XX
bool "R39XX"
depends on SYS_HAS_CPU_TX39XX
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_HAS_LOAD_STORE_LR
config CPU_VR41XX
bool "R41xx"
depends on SYS_HAS_CPU_VR41XX
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_HAS_LOAD_STORE_LR
help
The options selects support for the NEC VR4100 series of processors.
Only choose this option if you have one of these processors as a
kernel built with this option will not run on any other type of
processor or vice versa.
config CPU_R4300
bool "R4300"
depends on SYS_HAS_CPU_R4300
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_HAS_LOAD_STORE_LR
help
MIPS Technologies R4300-series processors.
config CPU_R4X00
bool "R4x00"
depends on SYS_HAS_CPU_R4X00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
help
MIPS Technologies R4000-series processors other than 4300, including
the R4000, R4400, R4600, and 4700.
config CPU_TX49XX
bool "R49XX"
depends on SYS_HAS_CPU_TX49XX
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
config CPU_R5000
bool "R5000"
depends on SYS_HAS_CPU_R5000
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
help
MIPS Technologies R5000-series processors other than the Nevada.
config CPU_R5432
bool "R5432"
depends on SYS_HAS_CPU_R5432
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
config CPU_R5500
bool "R5500"
depends on SYS_HAS_CPU_R5500
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
help
NEC VR5500 and VR5500A series processors implement 64-bit MIPS IV
instruction set.
config CPU_NEVADA
bool "RM52xx"
depends on SYS_HAS_CPU_NEVADA
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HUGEPAGES
select CPU_HAS_LOAD_STORE_LR
help
QED / PMC-Sierra RM52xx-series ("Nevada") processors.
config CPU_R8000
bool "R8000"
depends on SYS_HAS_CPU_R8000
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_64BIT_KERNEL
help
MIPS Technologies R8000 processors. Note these processors are
uncommon and the support for them is incomplete.
config CPU_R10000
bool "R10000"
depends on SYS_HAS_CPU_R10000
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
help
MIPS Technologies R10000-series processors.
config CPU_RM7000
bool "RM7000"
depends on SYS_HAS_CPU_RM7000
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
config CPU_SB1
bool "SB1"
depends on SYS_HAS_CPU_SB1
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select WEAK_ORDERING
config CPU_CAVIUM_OCTEON
bool "Cavium Octeon processor"
depends on SYS_HAS_CPU_CAVIUM_OCTEON
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_64BIT_KERNEL
select WEAK_ORDERING
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select MIPS_L1_CACHE_SHIFT_7
select HAVE_KVM
help
The Cavium Octeon processor is a highly integrated chip containing
many ethernet hardware widgets for networking tasks. The processor
can have up to 16 Mips64v2 cores and 8 integrated gigabit ethernets.
Full details can be found at http://www.caviumnetworks.com.
config CPU_BMIPS
bool "Broadcom BMIPS"
depends on SYS_HAS_CPU_BMIPS
select CPU_MIPS32
select CPU_BMIPS32_3300 if SYS_HAS_CPU_BMIPS32_3300
select CPU_BMIPS4350 if SYS_HAS_CPU_BMIPS4350
select CPU_BMIPS4380 if SYS_HAS_CPU_BMIPS4380
select CPU_BMIPS5000 if SYS_HAS_CPU_BMIPS5000
select CPU_SUPPORTS_32BIT_KERNEL
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select SWAP_IO_SPACE
select WEAK_ORDERING
select CPU_SUPPORTS_HIGHMEM
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_CPUFREQ
select MIPS_EXTERNAL_TIMER
help
Support for BMIPS32/3300/4350/4380 and BMIPS5000 processors.
config CPU_XLR
bool "Netlogic XLR SoC"
depends on SYS_HAS_CPU_XLR
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
help
Netlogic Microsystems XLR/XLS processors.
config CPU_XLP
bool "Netlogic XLP SoC"
depends on SYS_HAS_CPU_XLP
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_MIPSR2
select CPU_SUPPORTS_HUGEPAGES
select MIPS_ASID_BITS_VARIABLE
help
Netlogic Microsystems XLP processors.
endchoice
config CPU_MIPS32_3_5_FEATURES
bool "MIPS32 Release 3.5 Features"
depends on SYS_HAS_CPU_MIPS32_R3_5
depends on CPU_MIPS32_R2 || CPU_MIPS32_R6
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from the 3.5 release such as
support for Enhanced Virtual Addressing (EVA).
config CPU_MIPS32_3_5_EVA
bool "Enhanced Virtual Addressing (EVA)"
depends on CPU_MIPS32_3_5_FEATURES
select EVA
default y
help
Choose this option if you want to enable the Enhanced Virtual
Addressing (EVA) on your MIPS32 core (such as proAptiv).
One of its primary benefits is an increase in the maximum size
of lowmem (up to 3GB). If unsure, say 'N' here.
config CPU_MIPS32_R5_FEATURES
bool "MIPS32 Release 5 Features"
depends on SYS_HAS_CPU_MIPS32_R5
depends on CPU_MIPS32_R2
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from release 5 such as
support for Extended Physical Addressing (XPA).
config CPU_MIPS32_R5_XPA
bool "Extended Physical Addressing (XPA)"
depends on CPU_MIPS32_R5_FEATURES
depends on !EVA
depends on !PAGE_SIZE_4KB
depends on SYS_SUPPORTS_HIGHMEM
select XPA
select HIGHMEM
select PHYS_ADDR_T_64BIT
default n
help
Choose this option if you want to enable the Extended Physical
Addressing (XPA) on your MIPS32 core (such as P5600 series). The
benefit is to increase physical addressing equal to or greater
than 40 bits. Note that this has the side effect of turning on
64-bit addressing which in turn makes the PTEs 64-bit in size.
If unsure, say 'N' here.
if CPU_LOONGSON2F
config CPU_NOP_WORKAROUNDS
bool
config CPU_JUMP_WORKAROUNDS
bool
config CPU_LOONGSON2F_WORKAROUNDS
bool "Loongson 2F Workarounds"
default y
select CPU_NOP_WORKAROUNDS
select CPU_JUMP_WORKAROUNDS
help
Loongson 2F01 / 2F02 processors have the NOP & JUMP issues which
require workarounds. Without workarounds the system may hang
unexpectedly. For more information please refer to the gas
-mfix-loongson2f-nop and -mfix-loongson2f-jump options.
Loongson 2F03 and later have fixed these issues and no workarounds
are needed. The workarounds have no significant side effect on them
but may decrease the performance of the system so this option should
be disabled unless the kernel is intended to be run on 2F01 or 2F02
systems.
If unsure, please say Y.
endif # CPU_LOONGSON2F
config SYS_SUPPORTS_ZBOOT
bool
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
select HAVE_KERNEL_XZ
config SYS_SUPPORTS_ZBOOT_UART16550
bool
select SYS_SUPPORTS_ZBOOT
config SYS_SUPPORTS_ZBOOT_UART_PROM
bool
select SYS_SUPPORTS_ZBOOT
config CPU_LOONGSON2
bool
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select ARCH_HAS_PHYS_TO_DMA
select CPU_HAS_LOAD_STORE_LR
config CPU_LOONGSON1
bool
select CPU_MIPS32
select CPU_MIPSR2
select CPU_HAS_PREFETCH
select CPU_HAS_LOAD_STORE_LR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_CPUFREQ
config CPU_BMIPS32_3300
select SMP_UP if SMP
bool
config CPU_BMIPS4350
bool
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
config CPU_BMIPS4380
bool
select MIPS_L1_CACHE_SHIFT_6
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
select CPU_HAS_RIXI
config CPU_BMIPS5000
bool
select MIPS_CPU_SCACHE
select MIPS_L1_CACHE_SHIFT_7
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
select CPU_HAS_RIXI
config SYS_HAS_CPU_LOONGSON3
bool
select CPU_SUPPORTS_CPUFREQ
select CPU_HAS_RIXI
config SYS_HAS_CPU_LOONGSON2E
bool
config SYS_HAS_CPU_LOONGSON2F
bool
select CPU_SUPPORTS_CPUFREQ
select CPU_SUPPORTS_ADDRWINCFG if 64BIT
select CPU_SUPPORTS_UNCACHED_ACCELERATED
config SYS_HAS_CPU_LOONGSON1B
bool
config SYS_HAS_CPU_LOONGSON1C
bool
config SYS_HAS_CPU_MIPS32_R1
bool
config SYS_HAS_CPU_MIPS32_R2
bool
config SYS_HAS_CPU_MIPS32_R3_5
bool
config SYS_HAS_CPU_MIPS32_R5
bool
MIPS: Don't select ARCH_HAS_SYNC_DMA_FOR_CPU when DMA is coherent Commit f263f2a2c682 ("MIPS: Compile post DMA flush only when needed") pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which cpu_needs_post_dma_flush() might return true, but unfortunately missed the fact that some of these CPUs can be used in configurations with DMA_NONCOHERENT=n. When this is the case the kernel build does not include our definition of arch_sync_dma_for_cpu() from arch/mips/mm/dma-noncoherent.c and the build fails with a link error. One example of this problem is ip27_defconfig: kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu': direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu': direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_alloc': direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc' kernel/dma/direct.o: In function `dma_direct_free': direct.c:(.text+0xc3c): undefined reference to `arch_dma_free' make[1]: *** [Makefile:1021: vmlinux] Error 1 make: *** [Makefile:152: sub-make] Error 2 Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left as-is because systems with that CPU always select DMA_NONCOHERENT anyway. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: f263f2a2c682 ("MIPS: Compile post DMA flush only when needed")
2019-02-05 05:52:58 +08:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
config SYS_HAS_CPU_MIPS32_R6
bool
MIPS: Don't select ARCH_HAS_SYNC_DMA_FOR_CPU when DMA is coherent Commit f263f2a2c682 ("MIPS: Compile post DMA flush only when needed") pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which cpu_needs_post_dma_flush() might return true, but unfortunately missed the fact that some of these CPUs can be used in configurations with DMA_NONCOHERENT=n. When this is the case the kernel build does not include our definition of arch_sync_dma_for_cpu() from arch/mips/mm/dma-noncoherent.c and the build fails with a link error. One example of this problem is ip27_defconfig: kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu': direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu': direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_alloc': direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc' kernel/dma/direct.o: In function `dma_direct_free': direct.c:(.text+0xc3c): undefined reference to `arch_dma_free' make[1]: *** [Makefile:1021: vmlinux] Error 1 make: *** [Makefile:152: sub-make] Error 2 Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left as-is because systems with that CPU always select DMA_NONCOHERENT anyway. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: f263f2a2c682 ("MIPS: Compile post DMA flush only when needed")
2019-02-05 05:52:58 +08:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
config SYS_HAS_CPU_MIPS64_R1
bool
config SYS_HAS_CPU_MIPS64_R2
bool
config SYS_HAS_CPU_MIPS64_R6
bool
MIPS: Don't select ARCH_HAS_SYNC_DMA_FOR_CPU when DMA is coherent Commit f263f2a2c682 ("MIPS: Compile post DMA flush only when needed") pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which cpu_needs_post_dma_flush() might return true, but unfortunately missed the fact that some of these CPUs can be used in configurations with DMA_NONCOHERENT=n. When this is the case the kernel build does not include our definition of arch_sync_dma_for_cpu() from arch/mips/mm/dma-noncoherent.c and the build fails with a link error. One example of this problem is ip27_defconfig: kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu': direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu': direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_alloc': direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc' kernel/dma/direct.o: In function `dma_direct_free': direct.c:(.text+0xc3c): undefined reference to `arch_dma_free' make[1]: *** [Makefile:1021: vmlinux] Error 1 make: *** [Makefile:152: sub-make] Error 2 Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left as-is because systems with that CPU always select DMA_NONCOHERENT anyway. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: f263f2a2c682 ("MIPS: Compile post DMA flush only when needed")
2019-02-05 05:52:58 +08:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
config SYS_HAS_CPU_R3000
bool
config SYS_HAS_CPU_TX39XX
bool
config SYS_HAS_CPU_VR41XX
bool
config SYS_HAS_CPU_R4300
bool
config SYS_HAS_CPU_R4X00
bool
config SYS_HAS_CPU_TX49XX
bool
config SYS_HAS_CPU_R5000
bool
config SYS_HAS_CPU_R5432
bool
config SYS_HAS_CPU_R5500
bool
config SYS_HAS_CPU_NEVADA
bool
config SYS_HAS_CPU_R8000
bool
config SYS_HAS_CPU_R10000
bool
MIPS: Don't select ARCH_HAS_SYNC_DMA_FOR_CPU when DMA is coherent Commit f263f2a2c682 ("MIPS: Compile post DMA flush only when needed") pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which cpu_needs_post_dma_flush() might return true, but unfortunately missed the fact that some of these CPUs can be used in configurations with DMA_NONCOHERENT=n. When this is the case the kernel build does not include our definition of arch_sync_dma_for_cpu() from arch/mips/mm/dma-noncoherent.c and the build fails with a link error. One example of this problem is ip27_defconfig: kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu': direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu': direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu' kernel/dma/direct.o: In function `dma_direct_alloc': direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc' kernel/dma/direct.o: In function `dma_direct_free': direct.c:(.text+0xc3c): undefined reference to `arch_dma_free' make[1]: *** [Makefile:1021: vmlinux] Error 1 make: *** [Makefile:152: sub-make] Error 2 Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left as-is because systems with that CPU always select DMA_NONCOHERENT anyway. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: f263f2a2c682 ("MIPS: Compile post DMA flush only when needed")
2019-02-05 05:52:58 +08:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
config SYS_HAS_CPU_RM7000
bool
config SYS_HAS_CPU_SB1
bool
config SYS_HAS_CPU_CAVIUM_OCTEON
bool
config SYS_HAS_CPU_BMIPS
bool
config SYS_HAS_CPU_BMIPS32_3300
bool
select SYS_HAS_CPU_BMIPS
config SYS_HAS_CPU_BMIPS4350
bool
select SYS_HAS_CPU_BMIPS
config SYS_HAS_CPU_BMIPS4380
bool
select SYS_HAS_CPU_BMIPS
config SYS_HAS_CPU_BMIPS5000
bool
select SYS_HAS_CPU_BMIPS
select ARCH_HAS_SYNC_DMA_FOR_CPU
config SYS_HAS_CPU_XLR
bool
config SYS_HAS_CPU_XLP
bool
#
# CPU may reorder R->R, R->W, W->R, W->W
# Reordering beyond LL and SC is handled in WEAK_REORDERING_BEYOND_LLSC
#
config WEAK_ORDERING
bool
#
# CPU may reorder reads and writes beyond LL/SC
# CPU may reorder R->LL, R->LL, W->LL, W->LL, R->SC, R->SC, W->SC, W->SC
#
config WEAK_REORDERING_BEYOND_LLSC
bool
endmenu
#
# These two indicate any level of the MIPS32 and MIPS64 architecture
#
config CPU_MIPS32
bool
default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R6
config CPU_MIPS64
bool
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R6
#
# These indicate the revision of the architecture
#
config CPU_MIPSR1
bool
default y if CPU_MIPS32_R1 || CPU_MIPS64_R1
config CPU_MIPSR2
bool
default y if CPU_MIPS32_R2 || CPU_MIPS64_R2 || CPU_CAVIUM_OCTEON
select CPU_HAS_RIXI
select MIPS_SPRAM
config CPU_MIPSR6
bool
default y if CPU_MIPS32_R6 || CPU_MIPS64_R6
select CPU_HAS_RIXI
select HAVE_ARCH_BITREVERSE
select MIPS_ASID_BITS_VARIABLE
select MIPS_CRC_SUPPORT
select MIPS_SPRAM
config TARGET_ISA_REV
int
default 1 if CPU_MIPSR1
default 2 if CPU_MIPSR2
default 6 if CPU_MIPSR6
default 0
help
Reflects the ISA revision being targeted by the kernel build. This
is effectively the Kconfig equivalent of MIPS_ISA_REV.
config EVA
bool
config XPA
bool
config SYS_SUPPORTS_32BIT_KERNEL
bool
config SYS_SUPPORTS_64BIT_KERNEL
bool
config CPU_SUPPORTS_32BIT_KERNEL
bool
config CPU_SUPPORTS_64BIT_KERNEL
bool
config CPU_SUPPORTS_CPUFREQ
bool
config CPU_SUPPORTS_ADDRWINCFG
bool
config CPU_SUPPORTS_HUGEPAGES
bool
depends on !(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))
config CPU_SUPPORTS_UNCACHED_ACCELERATED
bool
config MIPS_PGD_C0_CONTEXT
bool
default y if 64BIT && (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLP
#
# Set to y for ptrace access to watch registers.
#
config HARDWARE_WATCHPOINTS
bool
default y if CPU_MIPSR1 || CPU_MIPSR2 || CPU_MIPSR6
menu "Kernel type"
choice
prompt "Kernel code model"
help
You should only select this option if you have a workload that
actually benefits from 64-bit processing or if your machine has
large memory. You will only be presented a single option in this
menu if your system does not support both 32-bit and 64-bit kernels.
config 32BIT
bool "32-bit kernel"
depends on CPU_SUPPORTS_32BIT_KERNEL && SYS_SUPPORTS_32BIT_KERNEL
select TRAD_SIGNALS
help
Select this option if you want to build a 32-bit kernel.
config 64BIT
bool "64-bit kernel"
depends on CPU_SUPPORTS_64BIT_KERNEL && SYS_SUPPORTS_64BIT_KERNEL
help
Select this option if you want to build a 64-bit kernel.
endchoice
config KVM_GUEST
bool "KVM Guest Kernel"
depends on BROKEN_ON_SMP
help
Select this option if building a guest kernel for KVM (Trap & Emulate)
mode.
config KVM_GUEST_TIMER_FREQ
int "Count/Compare Timer Frequency (MHz)"
depends on KVM_GUEST
default 100
help
Set this to non-zero if building a guest kernel for KVM to skip RTC
emulation when determining guest CPU Frequency. Instead, the guest's
timer frequency is specified directly.
config MIPS_VA_BITS_48
bool "48 bits virtual memory"
depends on 64BIT
help
Support a maximum at least 48 bits of application virtual
memory. Default is 40 bits or less, depending on the CPU.
For page sizes 16k and above, this option results in a small
memory overhead for page tables. For 4k page size, a fourth
level of page tables is added which imposes both a memory
overhead as well as slower TLB fault handling.
If unsure, say N.
choice
prompt "Kernel page size"
default PAGE_SIZE_4KB
config PAGE_SIZE_4KB
bool "4kB"
depends on !CPU_LOONGSON2 && !CPU_LOONGSON3
help
This option select the standard 4kB Linux page size. On some
R3000-family processors this is the only available page size. Using
4kB page size will minimize memory consumption and is therefore
recommended for low memory systems.
config PAGE_SIZE_8KB
bool "8kB"
depends on CPU_R8000 || CPU_CAVIUM_OCTEON
depends on !MIPS_VA_BITS_48
help
Using 8kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available
only on R8000 and cnMIPS processors. Note that you will need a
suitable Linux distribution to support this.
config PAGE_SIZE_16KB
bool "16kB"
depends on !CPU_R3000 && !CPU_TX39XX
help
Using 16kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available on
all non-R3000 family processors. Note that you will need a suitable
Linux distribution to support this.
config PAGE_SIZE_32KB
bool "32kB"
depends on CPU_CAVIUM_OCTEON
depends on !MIPS_VA_BITS_48
help
Using 32kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available
only on cnMIPS cores. Note that you will need a suitable Linux
distribution to support this.
config PAGE_SIZE_64KB
bool "64kB"
depends on !CPU_R3000 && !CPU_TX39XX
help
Using 64kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available on
all non-R3000 family processor. Not that at the time of this
writing this option is still high experimental.
endchoice
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
range 14 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_64KB
default "14" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_64KB
range 13 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_32KB
default "13" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_32KB
range 12 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_16KB
default "12" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_16KB
range 11 64
default "11"
help
The kernel memory allocator divides physically contiguous memory
blocks into "zones", where each zone is a power of two number of
pages. This option selects the largest power of two that the kernel
keeps in the memory allocator. If you need to allocate very large
blocks of physically contiguous memory, then you may need to
increase this value.
This config option is actually maximum order plus one. For example,
a value of 11 means that the largest free memory block is 2^10 pages.
The page size is not necessarily 4KB. Keep this in mind
when choosing a value for this option.
config BOARD_SCACHE
bool
config IP22_CPU_SCACHE
bool
select BOARD_SCACHE
#
# Support for a MIPS32 / MIPS64 style S-caches
#
config MIPS_CPU_SCACHE
bool
select BOARD_SCACHE
config R5000_CPU_SCACHE
bool
select BOARD_SCACHE
config RM7000_CPU_SCACHE
bool
select BOARD_SCACHE
config SIBYTE_DMA_PAGEOPS
bool "Use DMA to clear/copy pages"
depends on CPU_SB1
help
Instead of using the CPU to zero and copy pages, use a Data Mover
channel. These DMA channels are otherwise unused by the standard
SiByte Linux port. Seems to give a small performance benefit.
config CPU_HAS_PREFETCH
bool
config CPU_GENERIC_DUMP_TLB
bool
default y if !(CPU_R3000 || CPU_R8000 || CPU_TX39XX)
config MIPS_FP_SUPPORT
bool "Floating Point support" if EXPERT
default y
help
Select y to include support for floating point in the kernel
including initialization of FPU hardware, FP context save & restore
and emulation of an FPU where necessary. Without this support any
userland program attempting to use floating point instructions will
receive a SIGILL.
If you know that your userland will not attempt to use floating point
instructions then you can say n here to shrink the kernel a little.
If unsure, say y.
config CPU_R2300_FPU
bool
depends on MIPS_FP_SUPPORT
default y if CPU_R3000 || CPU_TX39XX
config CPU_R4K_FPU
bool
depends on MIPS_FP_SUPPORT
default y if !CPU_R2300_FPU
config CPU_R4K_CACHE_TLB
bool
default y if !(CPU_R3000 || CPU_R8000 || CPU_SB1 || CPU_TX39XX || CPU_CAVIUM_OCTEON)
config MIPS_MT_SMP
bool "MIPS MT SMP support (1 TC on each available VPE)"
default y
depends on SYS_SUPPORTS_MULTITHREADING && !CPU_MIPSR6 && !CPU_MICROMIPS
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
select SYNC_R4K
select MIPS_MT
select SMP
select SMP_UP
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_SCHED_SMT
select MIPS_PERF_SHARED_TC_COUNTERS
help
This is a kernel model which is known as SMVP. This is supported
on cores with the MT ASE and uses the available VPEs to implement
virtual processors which supports SMP. This is equivalent to the
Intel Hyperthreading feature. For further information go to
<http://www.imgtec.com/mips/mips-multithreading.asp>.
config MIPS_MT
bool
config SCHED_SMT
bool "SMT (multithreading) scheduler support"
depends on SYS_SUPPORTS_SCHED_SMT
default n
help
SMT scheduler support improves the CPU scheduler's decision making
when dealing with MIPS MT enabled cores at a cost of slightly
increased overhead in some places. If unsure say N here.
config SYS_SUPPORTS_SCHED_SMT
bool
config SYS_SUPPORTS_MULTITHREADING
bool
config MIPS_MT_FPAFF
bool "Dynamic FPU affinity for FP-intensive threads"
default y
depends on MIPS_MT_SMP
config MIPSR2_TO_R6_EMULATOR
bool "MIPS R2-to-R6 emulator"
depends on CPU_MIPSR6
depends on MIPS_FP_SUPPORT
default y
help
Choose this option if you want to run non-R6 MIPS userland code.
Even if you say 'Y' here, the emulator will still be disabled by
default. You can enable it using the 'mipsr2emu' kernel option.
The only reason this is a build-time option is to save ~14K from the
final kernel image.
MIPS: Fix undefined reference to physical_memsize Since commit d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") switched the default platform to the "generic" platform, allmodconfig has been failing with the following linker error (among other errors): arch/mips/kernel/vpe-mt.o In function `vpe_run': (.text+0x59c): undefined reference to `physical_memsize' The Lantiq platform already worked around the same issue in commit 9050d50e2244 ("MIPS: lantiq: Set physical_memsize") by declaring physical_memsize with the initial value of 0 (on the assumption that the actual memory size will be hard-coded in the loaded VPE firmware), and the Malta platform already provided physical_memsize. Since all other platforms will fail to link with the VPE loader enabled, only allow Lantiq and Malta platforms to enable it, by way of a SYS_SUPPORTS_VPE_LOADER which is selected by those two platforms and which MIPS_VPE_LOADER depends on. SYS_SUPPORTS_MULTITHREADING is now a dependency of SYS_SUPPORTS_VPE_LOADER so that Kconfig emits a warning if SYS_SUPPORTS_VPE_LOADER is selected without SYS_SUPPORTS_MULTITHREADING. Fixes: d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Tested-by: Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.linux-mips.org/patch/18453/
2018-01-16 04:54:35 +08:00
config SYS_SUPPORTS_VPE_LOADER
bool
depends on SYS_SUPPORTS_MULTITHREADING
help
Indicates that the platform supports the VPE loader, and provides
physical_memsize.
config MIPS_VPE_LOADER
bool "VPE loader support."
MIPS: Fix undefined reference to physical_memsize Since commit d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") switched the default platform to the "generic" platform, allmodconfig has been failing with the following linker error (among other errors): arch/mips/kernel/vpe-mt.o In function `vpe_run': (.text+0x59c): undefined reference to `physical_memsize' The Lantiq platform already worked around the same issue in commit 9050d50e2244 ("MIPS: lantiq: Set physical_memsize") by declaring physical_memsize with the initial value of 0 (on the assumption that the actual memory size will be hard-coded in the loaded VPE firmware), and the Malta platform already provided physical_memsize. Since all other platforms will fail to link with the VPE loader enabled, only allow Lantiq and Malta platforms to enable it, by way of a SYS_SUPPORTS_VPE_LOADER which is selected by those two platforms and which MIPS_VPE_LOADER depends on. SYS_SUPPORTS_MULTITHREADING is now a dependency of SYS_SUPPORTS_VPE_LOADER so that Kconfig emits a warning if SYS_SUPPORTS_VPE_LOADER is selected without SYS_SUPPORTS_MULTITHREADING. Fixes: d41e6858ba58 ("MIPS: Kconfig: Set default MIPS system type as generic") Signed-off-by: James Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: John Crispin <john@phrozen.org> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-mips@linux-mips.org Tested-by: Guenter Roeck <linux@roeck-us.net> Patchwork: https://patchwork.linux-mips.org/patch/18453/
2018-01-16 04:54:35 +08:00
depends on SYS_SUPPORTS_VPE_LOADER && MODULES
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
select MIPS_MT
help
Includes a loader for loading an elf relocatable object
onto another VPE and running it.
config MIPS_VPE_LOADER_CMP
bool
default "y"
depends on MIPS_VPE_LOADER && MIPS_CMP
config MIPS_VPE_LOADER_MT
bool
default "y"
depends on MIPS_VPE_LOADER && !MIPS_CMP
config MIPS_VPE_LOADER_TOM
bool "Load VPE program into memory hidden from linux"
depends on MIPS_VPE_LOADER
default y
help
The loader can use memory that is present but has been hidden from
Linux using the kernel command line option "mem=xxMB". It's up to
you to ensure the amount you put in the option and the space your
program requires is less or equal to the amount physically present.
config MIPS_VPE_APSP_API
bool "Enable support for AP/SP API (RTLX)"
depends on MIPS_VPE_LOADER
config MIPS_VPE_APSP_API_CMP
bool
default "y"
depends on MIPS_VPE_APSP_API && MIPS_CMP
config MIPS_VPE_APSP_API_MT
bool
default "y"
depends on MIPS_VPE_APSP_API && !MIPS_CMP
config MIPS_CMP
bool "MIPS CMP framework support (DEPRECATED)"
depends on SYS_SUPPORTS_MIPS_CMP && !CPU_MIPSR6
select SMP
select SYNC_R4K
select SYS_SUPPORTS_SMP
select WEAK_ORDERING
default n
help
Select this if you are using a bootloader which implements the "CMP
framework" protocol (ie. YAMON) and want your kernel to make use of
its ability to start secondary CPUs.
Unless you have a specific need, you should use CONFIG_MIPS_CPS
instead of this.
config MIPS_CPS
bool "MIPS Coherent Processing System support"
depends on SYS_SUPPORTS_MIPS_CPS
select MIPS_CM
select MIPS_CPS_PM if HOTPLUG_CPU
select SMP
select SYNC_R4K if (CEVT_R4K || CSRC_R4K)
select SYS_SUPPORTS_HOTPLUG_CPU
select SYS_SUPPORTS_SCHED_SMT if CPU_MIPSR6
select SYS_SUPPORTS_SMP
select WEAK_ORDERING
help
Select this if you wish to run an SMP kernel across multiple cores
within a MIPS Coherent Processing System. When this option is
enabled the kernel will probe for other cores and boot them with
no external assistance. It is safe to enable this when hardware
support is unavailable.
2014-04-14 18:00:56 +08:00
config MIPS_CPS_PM
depends on MIPS_CPS
2014-04-14 18:00:56 +08:00
bool
config MIPS_CM
bool
select MIPS_CPC
config MIPS_CPC
bool
config SB1_PASS_2_WORKAROUNDS
bool
depends on CPU_SB1 && (CPU_SB1_PASS_2_2 || CPU_SB1_PASS_2)
default y
config SB1_PASS_2_1_WORKAROUNDS
bool
depends on CPU_SB1 && CPU_SB1_PASS_2
default y
choice
prompt "SmartMIPS or microMIPS ASE support"
config CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS
bool "None"
help
Select this if you want neither microMIPS nor SmartMIPS support
config CPU_HAS_SMARTMIPS
depends on SYS_SUPPORTS_SMARTMIPS
bool "SmartMIPS"
help
SmartMIPS is a extension of the MIPS32 architecture aimed at
increased security at both hardware and software level for
smartcards. Enabling this option will allow proper use of the
SmartMIPS instructions by Linux applications. However a kernel with
this option will not work on a MIPS core without SmartMIPS core. If
you don't know you probably don't have SmartMIPS and should say N
here.
config CPU_MICROMIPS
depends on 32BIT && SYS_SUPPORTS_MICROMIPS && !CPU_MIPSR6
bool "microMIPS"
help
When this option is enabled the kernel will be built using the
microMIPS ISA
endchoice
config CPU_HAS_MSA
bool "Support for the MIPS SIMD Architecture"
depends on CPU_SUPPORTS_MSA
depends on MIPS_FP_SUPPORT
depends on 64BIT || MIPS_O32_FP64_SUPPORT
help
MIPS SIMD Architecture (MSA) introduces 128 bit wide vector registers
and a set of SIMD instructions to operate on them. When this option
is enabled the kernel will support allocating & switching MSA
vector register contexts. If you know that your kernel will only be
running on CPUs which do not support MSA or that your userland will
not be making use of it then you may wish to say N here to reduce
the size & complexity of your kernel.
If unsure, say Y.
config CPU_HAS_WB
bool
config XKS01
bool
config CPU_HAS_RIXI
bool
config CPU_HAS_LOAD_STORE_LR
bool
help
CPU has support for unaligned load and store instructions:
LWL, LWR, SWL, SWR (Load/store word left/right).
LDL, LDR, SDL, SDR (Load/store doubleword left/right, for 64bit systems).
#
# Vectored interrupt mode is an R2 feature
#
config CPU_MIPSR2_IRQ_VI
bool
#
# Extended interrupt mode is an R2 feature
#
config CPU_MIPSR2_IRQ_EI
bool
config CPU_HAS_SYNC
bool
depends on !CPU_R3000
default y
[MIPS] R4000/R4400 errata workarounds This is the gereric part of R4000/R4400 errata workarounds. They include compiler and assembler support as well as some source code modifications to address the problems with some combinations of multiply/divide+shift instructions as well as the daddi and daddiu instructions. Changes included are as follows: 1. New Kconfig options to select workarounds by platforms as necessary. 2. Arch top-level Makefile to pass necessary options to the compiler; also incompatible configurations are detected (-mno-sym32 unsupported as horribly intrusive for little gain). 3. Bug detection updated and shuffled -- the multiply/divide+shift problem is lethal enough that if not worked around it makes the kernel crash in time_init() because of a division by zero; the daddiu erratum might also trigger early potentially, though I have not observed it. On the other hand the daddi detection code requires the exception subsystem to have been initialised (and is there mainly for information). 4. r4k_daddiu_bug() added so that the existence of the erratum can be queried by code at the run time as necessary; useful for generated code like TLB fault and copy/clear page handlers. 5. __udelay() updated as it uses multiplication in inline assembly. Note that -mdaddi requires modified toolchain (which has been maintained by myself and available from my site for ~4years now -- versions covered are GCC 2.95.4 - 4.1.2 and binutils from 2.13 onwards). The -mfix-r4000 and -mfix-r4400 have been standard for a while though. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-10-23 19:43:11 +08:00
#
# CPU non-features
#
config CPU_DADDI_WORKAROUNDS
bool
config CPU_R4000_WORKAROUNDS
bool
select CPU_R4400_WORKAROUNDS
config CPU_R4400_WORKAROUNDS
bool
config MIPS_ASID_SHIFT
int
default 6 if CPU_R3000 || CPU_TX39XX
default 4 if CPU_R8000
default 0
config MIPS_ASID_BITS
int
default 0 if MIPS_ASID_BITS_VARIABLE
default 6 if CPU_R3000 || CPU_TX39XX
default 8
config MIPS_ASID_BITS_VARIABLE
bool
config MIPS_CRC_SUPPORT
bool
#
# - Highmem only makes sense for the 32-bit kernel.
# - The current highmem code will only work properly on physically indexed
# caches such as R3000, SB1, R7000 or those that look like they're virtually
# indexed such as R4000/R4400 SC and MC versions or R10000. So for the
# moment we protect the user and offer the highmem option only on machines
# where it's known to be safe. This will not offer highmem on a few systems
# such as MIPS32 and MIPS64 CPUs which may have virtual and physically
# indexed CPUs but we're playing safe.
# - We use SYS_SUPPORTS_HIGHMEM to offer highmem only for systems where we
# know they might have memory configurations that could make use of highmem
# support.
#
config HIGHMEM
bool "High Memory Support"
depends on 32BIT && CPU_SUPPORTS_HIGHMEM && SYS_SUPPORTS_HIGHMEM && !CPU_MIPS32_3_5_EVA
config CPU_SUPPORTS_HIGHMEM
bool
config SYS_SUPPORTS_HIGHMEM
bool
config SYS_SUPPORTS_SMARTMIPS
bool
config SYS_SUPPORTS_MICROMIPS
bool
config SYS_SUPPORTS_MIPS16
bool
help
This option must be set if a kernel might be executed on a MIPS16-
enabled CPU even if MIPS16 is not actually being used. In other
words, it makes the kernel MIPS16-tolerant.
config CPU_SUPPORTS_MSA
bool
config ARCH_FLATMEM_ENABLE
def_bool y
depends on !NUMA && !CPU_LOONGSON2
config ARCH_DISCONTIGMEM_ENABLE
bool
default y if SGI_IP27
help
Say Y to support efficient handling of discontiguous physical memory,
for architectures which are either NUMA (Non-Uniform Memory Access)
or have huge holes in the physical address space for other reasons.
See <file:Documentation/vm/numa.rst> for more.
config ARCH_SPARSEMEM_ENABLE
bool
select SPARSEMEM_STATIC
config NUMA
bool "NUMA Support"
depends on SYS_SUPPORTS_NUMA
help
Say Y to compile the kernel to support NUMA (Non-Uniform Memory
Access). This option improves performance on systems with more
than two nodes; on two node systems it is generally better to
leave it disabled; on single node systems disable this option
disabled.
config SYS_SUPPORTS_NUMA
bool
config RELOCATABLE
bool "Relocatable kernel"
depends on SYS_SUPPORTS_RELOCATABLE && (CPU_MIPS32_R2 || CPU_MIPS64_R2 || CPU_MIPS32_R6 || CPU_MIPS64_R6 || CAVIUM_OCTEON_SOC)
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
The relocations make the kernel binary about 15% larger,
but are discarded at runtime
config RELOCATION_TABLE_SIZE
hex "Relocation table size"
depends on RELOCATABLE
range 0x0 0x01000000
default "0x00100000"
---help---
A table of relocation data will be appended to the kernel binary
and parsed at boot to fix up the relocated kernel.
This option allows the amount of space reserved for the table to be
adjusted, although the default of 1Mb should be ok in most cases.
The build will fail and a valid size suggested if this is too small.
If unsure, leave at the default value.
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image"
depends on RELOCATABLE
---help---
Randomizes the physical and virtual address at which the
kernel image is loaded, as a security feature that
deters exploit attempts relying on knowledge of the location
of kernel internals.
Entropy is generated using any coprocessor 0 registers available.
The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET.
If unsure, say N.
config RANDOMIZE_BASE_MAX_OFFSET
hex "Maximum kASLR offset" if EXPERT
depends on RANDOMIZE_BASE
range 0x0 0x40000000 if EVA || 64BIT
range 0x0 0x08000000
default "0x01000000"
---help---
When kASLR is active, this provides the maximum offset that will
be applied to the kernel image. It should be set according to the
amount of physical RAM available in the target system minus
PHYSICAL_START and must be a power of 2.
This is limited by the size of KSEG0, 256Mb on 32-bit or 1Gb with
EVA or 64-bit. The default is 16Mb.
[PATCH] Configurable NODES_SHIFT Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for each arch. Its definition is sometimes configurable. Indeed, ia64 defines 5 NODES_SHIFT values in the current git tree. But it looks a bit messy. SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has been changeable by config. Suitable node's number may be changed in the future even if it is other architecture. So, I wrote configurable node's number. This patch set defines just default value for each arch which needs multi nodes except ia64. But, it is easy to change to configurable if necessary. On ia64 the number of nodes can be already configured in generic ia64 and SN2 config. But, NODES_SHIFT is defined for DIG64 and HP'S machine too. So, I changed it so that all platforms can be configured via CONFIG_NODES_SHIFT. It would be simpler. See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2 Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jack Steiner <steiner@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 13:53:53 +08:00
config NODES_SHIFT
int
default "6"
depends on NEED_MULTIPLE_NODES
config HW_PERF_EVENTS
bool "Enable hardware performance counter support for perf events"
depends on PERF_EVENTS && !OPROFILE && (CPU_MIPS32 || CPU_MIPS64 || CPU_R10000 || CPU_SB1 || CPU_CAVIUM_OCTEON || CPU_XLP || CPU_LOONGSON3)
default y
help
Enable hardware performance counter support for perf events. If
disabled, perf events will use software events only.
config SMP
bool "Multi-Processing support"
depends on SYS_SUPPORTS_SMP
help
This enables support for systems with more than one CPU. If you have
a system with only one CPU, say N. If you have a system with more
than one CPU, say Y.
If you say N here, the kernel will run on uni- and multiprocessor
machines, but will use only one CPU of a multiprocessor machine. If
you say Y here, the kernel will run on many, but not all,
uniprocessor machines. On a uniprocessor machine, the kernel
will run faster if you say N here.
People using multiprocessor machines who say Y here should also say
Y to "Enhanced Real Time Clock Support", below.
See also the SMP-HOWTO available at
<http://www.tldp.org/docs.html#howto>.
If you don't know what to do here, say N.
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP && SYS_SUPPORTS_HOTPLUG_CPU
help
Say Y here to allow turning CPUs off and on. CPUs can be
controlled through /sys/devices/system/cpu.
(Note: power management support will enable this option
automatically on SMP systems. )
Say N if you want to disable CPU hotplug.
config SMP_UP
bool
config SYS_SUPPORTS_MIPS_CMP
bool
config SYS_SUPPORTS_MIPS_CPS
bool
config SYS_SUPPORTS_SMP
bool
config NR_CPUS_DEFAULT_4
bool
config NR_CPUS_DEFAULT_8
bool
config NR_CPUS_DEFAULT_16
bool
config NR_CPUS_DEFAULT_32
bool
config NR_CPUS_DEFAULT_64
bool
config NR_CPUS
int "Maximum number of CPUs (2-256)"
range 2 256
depends on SMP
default "4" if NR_CPUS_DEFAULT_4
default "8" if NR_CPUS_DEFAULT_8
default "16" if NR_CPUS_DEFAULT_16
default "32" if NR_CPUS_DEFAULT_32
default "64" if NR_CPUS_DEFAULT_64
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 32 for 32-bit
kernel and 64 for 64-bit kernels; the minimum value which makes
sense is 1 for Qemu (useful only for kernel debugging purposes)
and 2 for all others.
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image. For best
performance should round up your number of processors to the next
power of two.
config MIPS_PERF_SHARED_TC_COUNTERS
bool
config MIPS_NR_CPU_NR_MAP_1024
bool
config MIPS_NR_CPU_NR_MAP
int
depends on SMP
default 1024 if MIPS_NR_CPU_NR_MAP_1024
default NR_CPUS if !MIPS_NR_CPU_NR_MAP_1024
#
# Timer Interrupt Frequency Configuration
#
choice
prompt "Timer frequency"
default HZ_250
help
Allows the configuration of the timer frequency.
config HZ_24
bool "24 HZ" if SYS_SUPPORTS_24HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_48
bool "48 HZ" if SYS_SUPPORTS_48HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_100
bool "100 HZ" if SYS_SUPPORTS_100HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_128
bool "128 HZ" if SYS_SUPPORTS_128HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_250
bool "250 HZ" if SYS_SUPPORTS_250HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_256
bool "256 HZ" if SYS_SUPPORTS_256HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_1000
bool "1000 HZ" if SYS_SUPPORTS_1000HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_1024
bool "1024 HZ" if SYS_SUPPORTS_1024HZ || SYS_SUPPORTS_ARBIT_HZ
endchoice
config SYS_SUPPORTS_24HZ
bool
config SYS_SUPPORTS_48HZ
bool
config SYS_SUPPORTS_100HZ
bool
config SYS_SUPPORTS_128HZ
bool
config SYS_SUPPORTS_250HZ
bool
config SYS_SUPPORTS_256HZ
bool
config SYS_SUPPORTS_1000HZ
bool
config SYS_SUPPORTS_1024HZ
bool
config SYS_SUPPORTS_ARBIT_HZ
bool
default y if !SYS_SUPPORTS_24HZ && \
!SYS_SUPPORTS_48HZ && \
!SYS_SUPPORTS_100HZ && \
!SYS_SUPPORTS_128HZ && \
!SYS_SUPPORTS_250HZ && \
!SYS_SUPPORTS_256HZ && \
!SYS_SUPPORTS_1000HZ && \
!SYS_SUPPORTS_1024HZ
config HZ
int
default 24 if HZ_24
default 48 if HZ_48
default 100 if HZ_100
default 128 if HZ_128
default 250 if HZ_250
default 256 if HZ_256
default 1000 if HZ_1000
default 1024 if HZ_1024
config SCHED_HRTICK
def_bool HIGH_RES_TIMERS
config KEXEC
bool "Kexec system call"
2015-09-10 06:38:55 +08:00
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
but it is independent of the system firmware. And like a reboot
you can start any kernel with it, not just Linux.
The name comes from the similarity to the exec system call.
It is an ongoing process to be certain the hardware in a machine
is properly shutdown, so do not be surprised if this code does not
initially work for you. As of this writing the exact hardware
interface is strongly in flux, so no good recommendation can be
made.
config CRASH_DUMP
bool "Kernel crash dumps"
help
Generate crash dump after being started by kexec.
This should be normally only set in special crash dump kernels
which are loaded in the main kernel with kexec-tools into
a specially reserved region and then later executed after
a crash by kdump/kexec. The crash dump kernel must be compiled
to a memory address not used by the main kernel or firmware using
PHYSICAL_START.
config PHYSICAL_START
hex "Physical address where the kernel is loaded"
default "0xffffffff84000000"
depends on CRASH_DUMP
help
This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
If you plan to use kernel for capturing the crash dump change
this value to start of the reserved region (the "X" value as
specified in the "crashkernel=YM@XM" command line boot parameter
passed to the panic-ed kernel).
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
execution. By using pipes or other transports made available to
the process as file descriptors supporting the read/write
syscalls, it's possible to isolate those applications in
their own address space using seccomp. Once seccomp is
enabled via /proc/<pid>/seccomp, it cannot be disabled
and the task is only allowed to execute a few safe syscalls
defined by each seccomp mode.
If unsure, say Y. Only embedded should say N here.
config MIPS_O32_FP64_SUPPORT
bool "Support for O32 binaries using 64-bit FP" if !CPU_MIPSR6
depends on 32BIT || MIPS32_O32
help
When this is enabled, the kernel will support use of 64-bit floating
point registers with binaries using the O32 ABI along with the
EF_MIPS_FP64 ELF header flag (typically built with -mfp64). On
32-bit MIPS systems this support is at the cost of increasing the
size and complexity of the compiled FPU emulator. Thus if you are
running a MIPS32 system and know that none of your userland binaries
will require 64-bit floating point, you may wish to reduce the size
of your kernel & potentially improve FP emulation performance by
saying N here.
MIPS: mark O32+FP64 experimental for now Commit 597ce1723e0f "MIPS: Support for 64-bit FP with O32 binaries" introduced support for setting Status.FR=1 for O32 binaries with the EF_MIPS_FP64 ELF header flag set. Whilst this flag is currently supported by binutils it does introduce an ABI break within userland. Objects built with EF_MIPS_FP64 cannot be safely linked with those built without it since code in either object may assume behaviour specific to a value of FR. More recently there has been discussion around avoiding further fragmentation of the O32 ABI whilst still allowing the use of FR=1 and features such as MSA which depend upon it. Details of the plan to allow this are still being worked on, and whilst the kernel will need the ability to handle FR=1 with O32 tasks it is unclear what else it may need to provide to a userland which seeks to avoid another ABI break. In order to prevent the proliferation of userland which may rely upon the current EF_MIPS_FP64 behaviour this patch marks the kernel support for it experimental & disables it by default. Under current proposals it is likely that this support can simply be enabled again later, but possibly after the introduction of further interfaces with userland and support for the MIPS R5 UFR feature. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Matthew Fortune <matthew.fortune@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Paul Burton <paul.burton@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/6549/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-02-15 01:55:18 +08:00
Although binutils currently supports use of this flag the details
concerning its effect upon the O32 ABI in userland are still being
worked on. In order to avoid userland becoming dependant upon current
behaviour before the details have been finalised, this option should
be considered experimental and only enabled by those working upon
said details.
If unsure, say N.
config USE_OF
bool
select OF
select OF_EARLY_FLATTREE
select IRQ_DOMAIN
config UHI_BOOT
bool
config BUILTIN_DTB
bool
choice
prompt "Kernel appended dtb support" if USE_OF
default MIPS_NO_APPENDED_DTB
config MIPS_NO_APPENDED_DTB
bool "None"
help
Do not enable appended dtb support.
config MIPS_ELF_APPENDED_DTB
bool "vmlinux"
help
With this option, the boot code will look for a device tree binary
DTB) included in the vmlinux ELF section .appended_dtb. By default
it is empty and the DTB can be appended using binutils command
objcopy:
objcopy --update-section .appended_dtb=<filename>.dtb vmlinux
This is meant as a backward compatiblity convenience for those
systems with a bootloader that can't be upgraded to accommodate
the documented boot protocol using a device tree.
config MIPS_RAW_APPENDED_DTB
bool "vmlinux.bin or vmlinuz.bin"
help
With this option, the boot code will look for a device tree binary
DTB) appended to raw vmlinux.bin or vmlinuz.bin.
(e.g. cat vmlinux.bin <filename>.dtb > vmlinux_w_dtb).
This is meant as a backward compatibility convenience for those
systems with a bootloader that can't be upgraded to accommodate
the documented boot protocol using a device tree.
Beware that there is very little in terms of protection against
this option being confused by leftover garbage in memory that might
look like a DTB header after a reboot if no actual DTB is appended
to vmlinux.bin. Do not leave this option active in a production kernel
if you don't intend to always append a DTB.
endchoice
choice
prompt "Kernel command line type" if !CMDLINE_OVERRIDE
default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \
!MIPS_MALTA && \
!CAVIUM_OCTEON_SOC
default MIPS_CMDLINE_FROM_BOOTLOADER
config MIPS_CMDLINE_FROM_DTB
depends on USE_OF
bool "Dtb kernel arguments if available"
config MIPS_CMDLINE_DTB_EXTEND
depends on USE_OF
bool "Extend dtb kernel arguments with bootloader arguments"
config MIPS_CMDLINE_FROM_BOOTLOADER
bool "Bootloader kernel arguments if available"
config MIPS_CMDLINE_BUILTIN_EXTEND
depends on CMDLINE_BOOL
bool "Extend builtin kernel arguments with bootloader arguments"
endchoice
endmenu
config LOCKDEP_SUPPORT
bool
default y
config STACKTRACE_SUPPORT
bool
default y
config HAVE_LATENCYTOP_SUPPORT
bool
default y
config PGTABLE_LEVELS
int
default 4 if PAGE_SIZE_4KB && MIPS_VA_BITS_48
default 3 if 64BIT && !PAGE_SIZE_64KB
default 2
config MIPS_AUTO_PFN_OFFSET
bool
menu "Bus options (PCI, PCMCIA, EISA, ISA, TC)"
config PCI_DRIVERS_GENERIC
select PCI_DOMAINS_GENERIC if PCI
bool
config PCI_DRIVERS_LEGACY
def_bool !PCI_DRIVERS_GENERIC
select NO_GENERIC_PCI_IOPORT_MAP
select PCI_DOMAINS if PCI
#
# ISA support is now enabled via select. Too many systems still have the one
# or other ISA chip on the board that users don't know about so don't expect
# users to choose the right thing ...
#
config ISA
bool
config TC
bool "TURBOchannel support"
depends on MACH_DECSTATION
help
TURBOchannel is a DEC (now Compaq (now HP)) bus for Alpha and MIPS
processors. TURBOchannel programming specifications are available
at:
<ftp://ftp.hp.com/pub/alphaserver/archive/triadd/>
and:
<http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/>
Linux driver support status is documented at:
<http://www.linux-mips.org/wiki/DECstation>
config MMU
bool
default y
config ARCH_MMAP_RND_BITS_MIN
default 12 if 64BIT
default 8
config ARCH_MMAP_RND_BITS_MAX
default 18 if 64BIT
default 15
config ARCH_MMAP_RND_COMPAT_BITS_MIN
default 8
config ARCH_MMAP_RND_COMPAT_BITS_MAX
default 15
config I8253
bool
select CLKSRC_I8253
select CLKEVT_I8253
select MIPS_EXTERNAL_TIMER
config ZONE_DMA
bool
config ZONE_DMA32
bool
endmenu
config TRAD_SIGNALS
bool
config MIPS32_COMPAT
bool
config COMPAT
bool
config SYSVIPC_COMPAT
bool
config MIPS32_O32
bool "Kernel support for o32 binaries"
depends on 64BIT
select ARCH_WANT_OLD_COMPAT_IPC
select COMPAT
select MIPS32_COMPAT
select SYSVIPC_COMPAT if SYSVIPC
help
Select this option if you want to run o32 binaries. These are pure
32-bit binaries as used by the 32-bit Linux/MIPS port. Most of
existing binaries are in this format.
If unsure, say Y.
config MIPS32_N32
bool "Kernel support for n32 binaries"
depends on 64BIT
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
select COMPAT
select MIPS32_COMPAT
select SYSVIPC_COMPAT if SYSVIPC
help
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
data that would normally be 64-bit. They are used in special
cases.
If unsure, say N.
config BINFMT_ELF32
bool
default y if MIPS32_O32 || MIPS32_N32
ELF/MIPS build fix CONFIG_MIPS32_N32=y but CONFIG_BINFMT_ELF disabled results in the following linker errors: arch/mips/built-in.o: In function `elf_core_dump': binfmt_elfn32.c:(.text+0x23dbc): undefined reference to `elf_core_extra_phdrs' binfmt_elfn32.c:(.text+0x246e4): undefined reference to `elf_core_extra_data_size' binfmt_elfn32.c:(.text+0x248d0): undefined reference to `elf_core_write_extra_phdrs' binfmt_elfn32.c:(.text+0x24ac4): undefined reference to `elf_core_write_extra_data' CONFIG_MIPS32_O32=y but CONFIG_BINFMT_ELF disabled results in the following linker errors: arch/mips/built-in.o: In function `elf_core_dump': binfmt_elfo32.c:(.text+0x28a04): undefined reference to `elf_core_extra_phdrs' binfmt_elfo32.c:(.text+0x29330): undefined reference to `elf_core_extra_data_size' binfmt_elfo32.c:(.text+0x2951c): undefined reference to `elf_core_write_extra_phdrs' binfmt_elfo32.c:(.text+0x29710): undefined reference to `elf_core_write_extra_data' This is because binfmt_elfn32 and binfmt_elfo32 are using symbols from elfcore but for these configurations elfcore will not be built. Fixed by making elfcore selectable by a separate config symbol which unlike the current mechanism can also be used from other directories than kernel/, then having each flavor of ELF that relies on elfcore.o, select it in Kconfig, including CONFIG_MIPS32_N32 and CONFIG_MIPS32_O32 which fixes this issue. Link: http://lkml.kernel.org/r/20160520141705.GA1913@linux-mips.org Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Reviewed-by: James Hogan <james.hogan@imgtec.com> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-24 07:22:26 +08:00
select ELFCORE
menu "Power management options"
config ARCH_HIBERNATION_POSSIBLE
def_bool y
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP
source "kernel/power/Kconfig"
endmenu
config MIPS_EXTERNAL_TIMER
bool
menu "CPU Power Management"
if CPU_SUPPORTS_CPUFREQ && MIPS_EXTERNAL_TIMER
source "drivers/cpufreq/Kconfig"
endif
source "drivers/cpuidle/Kconfig"
endmenu
source "drivers/firmware/Kconfig"
source "arch/mips/kvm/Kconfig"