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
|
2015-04-15 06:45:45 +08:00
|
|
|
config PGTABLE_LEVELS
|
|
|
|
|
int "Page Table Levels" if !IA64_PAGE_SIZE_64KB
|
|
|
|
|
range 3 4 if !IA64_PAGE_SIZE_64KB
|
|
|
|
|
default 3
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
menu "Processor type and features"
|
|
|
|
|
|
|
|
|
|
config IA64
|
|
|
|
|
bool
|
2022-02-01 00:54:52 +08:00
|
|
|
select ARCH_BINFMT_ELF_EXTRA_PHDRS
|
2020-08-17 22:41:50 +08:00
|
|
|
select ARCH_HAS_DMA_MARK_CLEAN
|
2021-05-17 15:22:34 +08:00
|
|
|
select ARCH_HAS_STRNCPY_FROM_USER
|
|
|
|
|
select ARCH_HAS_STRNLEN_USER
|
2013-10-08 10:08:56 +08:00
|
|
|
select ARCH_MIGHT_HAVE_PC_PARPORT
|
2014-01-02 03:31:12 +08:00
|
|
|
select ARCH_MIGHT_HAVE_PC_SERIO
|
2019-08-13 15:25:03 +08:00
|
|
|
select ACPI
|
2019-08-13 15:25:12 +08:00
|
|
|
select ACPI_NUMA if NUMA
|
2021-05-05 09:38:17 +08:00
|
|
|
select ARCH_ENABLE_MEMORY_HOTPLUG
|
|
|
|
|
select ARCH_ENABLE_MEMORY_HOTREMOVE
|
2019-08-13 15:25:03 +08:00
|
|
|
select ARCH_SUPPORTS_ACPI
|
2015-03-24 22:02:39 +08:00
|
|
|
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
|
2014-07-18 18:02:54 +08:00
|
|
|
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
|
2019-08-13 15:25:03 +08:00
|
|
|
select FORCE_PCI
|
2018-11-16 03:05:33 +08:00
|
|
|
select PCI_DOMAINS if PCI
|
2019-08-13 15:25:12 +08:00
|
|
|
select PCI_MSI
|
2018-11-16 03:05:34 +08:00
|
|
|
select PCI_SYSCALL if PCI
|
2019-08-19 13:54:20 +08:00
|
|
|
select HAVE_ASM_MODVERSIONS
|
2009-01-16 02:29:17 +08:00
|
|
|
select HAVE_UNSTABLE_SCHED_CLOCK
|
2016-05-21 08:00:16 +08:00
|
|
|
select HAVE_EXIT_THREAD
|
2008-02-03 04:10:35 +08:00
|
|
|
select HAVE_KPROBES
|
2008-03-05 06:28:37 +08:00
|
|
|
select HAVE_KRETPROBES
|
2009-01-09 11:29:49 +08:00
|
|
|
select HAVE_FTRACE_MCOUNT_RECORD
|
|
|
|
|
select HAVE_DYNAMIC_FTRACE if (!ITANIUM)
|
2009-01-09 11:29:46 +08:00
|
|
|
select HAVE_FUNCTION_TRACER
|
mm: percpu: generalize percpu related config
Patch series "mm: percpu: Cleanup percpu first chunk function".
When supporting page mapping percpu first chunk allocator on arm64, we
found there are lots of duplicated codes in percpu embed/page first chunk
allocator. This patchset is aimed to cleanup them and should no function
change.
The currently supported status about 'embed' and 'page' in Archs shows
below,
embed: NEED_PER_CPU_PAGE_FIRST_CHUNK
page: NEED_PER_CPU_EMBED_FIRST_CHUNK
embed page
------------------------
arm64 Y Y
mips Y N
powerpc Y Y
riscv Y N
sparc Y Y
x86 Y Y
------------------------
There are two interfaces about percpu first chunk allocator,
extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
size_t atom_size,
pcpu_fc_cpu_distance_fn_t cpu_distance_fn,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
extern int __init pcpu_page_first_chunk(size_t reserved_size,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn,
- pcpu_fc_populate_pte_fn_t populate_pte_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
The pcpu_fc_alloc_fn_t/pcpu_fc_free_fn_t is killed, we provide generic
pcpu_fc_alloc() and pcpu_fc_free() function, which are called in the
pcpu_embed/page_first_chunk().
1) For pcpu_embed_first_chunk(), pcpu_fc_cpu_to_node_fn_t is needed to be
provided when archs supported NUMA.
2) For pcpu_page_first_chunk(), the pcpu_fc_populate_pte_fn_t is killed too,
a generic pcpu_populate_pte() which marked '__weak' is provided, if you
need a different function to populate pte on the arch(like x86), please
provide its own implementation.
[1] https://github.com/kevin78/linux.git percpu-cleanup
This patch (of 4):
The HAVE_SETUP_PER_CPU_AREA/NEED_PER_CPU_EMBED_FIRST_CHUNK/
NEED_PER_CPU_PAGE_FIRST_CHUNK/USE_PERCPU_NUMA_NODE_ID configs, which have
duplicate definitions on platforms that subscribe it.
Move them into mm, drop these redundant definitions and instead just
select it on applicable platforms.
Link: https://lkml.kernel.org/r/20211216112359.103822-1-wangkefeng.wang@huawei.com
Link: https://lkml.kernel.org/r/20211216112359.103822-2-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-20 10:07:41 +08:00
|
|
|
select HAVE_SETUP_PER_CPU_AREA
|
2014-04-08 06:39:07 +08:00
|
|
|
select TTY
|
2008-10-02 04:57:14 +08:00
|
|
|
select HAVE_ARCH_TRACEHOOK
|
2022-02-15 20:41:02 +08:00
|
|
|
select HAVE_FUNCTION_DESCRIPTORS
|
2012-06-16 21:39:34 +08:00
|
|
|
select HAVE_VIRT_CPU_ACCOUNTING
|
2021-05-05 09:33:19 +08:00
|
|
|
select HUGETLB_PAGE_SIZE_VARIABLE if HUGETLB_PAGE
|
2011-01-20 03:32:46 +08:00
|
|
|
select GENERIC_IRQ_PROBE
|
|
|
|
|
select GENERIC_PENDING_IRQ if SMP
|
2011-03-26 04:04:38 +08:00
|
|
|
select GENERIC_IRQ_SHOW
|
2014-05-07 23:44:22 +08:00
|
|
|
select GENERIC_IRQ_LEGACY
|
2011-07-13 13:14:22 +08:00
|
|
|
select ARCH_HAVE_NMI_SAFE_CMPXCHG
|
2011-11-24 20:54:28 +08:00
|
|
|
select GENERIC_IOMAP
|
2012-04-20 21:05:49 +08:00
|
|
|
select GENERIC_SMP_IDLE_THREAD
|
2018-01-02 23:12:01 +08:00
|
|
|
select ARCH_TASK_STRUCT_ON_STACK
|
2012-05-05 23:05:48 +08:00
|
|
|
select ARCH_TASK_STRUCT_ALLOCATOR
|
Clarify naming of thread info/stack allocators
We've had the thread info allocated together with the thread stack for
most architectures for a long time (since the thread_info was split off
from the task struct), but that is about to change.
But the patches that move the thread info to be off-stack (and a part of
the task struct instead) made it clear how confused the allocator and
freeing functions are.
Because the common case was that we share an allocation with the thread
stack and the thread_info, the two pointers were identical. That
identity then meant that we would have things like
ti = alloc_thread_info_node(tsk, node);
...
tsk->stack = ti;
which certainly _worked_ (since stack and thread_info have the same
value), but is rather confusing: why are we assigning a thread_info to
the stack? And if we move the thread_info away, the "confusing" code
just gets to be entirely bogus.
So remove all this confusion, and make it clear that we are doing the
stack allocation by renaming and clarifying the function names to be
about the stack. The fact that the thread_info then shares the
allocation is an implementation detail, and not really about the
allocation itself.
This is a pure renaming and type fix: we pass in the same pointer, it's
just that we clarify what the pointer means.
The ia64 code that actually only has one single allocation (for all of
task_struct, thread_info and kernel thread stack) now looks a bit odd,
but since "tsk->stack" is actually not even used there, that oddity
doesn't matter. It would be a separate thing to clean that up, I
intentionally left the ia64 changes as a pure brute-force renaming and
type change.
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-06-25 06:09:37 +08:00
|
|
|
select ARCH_THREAD_STACK_ALLOCATOR
|
2012-05-19 00:45:48 +08:00
|
|
|
select ARCH_CLOCKSOURCE_DATA
|
2017-11-01 01:43:39 +08:00
|
|
|
select GENERIC_TIME_VSYSCALL
|
2020-09-24 21:23:13 +08:00
|
|
|
select LEGACY_TIMER_TICK
|
2019-08-13 15:25:12 +08:00
|
|
|
select SWIOTLB
|
2013-01-09 22:36:28 +08:00
|
|
|
select SYSCTL_ARCH_UNALIGN_NO_WARN
|
2012-09-28 13:01:03 +08:00
|
|
|
select HAVE_MOD_ARCH_SPECIFIC
|
|
|
|
|
select MODULES_USE_ELF_RELA
|
2013-09-04 06:31:21 +08:00
|
|
|
select ARCH_USE_CMPXCHG_LOCKREF
|
2014-02-25 17:16:24 +08:00
|
|
|
select HAVE_ARCH_AUDITSYSCALL
|
2018-05-09 12:53:49 +08:00
|
|
|
select NEED_DMA_MAP_STATE
|
2018-04-05 15:44:52 +08:00
|
|
|
select NEED_SG_DMA_LENGTH
|
2019-08-13 15:25:12 +08:00
|
|
|
select NUMA if !FLATMEM
|
2020-09-28 18:13:07 +08:00
|
|
|
select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
|
2021-07-01 09:52:20 +08:00
|
|
|
select ZONE_DMA32
|
2022-09-15 19:10:47 +08:00
|
|
|
select FUNCTION_ALIGNMENT_32B
|
2005-04-17 06:20:36 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
The Itanium Processor Family is Intel's 64-bit successor to
|
|
|
|
|
the 32-bit X86 line. The IA-64 Linux project has a home
|
|
|
|
|
page at <http://www.linuxia64.org/> and a mailing list at
|
|
|
|
|
<linux-ia64@vger.kernel.org>.
|
|
|
|
|
|
|
|
|
|
config 64BIT
|
|
|
|
|
bool
|
2007-02-09 11:29:51 +08:00
|
|
|
select ATA_NONSTANDARD if ATA
|
2005-04-17 06:20:36 +08:00
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config MMU
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
2010-09-24 04:52:07 +08:00
|
|
|
config STACKTRACE_SUPPORT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2008-01-30 20:31:20 +08:00
|
|
|
config GENERIC_LOCKBREAK
|
2009-09-25 23:42:16 +08:00
|
|
|
def_bool n
|
2008-01-30 20:31:20 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config GENERIC_CALIBRATE_DELAY
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
[PATCH] ia64: use i386 dmi_scan.c
Enable DMI table parsing on ia64.
Andi Kleen has a patch in his x86_64 tree which enables the use of i386
dmi_scan.c on x86_64. dmi_scan.c functions are being used by the
drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or
memory spaces where the IPMI controllers may be found.
This patch adds equivalent changes for ia64 as to what is in the x86_64
tree. In addition, I reworked the DMI detection, such that on EFI-capable
systems, it uses the efi.smbios pointer to find the table, rather than
brute-force searching from 0xF0000. On non-EFI systems, it continues the
brute-force search.
My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with
latest BIOS, does not list the IPMI controller in the ACPI namespace, nor
does it have an ACPI SPMI table. Also note, currently shipping Dell x8xx
EM64T servers don't have these either, so DMI is the only method for
obtaining the address of the IPMI controller.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-26 17:37:03 +08:00
|
|
|
config DMI
|
|
|
|
|
bool
|
|
|
|
|
default y
|
2014-01-24 07:54:39 +08:00
|
|
|
select DMI_SCAN_MACHINE_NON_EFI_FALLBACK
|
[PATCH] ia64: use i386 dmi_scan.c
Enable DMI table parsing on ia64.
Andi Kleen has a patch in his x86_64 tree which enables the use of i386
dmi_scan.c on x86_64. dmi_scan.c functions are being used by the
drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or
memory spaces where the IPMI controllers may be found.
This patch adds equivalent changes for ia64 as to what is in the x86_64
tree. In addition, I reworked the DMI detection, such that on EFI-capable
systems, it uses the efi.smbios pointer to find the table, rather than
brute-force searching from 0xF0000. On non-EFI systems, it continues the
brute-force search.
My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with
latest BIOS, does not list the IPMI controller in the ACPI namespace, nor
does it have an ACPI SPMI table. Also note, currently shipping Dell x8xx
EM64T servers don't have these either, so DMI is the only method for
obtaining the address of the IPMI controller.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-26 17:37:03 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config EFI
|
|
|
|
|
bool
|
2013-04-30 18:30:24 +08:00
|
|
|
select UCS2_STRING
|
2005-04-17 06:20:36 +08:00
|
|
|
default y
|
|
|
|
|
|
2008-11-11 16:05:16 +08:00
|
|
|
config SCHED_OMIT_FRAME_POINTER
|
2005-05-06 07:15:11 +08:00
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
2005-06-22 08:15:02 +08:00
|
|
|
config IA64_UNCACHED_ALLOCATOR
|
|
|
|
|
bool
|
|
|
|
|
select GENERIC_ALLOCATOR
|
|
|
|
|
|
2009-07-11 00:57:37 +08:00
|
|
|
config ARCH_USES_PG_UNCACHED
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on IA64_UNCACHED_ALLOCATOR
|
|
|
|
|
|
2006-09-12 15:04:40 +08:00
|
|
|
config AUDIT_ARCH
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
choice
|
|
|
|
|
prompt "Processor type"
|
|
|
|
|
default ITANIUM
|
|
|
|
|
|
|
|
|
|
config ITANIUM
|
|
|
|
|
bool "Itanium"
|
|
|
|
|
help
|
|
|
|
|
Select your IA-64 processor type. The default is Itanium.
|
|
|
|
|
This choice is safe for all IA-64 systems, but may not perform
|
|
|
|
|
optimally on systems with, say, Itanium 2 or newer processors.
|
|
|
|
|
|
|
|
|
|
config MCKINLEY
|
|
|
|
|
bool "Itanium 2"
|
|
|
|
|
help
|
|
|
|
|
Select this to configure for an Itanium 2 (McKinley) processor.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "Kernel page size"
|
|
|
|
|
default IA64_PAGE_SIZE_16KB
|
|
|
|
|
|
|
|
|
|
config IA64_PAGE_SIZE_4KB
|
|
|
|
|
bool "4KB"
|
|
|
|
|
help
|
|
|
|
|
This lets you select the page size of the kernel. For best IA-64
|
|
|
|
|
performance, a page size of 8KB or 16KB is recommended. For best
|
|
|
|
|
IA-32 compatibility, a page size of 4KB should be selected (the vast
|
|
|
|
|
majority of IA-32 binaries work perfectly fine with a larger page
|
|
|
|
|
size). For Itanium 2 or newer systems, a page size of 64KB can also
|
|
|
|
|
be selected.
|
|
|
|
|
|
|
|
|
|
4KB For best IA-32 compatibility
|
|
|
|
|
8KB For best IA-64 performance
|
|
|
|
|
16KB For best IA-64 performance
|
|
|
|
|
64KB Requires Itanium 2 or newer processor.
|
|
|
|
|
|
|
|
|
|
If you don't know what to do, choose 16KB.
|
|
|
|
|
|
|
|
|
|
config IA64_PAGE_SIZE_8KB
|
|
|
|
|
bool "8KB"
|
|
|
|
|
|
|
|
|
|
config IA64_PAGE_SIZE_16KB
|
|
|
|
|
bool "16KB"
|
|
|
|
|
|
|
|
|
|
config IA64_PAGE_SIZE_64KB
|
|
|
|
|
depends on !ITANIUM
|
|
|
|
|
bool "64KB"
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2018-12-11 19:01:04 +08:00
|
|
|
source "kernel/Kconfig.hz"
|
2005-06-23 15:08:27 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config IA64_BRL_EMU
|
|
|
|
|
bool
|
|
|
|
|
depends on ITANIUM
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
# align cache-sensitive data to 128 bytes
|
|
|
|
|
config IA64_L1_CACHE_SHIFT
|
|
|
|
|
int
|
|
|
|
|
default "7" if MCKINLEY
|
|
|
|
|
default "6" if ITANIUM
|
|
|
|
|
|
2019-08-13 15:25:12 +08:00
|
|
|
config IA64_SGI_UV
|
|
|
|
|
bool "SGI-UV support"
|
|
|
|
|
help
|
|
|
|
|
Selecting this option will add specific support for running on SGI
|
|
|
|
|
UV based systems. If you have an SGI UV system or are building a
|
|
|
|
|
distro kernel, select this option.
|
|
|
|
|
|
|
|
|
|
config IA64_HP_SBA_IOMMU
|
|
|
|
|
bool "HP SBA IOMMU support"
|
2020-07-08 15:30:00 +08:00
|
|
|
select DMA_OPS
|
2019-08-13 15:25:12 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here to add support for the SBA IOMMU found on HP zx1 and
|
|
|
|
|
sx1000 systems. If you're unsure, answer Y.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config IA64_CYCLONE
|
|
|
|
|
bool "Cyclone (EXA) Time Source support"
|
|
|
|
|
help
|
|
|
|
|
Say Y here to enable support for IBM EXA Cyclone time source.
|
|
|
|
|
If you're unsure, answer N.
|
|
|
|
|
|
2022-08-15 22:39:59 +08:00
|
|
|
config ARCH_FORCE_MAX_ORDER
|
2005-10-05 03:13:37 +08:00
|
|
|
int "MAX_ORDER (11 - 17)" if !HUGETLB_PAGE
|
|
|
|
|
range 11 17 if !HUGETLB_PAGE
|
|
|
|
|
default "17" if HUGETLB_PAGE
|
|
|
|
|
default "11"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
config SMP
|
|
|
|
|
bool "Symmetric multi-processing support"
|
|
|
|
|
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 single and multiprocessor
|
|
|
|
|
systems, but will use only one CPU of a multiprocessor system. If
|
|
|
|
|
you say Y here, the kernel will run on many, but not all,
|
|
|
|
|
single processor systems. On a single processor system, the kernel
|
|
|
|
|
will run faster if you say N here.
|
|
|
|
|
|
2008-02-03 21:50:21 +08:00
|
|
|
See also the SMP-HOWTO available at
|
|
|
|
|
<http://www.tldp.org/docs.html#howto>.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
|
|
|
|
|
|
config NR_CPUS
|
2008-08-03 02:29:24 +08:00
|
|
|
int "Maximum number of CPUs (2-4096)"
|
|
|
|
|
range 2 4096
|
2005-04-17 06:20:36 +08:00
|
|
|
depends on SMP
|
2008-08-03 02:29:24 +08:00
|
|
|
default "4096"
|
2005-04-17 06:20:36 +08:00
|
|
|
help
|
|
|
|
|
You should set this to the number of CPUs in your system, but
|
|
|
|
|
keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but
|
|
|
|
|
only use 2 CPUs on a >2 CPU system. Setting this to a value larger
|
|
|
|
|
than 64 will cause the use of a CPU mask array, causing a small
|
|
|
|
|
performance hit.
|
|
|
|
|
|
|
|
|
|
config HOTPLUG_CPU
|
2012-10-03 02:16:29 +08:00
|
|
|
bool "Support for hot-pluggable CPUs"
|
|
|
|
|
depends on SMP
|
2005-04-17 06:20:36 +08:00
|
|
|
default n
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2005-04-17 06:20:36 +08:00
|
|
|
Say Y here to experiment with turning CPUs off and on. CPUs
|
|
|
|
|
can be controlled through /sys/devices/system/cpu/cpu#.
|
|
|
|
|
Say N if you want to disable CPU hotplug.
|
|
|
|
|
|
2005-04-06 09:05:00 +08:00
|
|
|
config SCHED_SMT
|
|
|
|
|
bool "SMT scheduler support"
|
|
|
|
|
depends on SMP
|
|
|
|
|
help
|
|
|
|
|
Improves the CPU scheduler's decision making when dealing with
|
|
|
|
|
Intel IA64 chips with MultiThreading at a cost of slightly increased
|
|
|
|
|
overhead in some places. If unsure say N here.
|
|
|
|
|
|
2005-11-12 06:32:40 +08:00
|
|
|
config PERMIT_BSP_REMOVE
|
|
|
|
|
bool "Support removal of Bootstrap Processor"
|
|
|
|
|
depends on HOTPLUG_CPU
|
|
|
|
|
default n
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2005-11-12 06:32:40 +08:00
|
|
|
Say Y here if your platform SAL will support removal of BSP with HOTPLUG_CPU
|
|
|
|
|
support.
|
|
|
|
|
|
|
|
|
|
config FORCE_CPEI_RETARGET
|
2011-03-31 09:57:33 +08:00
|
|
|
bool "Force assumption that CPEI can be re-targeted"
|
2005-11-12 06:32:40 +08:00
|
|
|
depends on PERMIT_BSP_REMOVE
|
|
|
|
|
default n
|
2020-06-14 00:50:22 +08:00
|
|
|
help
|
2011-03-31 09:57:33 +08:00
|
|
|
Say Y if you need to force the assumption that CPEI can be re-targeted to
|
2005-11-12 06:32:40 +08:00
|
|
|
any cpu in the system. This hint is available via ACPI 3.0 specifications.
|
|
|
|
|
Tiger4 systems are capable of re-directing CPEI to any CPU other than BSP.
|
|
|
|
|
This option it useful to enable this feature on older BIOS's as well.
|
|
|
|
|
You can also enable this by using boot command line option force_cpei=1.
|
|
|
|
|
|
2005-10-05 03:13:37 +08:00
|
|
|
config ARCH_SELECT_MEMORY_MODEL
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config ARCH_FLATMEM_ENABLE
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config ARCH_SPARSEMEM_ENABLE
|
|
|
|
|
def_bool y
|
2007-10-16 16:24:15 +08:00
|
|
|
select SPARSEMEM_VMEMMAP_ENABLE
|
2005-10-05 03:13:37 +08:00
|
|
|
|
2020-12-15 11:09:51 +08:00
|
|
|
config ARCH_SPARSEMEM_DEFAULT
|
2019-08-13 15:25:12 +08:00
|
|
|
def_bool y
|
2020-12-15 11:09:51 +08:00
|
|
|
depends on ARCH_SPARSEMEM_ENABLE
|
2005-10-05 03:13:37 +08:00
|
|
|
|
|
|
|
|
config NUMA
|
|
|
|
|
bool "NUMA support"
|
2019-08-13 15:25:03 +08:00
|
|
|
depends on !FLATMEM
|
2019-08-09 03:53:00 +08:00
|
|
|
select SMP
|
mm: percpu: generalize percpu related config
Patch series "mm: percpu: Cleanup percpu first chunk function".
When supporting page mapping percpu first chunk allocator on arm64, we
found there are lots of duplicated codes in percpu embed/page first chunk
allocator. This patchset is aimed to cleanup them and should no function
change.
The currently supported status about 'embed' and 'page' in Archs shows
below,
embed: NEED_PER_CPU_PAGE_FIRST_CHUNK
page: NEED_PER_CPU_EMBED_FIRST_CHUNK
embed page
------------------------
arm64 Y Y
mips Y N
powerpc Y Y
riscv Y N
sparc Y Y
x86 Y Y
------------------------
There are two interfaces about percpu first chunk allocator,
extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
size_t atom_size,
pcpu_fc_cpu_distance_fn_t cpu_distance_fn,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
extern int __init pcpu_page_first_chunk(size_t reserved_size,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn,
- pcpu_fc_populate_pte_fn_t populate_pte_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
The pcpu_fc_alloc_fn_t/pcpu_fc_free_fn_t is killed, we provide generic
pcpu_fc_alloc() and pcpu_fc_free() function, which are called in the
pcpu_embed/page_first_chunk().
1) For pcpu_embed_first_chunk(), pcpu_fc_cpu_to_node_fn_t is needed to be
provided when archs supported NUMA.
2) For pcpu_page_first_chunk(), the pcpu_fc_populate_pte_fn_t is killed too,
a generic pcpu_populate_pte() which marked '__weak' is provided, if you
need a different function to populate pte on the arch(like x86), please
provide its own implementation.
[1] https://github.com/kevin78/linux.git percpu-cleanup
This patch (of 4):
The HAVE_SETUP_PER_CPU_AREA/NEED_PER_CPU_EMBED_FIRST_CHUNK/
NEED_PER_CPU_PAGE_FIRST_CHUNK/USE_PERCPU_NUMA_NODE_ID configs, which have
duplicate definitions on platforms that subscribe it.
Move them into mm, drop these redundant definitions and instead just
select it on applicable platforms.
Link: https://lkml.kernel.org/r/20211216112359.103822-1-wangkefeng.wang@huawei.com
Link: https://lkml.kernel.org/r/20211216112359.103822-2-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-20 10:07:41 +08:00
|
|
|
select USE_PERCPU_NUMA_NODE_ID
|
2005-10-05 03:13:37 +08:00
|
|
|
help
|
|
|
|
|
Say Y to compile the kernel to support NUMA (Non-Uniform Memory
|
|
|
|
|
Access). This option is for configuring high-end multiprocessor
|
|
|
|
|
server systems. If in doubt, say N.
|
|
|
|
|
|
2006-04-11 13:53:53 +08:00
|
|
|
config NODES_SHIFT
|
|
|
|
|
int "Max num nodes shift(3-10)"
|
|
|
|
|
range 3 10
|
2006-08-23 10:43:27 +08:00
|
|
|
default "10"
|
2021-06-29 10:43:01 +08:00
|
|
|
depends on NUMA
|
2006-04-11 13:53:53 +08:00
|
|
|
help
|
|
|
|
|
This option specifies the maximum number of nodes in your SSI system.
|
|
|
|
|
MAX_NUMNODES will be 2^(This value).
|
|
|
|
|
If in doubt, use the default.
|
|
|
|
|
|
2006-06-27 17:53:33 +08:00
|
|
|
config HAVE_ARCH_NODEDATA_EXTENSION
|
|
|
|
|
def_bool y
|
2010-05-27 05:44:59 +08:00
|
|
|
depends on NUMA
|
|
|
|
|
|
2010-05-27 05:45:01 +08:00
|
|
|
config HAVE_MEMORYLESS_NODES
|
2010-08-10 08:19:00 +08:00
|
|
|
def_bool NUMA
|
2010-05-27 05:45:01 +08:00
|
|
|
|
2009-09-23 07:45:45 +08:00
|
|
|
config ARCH_PROC_KCORE_TEXT
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on PROC_KCORE
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
config IA64_MCA_RECOVERY
|
2022-01-30 05:40:58 +08:00
|
|
|
bool "MCA recovery from errors other than TLB."
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
config IA64_PALINFO
|
|
|
|
|
tristate "/proc/pal support"
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you are able to get PAL (Processor Abstraction
|
|
|
|
|
Layer) information in /proc/pal. This contains useful information
|
|
|
|
|
about the processors in your systems, such as cache and TLB sizes
|
|
|
|
|
and the PAL firmware version in use.
|
|
|
|
|
|
|
|
|
|
To use this option, you have to ensure that the "/proc file system
|
|
|
|
|
support" (CONFIG_PROC_FS) is enabled, too.
|
|
|
|
|
|
2006-12-09 08:06:01 +08:00
|
|
|
config IA64_MC_ERR_INJECT
|
|
|
|
|
tristate "MC error injection support"
|
|
|
|
|
help
|
2007-10-20 07:34:40 +08:00
|
|
|
Adds support for MC error injection. If enabled, the kernel
|
|
|
|
|
will provide a sysfs interface for user applications to
|
|
|
|
|
call MC error injection PAL procedures to inject various errors.
|
2006-12-09 08:06:01 +08:00
|
|
|
This is a useful tool for MCA testing.
|
|
|
|
|
|
|
|
|
|
If you're unsure, do not select this option.
|
|
|
|
|
|
[IA64] esi-support
Add support for making ESI calls [1]. ESI stands for "Extensible SAL
specification" and is basically a way for invoking firmware
subroutines which are identified by a GUID. I don't know whether ESI
is used by vendors other than HP (if you do, please let me know) but
as firmware "backdoors" go, this seems one of the cleaner methods, so
it seems reasonable to support it, even though I'm not aware of any
publicly documented ESI calls. I'd have liked to make the ESI module
completely stand-alone, but unfortunately that is not easily (or not
at all) possible because in order to make ESI calls in physical mode,
a small stub similar to the EFI stub is needed in the kernel proper.
I did try to create a stub that would work in user-level, but it
quickly got ugly beyond recognition (e.g., the stub had to make
assumptions about how the module-loader generated call-stubs work) and
I didn't even get it to work (that's probably fixable, but I didn't
bother because I concluded it was too ugly anyhow). While it's not
terribly elegant to have kernel code which isn't actively used in the
kernel proper, I think it might be worth making an exception here for
two reasons: the code is trivially small (all that's really needed is
esi_stub.S) and by including it in the normal kernel distro, it might
encourage other OEMs to also use ESI, which I think would be far
better than each inventing their own firmware "backdoor".
The code was originally written by Alex. I just massaged and packaged
it a bit (and perhaps messed up some things along the way...).
Changes since first version of patch that was posted to mailing list:
* Export ia64_esi_call and ia64_esi_call_phys() as GPL symbols.
* Disallow building esi.c as a module for now. Building as a module
would currently lead to an unresolved reference to "sal_lock" on SMP kernels
because that symbol doesn't get exported.
* Export esi_call_phys() only if ESI is enabled.
* Remove internal stuff from esi.h and add a "proc_type" argument to
ia64_esi_call() such that serialization-requirements can be expressed (ESI
follows SAL here, where procedure calls may have to be serialized, are
MP-safe, or MP-safe andr reentrant).
[1] h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,919,00.html
Signed-off-by: David Mosberger <David.Mosberger@acm.org>
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-06-22 02:19:22 +08:00
|
|
|
config IA64_ESI
|
|
|
|
|
bool "ESI (Extensible SAL Interface) support"
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, support is built into the kernel to
|
|
|
|
|
make ESI calls. ESI calls are used to support vendor-specific
|
|
|
|
|
firmware extensions, such as the ability to inject memory-errors
|
|
|
|
|
for test-purposes. If you're unsure, say N.
|
|
|
|
|
|
2007-09-21 04:22:03 +08:00
|
|
|
config IA64_HP_AML_NFW
|
|
|
|
|
bool "Support ACPI AML calls to native firmware"
|
|
|
|
|
help
|
|
|
|
|
This driver installs a global ACPI Operation Region handler for
|
|
|
|
|
region 0xA1. AML methods can use this OpRegion to call arbitrary
|
|
|
|
|
native firmware functions. The driver installs the OpRegion
|
|
|
|
|
handler if there is an HPQ5001 device or if the user supplies
|
|
|
|
|
the "force" module parameter, e.g., with the "aml_nfw.force"
|
|
|
|
|
kernel command line option.
|
|
|
|
|
|
2006-12-08 01:51:35 +08:00
|
|
|
config KEXEC
|
2012-10-03 02:16:29 +08:00
|
|
|
bool "kexec system call"
|
2019-08-13 15:25:03 +08:00
|
|
|
depends on !SMP || HOTPLUG_CPU
|
2015-09-10 06:38:55 +08:00
|
|
|
select KEXEC_CORE
|
2006-12-08 01:51:35 +08:00
|
|
|
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
|
2007-05-09 13:12:20 +08:00
|
|
|
but it is independent of the system firmware. And like a reboot
|
2006-12-08 01:51:35 +08:00
|
|
|
you can start any kernel with it, not just Linux.
|
|
|
|
|
|
2007-10-20 07:34:40 +08:00
|
|
|
The name comes from the similarity to the exec system call.
|
2006-12-08 01:51:35 +08:00
|
|
|
|
|
|
|
|
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
|
2013-08-21 03:38:03 +08:00
|
|
|
initially work for you. As of this writing the exact hardware
|
|
|
|
|
interface is strongly in flux, so no good recommendation can be
|
|
|
|
|
made.
|
2006-12-08 01:51:35 +08:00
|
|
|
|
|
|
|
|
config CRASH_DUMP
|
2008-06-26 20:53:11 +08:00
|
|
|
bool "kernel crash dumps"
|
2019-08-13 15:25:03 +08:00
|
|
|
depends on IA64_MCA_RECOVERY && (!SMP || HOTPLUG_CPU)
|
2006-12-08 01:51:35 +08:00
|
|
|
help
|
|
|
|
|
Generate crash dump after being started by kexec.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
endmenu
|
|
|
|
|
|
2008-11-07 00:53:54 +08:00
|
|
|
menu "Power management and ACPI options"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-08-26 00:08:25 +08:00
|
|
|
source "kernel/power/Kconfig"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
source "drivers/acpi/Kconfig"
|
|
|
|
|
|
2005-07-30 07:15:00 +08:00
|
|
|
if PM
|
2013-04-04 20:54:20 +08:00
|
|
|
menu "CPU Frequency scaling"
|
|
|
|
|
source "drivers/cpufreq/Kconfig"
|
|
|
|
|
endmenu
|
2005-07-30 07:15:00 +08:00
|
|
|
endif
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
endmenu
|
|
|
|
|
|
2006-11-11 04:27:49 +08:00
|
|
|
config MSPEC
|
|
|
|
|
tristate "Memory special operations driver"
|
|
|
|
|
depends on IA64
|
|
|
|
|
select IA64_UNCACHED_ALLOCATOR
|
|
|
|
|
help
|
|
|
|
|
If you have an ia64 and you want to enable memory special
|
|
|
|
|
operations support (formerly known as fetchop), say Y here,
|
|
|
|
|
otherwise say N.
|