2019-05-19 15:07:45 +03:00
# SPDX-License-Identifier: GPL-2.0-only
2017-07-11 04:08:08 +03:00
#
# For a description of the syntax of this configuration file,
2019-06-12 20:52:48 +03:00
# see Documentation/kbuild/kconfig-language.rst.
2017-07-11 04:08:08 +03:00
#
2018-04-27 09:38:23 +03:00
config 64BIT
bool
config 32BIT
bool
2017-07-11 04:08:08 +03:00
config RISCV
def_bool y
2023-05-15 08:49:13 +03:00
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
2023-04-01 12:15:31 +03:00
select ARCH_DMA_DEFAULT_COHERENT
2021-08-10 16:51:05 +03:00
select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
2021-09-27 06:03:25 +03:00
select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
2022-12-19 20:28:37 +03:00
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
2019-06-13 10:09:03 +03:00
select ARCH_HAS_BINFMT_FLAT
2022-02-24 09:04:11 +03:00
select ARCH_HAS_CURRENT_STACK_POINTER
2020-06-04 23:55:14 +03:00
select ARCH_HAS_DEBUG_VIRTUAL if MMU
2022-12-19 20:28:37 +03:00
select ARCH_HAS_DEBUG_VM_PGTABLE
2020-06-04 02:03:55 +03:00
select ARCH_HAS_DEBUG_WX
2021-02-25 10:03:03 +03:00
select ARCH_HAS_FORTIFY_SOURCE
2020-06-04 23:55:14 +03:00
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE
2020-06-26 15:40:56 +03:00
select ARCH_HAS_KCOV
2020-06-04 23:55:14 +03:00
select ARCH_HAS_MMIOWB
2023-05-04 10:29:10 +03:00
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
2022-11-14 12:05:35 +03:00
select ARCH_HAS_PMEM_API
2020-06-04 23:55:14 +03:00
select ARCH_HAS_PTE_SPECIAL
2021-07-08 04:07:54 +03:00
select ARCH_HAS_SET_DIRECT_MAP if MMU
select ARCH_HAS_SET_MEMORY if MMU
2021-04-13 09:35:14 +03:00
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL
2023-07-10 21:35:46 +03:00
select ARCH_HAS_SYSCALL_WRAPPER
2021-03-07 05:24:46 +03:00
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
2021-08-04 19:30:59 +03:00
select ARCH_HAS_UBSAN_SANITIZE_ALL
2023-04-08 02:11:03 +03:00
select ARCH_HAS_VDSO_DATA
2020-06-23 08:36:59 +03:00
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
2021-08-04 19:29:08 +03:00
select ARCH_STACKWALK
select ARCH_SUPPORTS_ATOMIC_RMW
2023-07-10 21:35:51 +03:00
select ARCH_SUPPORTS_CFI_CLANG
2021-08-04 19:29:08 +03:00
select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
2021-05-05 04:38:13 +03:00
select ARCH_SUPPORTS_HUGETLBFS if MMU
2022-06-24 11:52:36 +03:00
select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU
2023-05-23 19:59:42 +03:00
select ARCH_SUPPORTS_PER_VMA_LOCK if MMU
2021-05-07 12:47:15 +03:00
select ARCH_USE_MEMTEST
2022-03-17 02:11:33 +03:00
select ARCH_USE_QUEUED_RWLOCKS
2023-07-10 21:35:49 +03:00
select ARCH_USES_CFI_TRAPS if CFI_CLANG
2020-06-04 23:55:14 +03:00
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
2017-07-11 04:08:08 +03:00
select ARCH_WANT_FRAME_POINTERS
2023-02-09 16:16:46 +03:00
select ARCH_WANT_GENERAL_HUGETLB if !RISCV_ISA_SVNAPOT
2020-06-04 23:55:14 +03:00
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
2023-01-19 18:54:17 +03:00
select ARCH_WANT_LD_ORPHAN_WARN if !XIP_KERNEL
2023-07-24 22:07:53 +03:00
select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
2022-08-29 17:57:42 +03:00
select ARCH_WANTS_THP_SWAP if HAVE_ARCH_TRANSPARENT_HUGEPAGE
2021-04-17 04:10:09 +03:00
select BINFMT_FLAT_NO_DATA_START_OFFSET if !MMU
2021-08-26 17:10:29 +03:00
select BUILDTIME_TABLE_SORT if MMU
2020-09-14 19:56:30 +03:00
select CLINT_TIMER if !MMU
2022-12-19 20:28:37 +03:00
select CLONE_BACKWARDS
2017-07-11 04:08:08 +03:00
select COMMON_CLK
2023-03-30 09:43:21 +03:00
select CPU_PM if CPU_IDLE || HIBERNATION
2020-06-04 23:55:14 +03:00
select EDAC_SUPPORT
2023-08-23 11:28:45 +03:00
select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
2022-07-15 20:51:56 +03:00
select GENERIC_ARCH_TOPOLOGY
2020-06-04 23:55:14 +03:00
select GENERIC_ATOMIC64 if !64BIT
2021-03-07 05:24:46 +03:00
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
2020-09-18 01:37:11 +03:00
select GENERIC_EARLY_IOREMAP
2023-02-22 06:30:18 +03:00
select GENERIC_ENTRY
2020-06-09 17:14:48 +03:00
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
2021-07-08 04:59:48 +03:00
select GENERIC_IDLE_POLL_SETUP
2021-09-08 05:55:58 +03:00
select GENERIC_IOREMAP if MMU
2023-03-28 06:52:19 +03:00
select GENERIC_IRQ_IPI if SMP
select GENERIC_IRQ_IPI_MUX if SMP
2020-06-04 23:55:14 +03:00
select GENERIC_IRQ_MULTI_HANDLER
2017-07-11 04:08:08 +03:00
select GENERIC_IRQ_SHOW
2021-07-08 04:59:49 +03:00
select GENERIC_IRQ_SHOW_LEVEL
2020-07-09 21:51:17 +03:00
select GENERIC_LIB_DEVMEM_IS_ALLOWED
2017-07-11 04:08:08 +03:00
select GENERIC_PCI_IOMAP
2020-06-04 23:55:14 +03:00
select GENERIC_PTDUMP if MMU
2018-12-04 13:29:51 +03:00
select GENERIC_SCHED_CLOCK
2020-06-04 23:55:14 +03:00
select GENERIC_SMP_IDLE_THREAD
2020-06-09 17:14:48 +03:00
select GENERIC_TIME_VSYSCALL if MMU && 64BIT
2021-09-01 06:20:25 +03:00
select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
2022-07-29 14:11:17 +03:00
select HARDIRQS_SW_RESEND
2023-03-23 19:33:52 +03:00
select HAS_IOPORT if MMU
2018-10-29 13:48:53 +03:00
select HAVE_ARCH_AUDITSYSCALL
2022-10-12 15:00:38 +03:00
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
2022-10-12 15:00:37 +03:00
select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT && !XIP_KERNEL
2021-05-10 19:28:38 +03:00
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_KASAN if MMU && 64BIT
2021-01-16 08:58:35 +03:00
select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
2021-06-15 06:07:34 +03:00
select HAVE_ARCH_KFENCE if MMU && 64BIT
2021-05-10 19:28:38 +03:00
select HAVE_ARCH_KGDB if !XIP_KERNEL
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
2022-04-05 10:13:14 +03:00
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
2019-10-05 03:12:22 +03:00
select HAVE_ARCH_SECCOMP_FILTER
2022-12-19 20:28:37 +03:00
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_TRACEHOOK
2021-07-09 20:36:29 +03:00
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU
2023-06-24 09:03:20 +03:00
select HAVE_ARCH_USERFAULTFD_MINOR if 64BIT && USERFAULTFD
riscv: add VMAP_STACK overflow detection
This patch adds stack overflow detection to riscv, usable when
CONFIG_VMAP_STACK=y.
Overflow is detected in kernel exception entry(kernel/entry.S), if the
kernel stack is overflow and been detected, the overflow handler is
invoked on a per-cpu overflow stack. This approach preserves GPRs and
the original exception information.
The overflow detect is performed before any attempt is made to access
the stack and the principle of stack overflow detection: kernel stacks
are aligned to double their size, enabling overflow to be detected with
a single bit test. For example, a 16K stack is aligned to 32K, ensuring
that bit 14 of the SP must be zero. On an overflow (or underflow), this
bit is flipped. Thus, overflow (of less than the size of the stack) can
be detected by testing whether this bit is set.
This gives us a useful error message on stack overflow, as can be
trigger with the LKDTM overflow test:
[ 388.053267] lkdtm: Performing direct entry EXHAUST_STACK
[ 388.053663] lkdtm: Calling function with 1024 frame size to depth 32 ...
[ 388.054016] lkdtm: loop 32/32 ...
[ 388.054186] lkdtm: loop 31/32 ...
[ 388.054491] lkdtm: loop 30/32 ...
[ 388.054672] lkdtm: loop 29/32 ...
[ 388.054859] lkdtm: loop 28/32 ...
[ 388.055010] lkdtm: loop 27/32 ...
[ 388.055163] lkdtm: loop 26/32 ...
[ 388.055309] lkdtm: loop 25/32 ...
[ 388.055481] lkdtm: loop 24/32 ...
[ 388.055653] lkdtm: loop 23/32 ...
[ 388.055837] lkdtm: loop 22/32 ...
[ 388.056015] lkdtm: loop 21/32 ...
[ 388.056188] lkdtm: loop 20/32 ...
[ 388.058145] Insufficient stack space to handle exception!
[ 388.058153] Task stack: [0xffffffd014260000..0xffffffd014264000]
[ 388.058160] Overflow stack: [0xffffffe1f8d2c220..0xffffffe1f8d2d220]
[ 388.058168] CPU: 0 PID: 89 Comm: bash Not tainted 5.12.0-rc8-dirty #90
[ 388.058175] Hardware name: riscv-virtio,qemu (DT)
[ 388.058187] epc : number+0x32/0x2c0
[ 388.058247] ra : vsnprintf+0x2ae/0x3f0
[ 388.058255] epc : ffffffe0002d38f6 ra : ffffffe0002d814e sp : ffffffd01425ffc0
[ 388.058263] gp : ffffffe0012e4010 tp : ffffffe08014da00 t0 : ffffffd0142606e8
[ 388.058271] t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffd014260070
[ 388.058303] s1 : ffffffd014260158 a0 : ffffffd01426015e a1 : ffffffd014260158
[ 388.058311] a2 : 0000000000000013 a3 : ffff0a01ffffff10 a4 : ffffffe000c398e0
[ 388.058319] a5 : 511b02ec65f3e300 a6 : 0000000000a1749a a7 : 0000000000000000
[ 388.058327] s2 : ffffffff000000ff s3 : 00000000ffff0a01 s4 : ffffffe0012e50a8
[ 388.058335] s5 : 0000000000ffff0a s6 : ffffffe0012e50a8 s7 : ffffffe000da1cc0
[ 388.058343] s8 : ffffffffffffffff s9 : ffffffd0142602b0 s10: ffffffd0142602a8
[ 388.058351] s11: ffffffd01426015e t3 : 00000000000f0000 t4 : ffffffffffffffff
[ 388.058359] t5 : 000000000000002f t6 : ffffffd014260158
[ 388.058366] status: 0000000000000100 badaddr: ffffffd01425fff8 cause: 000000000000000f
[ 388.058374] Kernel panic - not syncing: Kernel stack overflow
[ 388.058381] CPU: 0 PID: 89 Comm: bash Not tainted 5.12.0-rc8-dirty #90
[ 388.058387] Hardware name: riscv-virtio,qemu (DT)
[ 388.058393] Call Trace:
[ 388.058400] [<ffffffe000004944>] walk_stackframe+0x0/0xce
[ 388.058406] [<ffffffe0006f0b28>] dump_backtrace+0x38/0x46
[ 388.058412] [<ffffffe0006f0b46>] show_stack+0x10/0x18
[ 388.058418] [<ffffffe0006f3690>] dump_stack+0x74/0x8e
[ 388.058424] [<ffffffe0006f0d52>] panic+0xfc/0x2b2
[ 388.058430] [<ffffffe0006f0acc>] print_trace_address+0x0/0x24
[ 388.058436] [<ffffffe0002d814e>] vsnprintf+0x2ae/0x3f0
[ 388.058956] SMP: stopping secondary CPUs
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-06-21 06:28:55 +03:00
select HAVE_ARCH_VMAP_STACK if MMU && 64BIT
2019-08-19 08:54:20 +03:00
select HAVE_ASM_MODVERSIONS
2022-06-08 17:40:24 +03:00
select HAVE_CONTEXT_TRACKING_USER
2020-06-27 13:50:50 +03:00
select HAVE_DEBUG_KMEMLEAK
2019-10-28 15:10:41 +03:00
select HAVE_DMA_CONTIGUOUS if MMU
2023-05-23 19:54:59 +03:00
select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && MMU && (CLANG_SUPPORTS_DYNAMIC_FTRACE || GCC_SUPPORTS_DYNAMIC_FTRACE)
select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
select HAVE_FUNCTION_GRAPH_TRACER
2023-07-07 20:07:19 +03:00
select HAVE_FUNCTION_GRAPH_RETVAL if HAVE_FUNCTION_GRAPH_TRACER
2023-05-23 19:54:59 +03:00
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && !PREEMPTION
2020-06-04 23:55:14 +03:00
select HAVE_EBPF_JIT if MMU
2022-12-19 20:28:37 +03:00
select HAVE_FUNCTION_ARG_ACCESS_API
2020-12-17 19:01:45 +03:00
select HAVE_FUNCTION_ERROR_INJECTION
2020-06-26 15:40:56 +03:00
select HAVE_GCC_PLUGINS
2020-06-09 17:14:48 +03:00
select HAVE_GENERIC_VDSO if MMU && 64BIT
2020-10-28 07:28:42 +03:00
select HAVE_IRQ_TIME_ACCOUNTING
2021-05-10 19:28:38 +03:00
select HAVE_KPROBES if !XIP_KERNEL
select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
select HAVE_KRETPROBES if !XIP_KERNEL
2023-06-23 20:06:17 +03:00
# https://github.com/ClangBuiltLinux/linux/issues/1881
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
2021-04-16 19:37:22 +03:00
select HAVE_MOVE_PMD
select HAVE_MOVE_PUD
2020-06-04 23:55:14 +03:00
select HAVE_PCI
2018-04-20 02:27:49 +03:00
select HAVE_PERF_EVENTS
2019-09-05 06:46:35 +03:00
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
2022-10-02 07:49:31 +03:00
select HAVE_POSIX_CPU_TIMERS_TASK_WORK
riscv: support PREEMPT_DYNAMIC with static keys
Currently, each architecture can support PREEMPT_DYNAMIC through
either static calls or static keys. To support PREEMPT_DYNAMIC on
riscv, we face three choices:
1. only add static calls support to riscv
As Mark pointed out in commit 99cf983cc8bc ("sched/preempt: Add
PREEMPT_DYNAMIC using static keys"), static keys "...should have
slightly lower overhead than non-inline static calls, as this
effectively inlines each trampoline into the start of its callee. This
may avoid redundant work, and may integrate better with CFI schemes."
So even we add static calls(without inline static calls) to riscv,
static keys is still a better choice.
2. add static calls and inline static calls to riscv
Per my understanding, inline static calls requires objtool support
which is not easy.
3. use static keys
While riscv doesn't have static calls support, it supports static keys
perfectly. So this patch selects HAVE_PREEMPT_DYNAMIC_KEY to enable
support for PREEMPT_DYNAMIC on riscv, so that the preemption model can
be chosen at boot time. It also patches asm-generic/preempt.h, mainly
to add __preempt_schedule() and __preempt_schedule_notrace() macros
for PREEMPT_DYNAMIC case. Other architectures which use generic
preempt.h can also benefit from this patch by simply selecting
HAVE_PREEMPT_DYNAMIC_KEY to enable PREEMPT_DYNAMIC if they supports
static keys.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230716164925.1858-1-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-16 19:49:25 +03:00
select HAVE_PREEMPT_DYNAMIC_KEY if !XIP_KERNEL
2020-12-17 19:01:37 +03:00
select HAVE_REGS_AND_STACK_ACCESS_API
2023-05-23 19:54:59 +03:00
select HAVE_RETHOOK if !XIP_KERNEL
2022-12-19 20:28:37 +03:00
select HAVE_RSEQ
2020-07-10 19:19:57 +03:00
select HAVE_STACKPROTECTOR
2018-12-06 18:26:35 +03:00
select HAVE_SYSCALL_TRACEPOINTS
2023-05-13 00:07:40 +03:00
select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
2017-07-11 04:08:08 +03:00
select IRQ_DOMAIN
2021-07-08 04:59:47 +03:00
select IRQ_FORCED_THREADING
2023-02-03 10:52:32 +03:00
select KASAN_VMALLOC if KASAN
2023-06-22 21:18:18 +03:00
select LOCK_MM_AND_FIND_VMA
2017-07-11 04:08:08 +03:00
select MODULES_USE_ELF_RELA if MODULES
RISC-V: Support MODULE_SECTIONS mechanism on RV32
This patch supports dynamic generate got and plt sections mechanism on
rv32. It contains the modification as follows:
- Always enable MODULE_SECTIONS (both rv64 and rv32)
- Change the fixed size type.
This patch had been tested by following modules:
btrfs 6795991 0 - Live 0xa544b000
test_static_keys 17304 0 - Live 0xa28be000
zstd_compress 1198986 1 btrfs, Live 0xa2a25000
zstd_decompress 608112 1 btrfs, Live 0xa24e7000
lzo 8787 0 - Live 0xa2049000
xor 27461 1 btrfs, Live 0xa2041000
zram 78849 0 - Live 0xa2276000
netdevsim 55909 0 - Live 0xa202d000
tun 211534 0 - Live 0xa21b5000
fuse 566049 0 - Live 0xa25fb000
nfs_layout_flexfiles 192597 0 - Live 0xa229b000
ramoops 74895 0 - Live 0xa2019000
xfs 3973221 0 - Live 0xa507f000
libcrc32c 3053 2 btrfs,xfs, Live 0xa34af000
lzo_compress 17302 2 btrfs,lzo, Live 0xa347d000
lzo_decompress 7178 2 btrfs,lzo, Live 0xa3451000
raid6_pq 142086 1 btrfs, Live 0xa33a4000
reed_solomon 31022 1 ramoops, Live 0xa31eb000
test_bitmap 3734 0 - Live 0xa31af000
test_bpf 1588736 0 - Live 0xa2c11000
test_kmod 41161 0 - Live 0xa29f8000
test_module 1356 0 - Live 0xa299e000
test_printf 6024 0 [permanent], Live 0xa2971000
test_static_key_base 5797 1 test_static_keys, Live 0xa2931000
test_user_copy 4382 0 - Live 0xa28c9000
xxhash 70501 2 zstd_compress,zstd_decompress, Live 0xa2055000
Signed-off-by: Zong Li <zong@andestech.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-12-07 12:02:16 +03:00
select MODULE_SECTIONS if MODULES
2020-06-04 23:55:14 +03:00
select OF
select OF_EARLY_FLATTREE
select OF_IRQ
2018-11-15 22:05:33 +03:00
select PCI_DOMAINS_GENERIC if PCI
2018-11-15 22:05:32 +03:00
select PCI_MSI if PCI
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 13:05:39 +03:00
select RISCV_ALTERNATIVE if !XIP_KERNEL
2020-06-01 12:15:43 +03:00
select RISCV_INTC
2020-08-17 15:42:50 +03:00
select RISCV_TIMER if RISCV_SBI
2022-11-18 13:43:01 +03:00
select SIFIVE_PLIC
2020-06-04 23:55:14 +03:00
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
2021-07-31 08:22:32 +03:00
select TRACE_IRQFLAGS_SUPPORT
2020-09-07 08:58:22 +03:00
select UACCESS_MEMCPY if !MMU
2021-07-01 04:52:20 +03:00
select ZONE_DMA32 if 64BIT
2019-09-24 01:39:21 +03:00
2023-04-04 23:34:21 +03:00
config CLANG_SUPPORTS_DYNAMIC_FTRACE
def_bool CC_IS_CLANG
# https://github.com/llvm/llvm-project/commit/6ab8927931851bb42b2c93a00801dc499d7d9b1e
depends on CLANG_VERSION >= 130000
# https://github.com/ClangBuiltLinux/linux/issues/1817
depends on AS_IS_GNU || (AS_IS_LLVM && (LD_IS_LLD || LD_VERSION >= 23600))
config GCC_SUPPORTS_DYNAMIC_FTRACE
def_bool CC_IS_GCC
depends on $(cc-option,-fpatchable-function-entry=8)
2019-09-24 01:39:21 +03:00
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
default 8
2022-04-05 10:13:14 +03:00
config ARCH_MMAP_RND_COMPAT_BITS_MIN
default 8
2019-09-24 01:39:21 +03:00
# max bits determined by the following formula:
# VA_BITS - PAGE_SHIFT - 3
config ARCH_MMAP_RND_BITS_MAX
default 24 if 64BIT # SV39 based
default 17
2017-07-11 04:08:08 +03:00
2022-04-05 10:13:14 +03:00
config ARCH_MMAP_RND_COMPAT_BITS_MAX
default 17
2019-10-28 15:10:32 +03:00
# set if we run in machine mode, cleared if we run in supervisor mode
config RISCV_M_MODE
bool
2019-10-28 15:10:41 +03:00
default !MMU
2019-10-28 15:10:32 +03:00
2019-10-28 15:10:33 +03:00
# set if we are running in S-mode and can use SBI calls
config RISCV_SBI
bool
depends on !RISCV_M_MODE
default y
2017-07-11 04:08:08 +03:00
config MMU
2019-10-28 15:10:41 +03:00
bool "MMU-based Paged Memory Management Support"
default y
help
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.
2017-07-11 04:08:08 +03:00
config PAGE_OFFSET
hex
2023-03-01 03:26:56 +03:00
default 0xC0000000 if 32BIT && MMU
default 0x80000000 if !MMU
2022-01-27 05:48:43 +03:00
default 0xff60000000000000 if 64BIT
2017-07-11 04:08:08 +03:00
2021-10-29 07:59:27 +03:00
config KASAN_SHADOW_OFFSET
hex
depends on KASAN_GENERIC
2021-12-06 13:46:45 +03:00
default 0xdfffffff00000000 if 64BIT
2021-10-29 07:59:27 +03:00
default 0xffffffff if 32BIT
2019-08-29 00:40:54 +03:00
config ARCH_FLATMEM_ENABLE
2020-11-19 03:38:29 +03:00
def_bool !NUMA
2019-08-29 00:40:54 +03:00
config ARCH_SPARSEMEM_ENABLE
def_bool y
2020-02-12 13:34:24 +03:00
depends on MMU
2021-03-29 06:13:07 +03:00
select SPARSEMEM_STATIC if 32BIT && SPARSEMEM
2021-03-15 15:03:07 +03:00
select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
2019-08-29 00:40:54 +03:00
config ARCH_SELECT_MEMORY_MODEL
def_bool ARCH_SPARSEMEM_ENABLE
2020-12-17 19:01:44 +03:00
config ARCH_SUPPORTS_UPROBES
def_bool y
2017-07-11 04:08:08 +03:00
config STACKTRACE_SUPPORT
def_bool y
config GENERIC_BUG
def_bool y
depends on BUG
select GENERIC_BUG_RELATIVE_POINTERS if 64BIT
config GENERIC_BUG_RELATIVE_POINTERS
bool
config GENERIC_CALIBRATE_DELAY
def_bool y
config GENERIC_CSUM
def_bool y
config GENERIC_HWEIGHT
def_bool y
2019-01-07 18:27:01 +03:00
config FIX_EARLYCON_MEM
2019-12-17 14:15:16 +03:00
def_bool MMU
2019-01-07 18:27:01 +03:00
2017-07-11 04:08:08 +03:00
config PGTABLE_LEVELS
int
2022-01-27 05:48:43 +03:00
default 5 if 64BIT
2017-07-11 04:08:08 +03:00
default 2
2020-06-27 16:57:08 +03:00
config LOCKDEP_SUPPORT
def_bool y
2022-07-07 02:15:35 +03:00
config RISCV_DMA_NONCOHERENT
bool
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_SETUP_DMA_OPS
2022-12-19 20:28:37 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
riscv: enable DMA_BOUNCE_UNALIGNED_KMALLOC for !dma_coherent
With the DMA bouncing of unaligned kmalloc() buffers now in place,
enable it for riscv when RISCV_DMA_NONCOHERENT=y to allow the
kmalloc-{8,16,32,96} caches. Since RV32 doesn't enable SWIOTLB
yet, and I didn't see any dma noncoherent RV32 platforms in the
mainline, so skip RV32 now by only enabling
DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB is available. Once we see
such requirement on RV32, we can enable it then.
NOTE: we didn't force to create the swiotlb buffer even when the
end of RAM is within the 32-bit physical address range. That's to
say:
For RV64 with > 4GB memory, the feature is enabled.
For RV64 with <= 4GB memory, the feature isn't enabled by default. We
rely on users to pass "swiotlb=mmnn,force" where mmnn is the Number of
I/O TLB slabs, see kernel-parameters.txt for details.
Tested on Sipeed Lichee Pi 4A with 8GB DDR and Sipeed M1S BL808 Dock
board.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230718152214.2907-3-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-18 18:22:14 +03:00
select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
2023-09-01 13:51:11 +03:00
select DMA_DIRECT_REMAP if MMU
2022-07-07 02:15:35 +03:00
2023-08-18 16:57:20 +03:00
config RISCV_NONSTANDARD_CACHE_OPS
bool
depends on RISCV_DMA_NONCOHERENT
help
This enables function pointer support for non-standard noncoherent
systems to handle cache management.
2022-10-02 07:48:07 +03:00
config AS_HAS_INSN
def_bool $(as-instr,.insn r 51$(comma) 0$(comma) 0$(comma) t0$(comma) t0$(comma) zero)
2023-06-05 14:07:20 +03:00
config AS_HAS_OPTION_ARCH
# https://reviews.llvm.org/D123515
def_bool y
depends on $(as-instr, .option arch$(comma) +m)
depends on !$(as-instr, .option arch$(comma) -i)
2019-06-17 22:29:48 +03:00
source "arch/riscv/Kconfig.socs"
2023-02-24 18:45:57 +03:00
source "arch/riscv/Kconfig.errata"
2019-06-17 22:29:48 +03:00
2017-07-11 04:08:08 +03:00
menu "Platform type"
2022-05-21 22:33:57 +03:00
config NONPORTABLE
bool "Allow configurations that result in non-portable kernels"
help
RISC-V kernel binaries are compatible between all known systems
whenever possible, but there are some use cases that can only be
satisfied by configurations that result in kernel binaries that are
not portable between systems.
Selecting N does not guarantee kernels will be portable to all known
systems. Selecting any of the options guarded by NONPORTABLE will
result in kernel binaries that are unlikely to be portable between
systems.
If unsure, say N.
2017-07-11 04:08:08 +03:00
choice
prompt "Base ISA"
default ARCH_RV64I
help
2019-01-08 22:45:57 +03:00
This selects the base ISA that this kernel will target and must match
2017-07-11 04:08:08 +03:00
the target platform.
config ARCH_RV32I
bool "RV32I"
2022-05-21 22:33:57 +03:00
depends on NONPORTABLE
2017-07-11 04:08:08 +03:00
select 32BIT
2018-04-11 10:50:17 +03:00
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
2018-06-25 11:49:38 +03:00
select GENERIC_LIB_UCMPDI2
2017-07-11 04:08:08 +03:00
config ARCH_RV64I
bool "RV64I"
select 64BIT
2021-09-11 02:40:42 +03:00
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
2019-10-28 15:10:41 +03:00
select SWIOTLB if MMU
2017-07-11 04:08:08 +03:00
endchoice
# We must be able to map all physical memory into the kernel, but the compiler
# is still a bit more efficient when generating code if it's setup in a manner
# such that it can only map 2GiB of memory.
choice
prompt "Kernel Code Model"
default CMODEL_MEDLOW if 32BIT
default CMODEL_MEDANY if 64BIT
config CMODEL_MEDLOW
bool "medium low code model"
config CMODEL_MEDANY
bool "medium any code model"
endchoice
2018-03-15 11:50:41 +03:00
config MODULE_SECTIONS
bool
select HAVE_MOD_ARCH_SPECIFIC
2017-07-11 04:08:08 +03:00
config SMP
bool "Symmetric Multi-Processing"
help
This enables support for systems with more than one CPU. If
you say N here, the kernel will run on single 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, single processor machines. On a single
processor machine, the kernel will run faster if you say N
here.
If you don't know what to do here, say N.
2023-03-10 14:03:36 +03:00
config SCHED_MC
bool "Multi-core scheduler support"
depends on SMP
help
Multi-core scheduler support improves the CPU scheduler's decision
making when dealing with multi-core CPU chips at a cost of slightly
increased overhead in some places. If unsure say N here.
2017-07-11 04:08:08 +03:00
config NR_CPUS
2022-04-20 14:24:08 +03:00
int "Maximum number of CPUs (2-512)"
2017-07-11 04:08:08 +03:00
depends on SMP
2022-11-26 09:15:56 +03:00
range 2 512 if !RISCV_SBI_V01
range 2 32 if RISCV_SBI_V01 && 32BIT
range 2 64 if RISCV_SBI_V01 && 64BIT
2022-04-20 14:24:08 +03:00
default "32" if 32BIT
default "64" if 64BIT
2017-07-11 04:08:08 +03:00
2020-03-18 04:11:44 +03:00
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
select GENERIC_IRQ_MIGRATION
help
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
Say N if you want to disable CPU hotplug.
2017-07-11 04:08:08 +03:00
choice
prompt "CPU Tuning"
default TUNE_GENERIC
config TUNE_GENERIC
bool "generic"
endchoice
2020-11-19 03:38:29 +03:00
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
2021-03-30 16:25:31 +03:00
depends on SMP && MMU
2022-12-19 20:28:37 +03:00
select ARCH_SUPPORTS_NUMA_BALANCING
2020-11-19 03:38:29 +03:00
select GENERIC_ARCH_NUMA
2022-12-19 20:28:37 +03:00
select NEED_PER_CPU_EMBED_FIRST_CHUNK
2020-11-19 03:38:29 +03:00
select OF_NUMA
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 05:07:41 +03:00
select USE_PERCPU_NUMA_NODE_ID
2020-11-19 03:38:29 +03:00
help
Enable NUMA (Non-Uniform Memory Access) support.
The kernel will try to allocate memory used by a CPU on the
local memory of the CPU and add some more NUMA awareness to the kernel.
config NODES_SHIFT
int "Maximum NUMA Nodes (as a power of 2)"
range 1 10
default "2"
2021-06-29 05:43:01 +03:00
depends on NUMA
2020-11-19 03:38:29 +03:00
help
Specify the maximum number of NUMA Nodes available on the target
system. Increases memory reserved to accommodate various tables.
2022-05-11 22:29:10 +03:00
config RISCV_ALTERNATIVE
bool
depends on !XIP_KERNEL
help
This Kconfig allows the kernel to automatically patch the
2023-02-24 18:45:59 +03:00
erratum or cpufeature required by the execution platform at run
time. The code patching overhead is minimal, as it's only done
once at boot and once on each module load.
2022-05-11 22:29:10 +03:00
2022-05-11 22:29:21 +03:00
config RISCV_ALTERNATIVE_EARLY
bool
depends on RISCV_ALTERNATIVE
help
Allows early patching of the kernel for special errata
2017-07-11 04:08:08 +03:00
config RISCV_ISA_C
bool "Emit compressed instructions when building Linux"
default y
help
2022-05-20 15:02:30 +03:00
Adds "C" to the ISA subsets that the toolchain is allowed to emit
when building Linux, which results in compressed instructions in the
Linux binary.
2017-07-11 04:08:08 +03:00
2022-05-20 15:02:30 +03:00
If you don't know what to do here, say Y.
2017-07-11 04:08:08 +03:00
2023-02-09 16:16:45 +03:00
config RISCV_ISA_SVNAPOT
2023-04-05 13:21:10 +03:00
bool "Svnapot extension support for supervisor mode NAPOT pages"
2023-02-09 16:16:45 +03:00
depends on 64BIT && MMU
2023-03-24 15:12:41 +03:00
depends on RISCV_ALTERNATIVE
2023-02-09 16:16:45 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Allow kernel to detect the Svnapot ISA-extension dynamically at boot
2023-02-09 16:16:45 +03:00
time and enable its usage.
2023-04-05 13:21:10 +03:00
The Svnapot extension is used to mark contiguous PTEs as a range
2023-02-09 16:16:45 +03:00
of contiguous virtual-to-physical translations for a naturally
aligned power-of-2 (NAPOT) granularity larger than the base 4KB page
size. When HUGETLBFS is also selected this option unconditionally
allocates some memory for each NAPOT page size supported by the kernel.
When optimizing for low memory consumption and for platforms without
2023-04-05 13:21:10 +03:00
the Svnapot extension, it may be better to say N here.
2023-02-09 16:16:45 +03:00
If you don't know what to do here, say Y.
2022-05-11 22:29:18 +03:00
config RISCV_ISA_SVPBMT
2023-04-05 13:21:10 +03:00
bool "Svpbmt extension support for supervisor mode page-based memory types"
2022-05-11 22:29:18 +03:00
depends on 64BIT && MMU
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 13:05:39 +03:00
depends on RISCV_ALTERNATIVE
2022-05-11 22:29:18 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Adds support to dynamically detect the presence of the Svpbmt
2022-05-26 23:56:43 +03:00
ISA-extension (Supervisor-mode: page-based memory types) and
enable its usage.
The memory type for a page contains a combination of attributes
that indicate the cacheability, idempotency, and ordering
properties for access to that page.
2022-05-11 22:29:18 +03:00
2023-04-05 13:21:10 +03:00
The Svpbmt extension is only available on 64-bit cpus.
2022-05-11 22:29:18 +03:00
If you don't know what to do here, say Y.
2023-06-05 14:07:21 +03:00
config TOOLCHAIN_HAS_V
bool
default y
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64iv)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32iv)
depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
depends on AS_HAS_OPTION_ARCH
config RISCV_ISA_V
bool "VECTOR extension support"
depends on TOOLCHAIN_HAS_V
depends on FPU
select DYNAMIC_SIGFRAME
default y
help
Say N here if you want to disable all vector related procedure
in the kernel.
If you don't know what to do here, say Y.
config RISCV_ISA_V_DEFAULT_ENABLE
bool "Enable userspace Vector by default"
depends on RISCV_ISA_V
default y
help
Say Y here if you want to enable Vector in userspace by default.
Otherwise, userspace has to make explicit prctl() call to enable
Vector, or enable it via the sysctl interface.
If you don't know what to do here, say Y.
2023-01-14 00:23:01 +03:00
config TOOLCHAIN_HAS_ZBB
2022-07-07 02:15:35 +03:00
bool
2022-10-06 20:35:20 +03:00
default y
2023-01-14 00:23:01 +03:00
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb)
depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
2023-06-05 14:07:20 +03:00
depends on AS_HAS_OPTION_ARCH
2023-01-14 00:23:01 +03:00
config RISCV_ISA_ZBB
bool "Zbb extension support for bit manipulation instructions"
depends on TOOLCHAIN_HAS_ZBB
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 13:05:39 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2023-01-14 00:23:01 +03:00
default y
help
Adds support to dynamically detect the presence of the ZBB
extension (basic bit manipulation) and enable its usage.
The Zbb extension provides instructions to accelerate a number
of bit-specific operations (count bit population, sign extending,
bitrotation, etc).
If you don't know what to do here, say Y.
2022-07-07 02:15:35 +03:00
config RISCV_ISA_ZICBOM
bool "Zicbom extension support for non-coherent DMA operation"
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 13:05:39 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2022-07-07 02:15:35 +03:00
default y
2022-12-19 20:28:37 +03:00
select RISCV_DMA_NONCOHERENT
2022-07-07 02:15:35 +03:00
help
Adds support to dynamically detect the presence of the ZICBOM
extension (Cache Block Management Operations) and enable its
usage.
The Zicbom extension can be used to handle for example
non-coherent DMA support on devices that need it.
If you don't know what to do here, say Y.
2023-02-24 19:26:29 +03:00
config RISCV_ISA_ZICBOZ
bool "Zicboz extension support for faster zeroing of memory"
2023-03-24 15:12:41 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2023-02-24 19:26:29 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Enable the use of the Zicboz extension (cbo.zero instruction)
2023-02-24 19:26:29 +03:00
when available.
The Zicboz extension is used for faster zeroing of memory.
If you don't know what to do here, say Y.
2022-10-06 20:35:21 +03:00
config TOOLCHAIN_HAS_ZIHINTPAUSE
bool
default y
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zihintpause)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause)
depends on LLD_VERSION >= 150000 || LD_VERSION >= 23600
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-14 02:00:23 +03:00
config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
def_bool y
# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
2023-08-09 19:56:48 +03:00
# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
depends on AS_IS_GNU && AS_VERSION >= 23600
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-14 02:00:23 +03:00
help
2023-08-09 19:56:48 +03:00
Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer
20191213 version, which moves some instructions from the I extension to
the Zicsr and Zifencei extensions. This requires explicitly specifying
Zicsr and Zifencei when binutils >= 2.38 or GCC >= 12.1.0. Zicsr
and Zifencei are supported in binutils from version 2.36 onwards.
To make life easier, and avoid forcing toolchains that default to a
newer ISA spec to version 2.2, relax the check to binutils >= 2.36.
2023-08-24 22:08:52 +03:00
For clang < 17 or GCC < 11.3.0, for which this is not possible or need
special treatment, this is dealt with in TOOLCHAIN_NEEDS_OLD_ISA_SPEC.
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-14 02:00:23 +03:00
config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
def_bool y
depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
2023-08-24 22:08:52 +03:00
# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d29f5d6ab513c52fd872f532c492e35ae9fd6671
depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110300)
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-14 02:00:23 +03:00
help
2023-08-09 19:56:48 +03:00
Certain versions of clang and GCC do not support zicsr and zifencei via
-march. This option causes an older ISA spec compatible with these older
versions of clang and GCC to be passed to GAS, which has the same result
as passing zicsr and zifencei to -march.
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-14 02:00:23 +03:00
2018-10-09 05:18:33 +03:00
config FPU
bool "FPU support"
default y
help
Say N here if you want to disable all floating-point related procedure
in the kernel.
If you don't know what to do here, say Y.
2023-06-14 04:30:16 +03:00
config IRQ_STACKS
2023-06-14 04:30:17 +03:00
bool "Independent irq & softirq stacks" if EXPERT
2023-06-14 04:30:16 +03:00
default y
select HAVE_IRQ_EXIT_ON_IRQ_STACK
2023-06-14 04:30:17 +03:00
select HAVE_SOFTIRQ_ON_OWN_STACK
2023-06-14 04:30:16 +03:00
help
2023-06-14 04:30:17 +03:00
Add independent irq & softirq stacks for percpu to prevent kernel stack
overflows. We may save some memory footprint by disabling IRQ_STACKS.
2023-06-14 04:30:16 +03:00
2023-06-14 04:30:18 +03:00
config THREAD_SIZE_ORDER
int "Kernel stack size (in power-of-two numbers of page size)" if VMAP_STACK && EXPERT
range 0 4
default 1 if 32BIT && !KASAN
default 3 if 64BIT && KASAN
default 2
help
Specify the Pages of thread stack size (from 4KB to 64KB), which also
affects irq stack size, which is equal to thread stack size.
2022-05-20 15:02:30 +03:00
endmenu # "Platform type"
2017-07-11 04:08:08 +03:00
2018-09-20 01:48:15 +03:00
menu "Kernel features"
2017-07-11 04:08:08 +03:00
source "kernel/Kconfig.hz"
2020-03-18 04:11:37 +03:00
config RISCV_SBI_V01
bool "SBI v0.1 support"
depends on RISCV_SBI
help
This config allows kernel to use SBI v0.1 APIs. This will be
deprecated in future once legacy M-mode software are no longer in use.
2021-04-19 03:55:36 +03:00
2022-01-20 12:09:17 +03:00
config RISCV_BOOT_SPINWAIT
bool "Spinwait booting method"
depends on SMP
2022-04-21 20:03:55 +03:00
default y if RISCV_SBI_V01 || RISCV_M_MODE
2022-01-20 12:09:17 +03:00
help
This enables support for booting Linux via spinwait method. In the
spinwait method, all cores randomly jump to Linux. One of the cores
gets chosen via lottery and all other keep spinning on a percpu
variable. This method cannot support CPU hotplug and sparse hartid
scheme. It should be only enabled for M-mode Linux or platforms relying
on older firmware without SBI HSM extension. All other platforms should
rely on ordered booting via SBI HSM extension which gets chosen
dynamically at runtime if the firmware supports it.
2022-04-21 20:03:55 +03:00
Since spinwait is incompatible with sparse hart IDs, it requires
NR_CPUS be large enough to contain the physical hart ID of the first
hart to enter Linux.
If unsure what to do here, say N.
2023-07-12 19:15:42 +03:00
config ARCH_SUPPORTS_KEXEC
def_bool MMU
config ARCH_SELECTS_KEXEC
def_bool y
depends on KEXEC
2022-12-19 20:28:37 +03:00
select HOTPLUG_CPU if SMP
2021-04-19 03:55:36 +03:00
2023-07-12 19:15:42 +03:00
config ARCH_SUPPORTS_KEXEC_FILE
def_bool 64BIT && MMU
2021-04-19 03:55:36 +03:00
2023-07-12 19:15:42 +03:00
config ARCH_SELECTS_KEXEC_FILE
def_bool y
depends on KEXEC_FILE
2022-12-19 20:28:37 +03:00
select HAVE_IMA_KEXEC if IMA
2022-04-08 13:09:11 +03:00
select KEXEC_ELF
2023-07-12 19:15:45 +03:00
config ARCH_SUPPORTS_KEXEC_PURGATORY
2022-04-08 13:09:13 +03:00
def_bool KEXEC_FILE
depends on CRYPTO=y
depends on CRYPTO_SHA256=y
2023-07-12 19:15:42 +03:00
config ARCH_SUPPORTS_CRASH_DUMP
def_bool y
2021-04-19 03:55:36 +03:00
2022-04-05 10:13:14 +03:00
config COMPAT
bool "Kernel support for 32-bit U-mode"
default 64BIT
depends on 64BIT && MMU
help
This option enables support for a 32-bit U-mode running under a 64-bit
kernel at S-mode. riscv32-specific components such as system calls,
the user helper functions (vdso), signal rt_frame functions and the
ptrace interface are handled appropriately by the kernel.
If you want to execute 32-bit userspace applications, say Y.
2023-03-29 07:53:26 +03:00
config RELOCATABLE
bool "Build a relocatable kernel"
depends on MMU && 64BIT && !XIP_KERNEL
help
This builds a kernel as a Position Independent Executable (PIE),
which retains all relocation metadata required to relocate the
kernel binary at runtime to a different virtual address than the
address it was linked at.
Since RISCV uses the RELA relocation format, this requires a
relocation pass at runtime even if the kernel is loaded at the
same address it was linked at.
If unsure, say N.
2023-07-22 15:38:46 +03:00
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image"
select RELOCATABLE
depends on MMU && 64BIT && !XIP_KERNEL
help
Randomizes the 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.
It is the bootloader's job to provide entropy, by passing a
random u64 value in /chosen/kaslr-seed at kernel entry.
When booting via the UEFI stub, it will invoke the firmware's
EFI_RNG_PROTOCOL implementation (if available) to supply entropy
to the kernel proper. In addition, it will randomise the physical
location of the kernel Image as well.
If unsure, say N.
2022-05-20 15:02:30 +03:00
endmenu # "Kernel features"
2017-07-11 04:08:08 +03:00
2018-09-20 01:48:15 +03:00
menu "Boot options"
2018-11-18 03:06:56 +03:00
config CMDLINE
string "Built-in kernel command line"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03:00
For most platforms, the arguments for the kernel's command line
are provided at run-time, during boot. However, there are cases
where either no arguments are being provided or the provided
arguments are insufficient or even invalid.
2018-09-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
When that occurs, it is possible to define a built-in command
line here and choose how the kernel should use it later on.
2018-09-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
choice
prompt "Built-in command line usage" if CMDLINE != ""
default CMDLINE_FALLBACK
help
Choose how the kernel will handle the provided built-in command
line.
2018-09-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
config CMDLINE_FALLBACK
bool "Use bootloader kernel arguments if available"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03:00
Use the built-in command line as fallback in case we get nothing
during boot. This is the default behaviour.
config CMDLINE_EXTEND
bool "Extend bootloader kernel arguments"
help
The command-line arguments provided during boot will be
appended to the built-in command line. This is useful in
cases where the provided arguments are insufficient and
you don't want to or cannot modify them.
2018-09-20 01:48:15 +03:00
config CMDLINE_FORCE
2018-11-18 03:06:56 +03:00
bool "Always use the default kernel command string"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03:00
Always use the built-in command line, even if we get one during
boot. This is useful in case you need to override the provided
command line on systems where you don't have or want control
over it.
2018-09-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
endchoice
2018-09-20 01:48:15 +03:00
2020-09-18 01:37:14 +03:00
config EFI_STUB
bool
config EFI
bool "UEFI runtime support"
2021-04-13 09:35:14 +03:00
depends on OF && !XIP_KERNEL
2022-12-19 20:28:37 +03:00
depends on MMU
default y
2023-05-15 08:49:13 +03:00
select ARCH_SUPPORTS_ACPI if 64BIT
2020-09-18 01:37:14 +03:00
select EFI_GENERIC_STUB
2022-12-19 20:28:37 +03:00
select EFI_PARAMS_FROM_FDT
2020-09-18 01:37:15 +03:00
select EFI_RUNTIME_WRAPPERS
2022-12-19 20:28:37 +03:00
select EFI_STUB
select LIBFDT
2020-09-18 01:37:14 +03:00
select RISCV_ISA_C
2022-12-19 20:28:37 +03:00
select UCS2_STRING
2020-09-18 01:37:14 +03:00
help
This option provides support for runtime services provided
by UEFI firmware (such as non-volatile variables, realtime
clock, and platform reset). A UEFI stub is also provided to
allow the kernel to be booted as an EFI application. This
is only useful on systems that have UEFI firmware.
riscv: Enable per-task stack canaries
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.
After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.
x86: Use a fix offset from gs, not flexible.
struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
char gs_base[40]; // :(
unsigned long stack_canary;
};
arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx
riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx
GCC's implementation has been merged:
commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
Author: Cooper Qu <cooper.qu@linux.alibaba.com>
Date: Mon Jul 13 16:15:08 2020 +0800
RISC-V: Add support for TLS stack protector canary access
In the end, these codes are inserted by gcc before return:
* 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
* 0xffffffe00020b39a <+124>: xor a5,a5,a4
* 0xffffffe00020b39c <+126>: mv a0,s5
* 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766>
0xffffffe00020b3a2 <+132>: ld ra,136(sp)
0xffffffe00020b3a4 <+134>: ld s0,128(sp)
0xffffffe00020b3a6 <+136>: ld s1,120(sp)
0xffffffe00020b3a8 <+138>: ld s2,112(sp)
0xffffffe00020b3aa <+140>: ld s3,104(sp)
0xffffffe00020b3ac <+142>: ld s4,96(sp)
0xffffffe00020b3ae <+144>: ld s5,88(sp)
0xffffffe00020b3b0 <+146>: ld s6,80(sp)
0xffffffe00020b3b2 <+148>: ld s7,72(sp)
0xffffffe00020b3b4 <+150>: addi sp,sp,144
0xffffffe00020b3b6 <+152>: ret
...
* 0xffffffe00020b61c <+766>: auipc ra,0x7f8
* 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Cooper Qu <cooper.qu@linux.alibaba.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-12-17 19:29:18 +03:00
config CC_HAVE_STACKPROTECTOR_TLS
def_bool $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
config STACKPROTECTOR_PER_TASK
def_bool y
2022-05-03 23:55:00 +03:00
depends on !RANDSTRUCT
riscv: Enable per-task stack canaries
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.
After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.
x86: Use a fix offset from gs, not flexible.
struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
char gs_base[40]; // :(
unsigned long stack_canary;
};
arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx
riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx
GCC's implementation has been merged:
commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
Author: Cooper Qu <cooper.qu@linux.alibaba.com>
Date: Mon Jul 13 16:15:08 2020 +0800
RISC-V: Add support for TLS stack protector canary access
In the end, these codes are inserted by gcc before return:
* 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
* 0xffffffe00020b39a <+124>: xor a5,a5,a4
* 0xffffffe00020b39c <+126>: mv a0,s5
* 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766>
0xffffffe00020b3a2 <+132>: ld ra,136(sp)
0xffffffe00020b3a4 <+134>: ld s0,128(sp)
0xffffffe00020b3a6 <+136>: ld s1,120(sp)
0xffffffe00020b3a8 <+138>: ld s2,112(sp)
0xffffffe00020b3aa <+140>: ld s3,104(sp)
0xffffffe00020b3ac <+142>: ld s4,96(sp)
0xffffffe00020b3ae <+144>: ld s5,88(sp)
0xffffffe00020b3b0 <+146>: ld s6,80(sp)
0xffffffe00020b3b2 <+148>: ld s7,72(sp)
0xffffffe00020b3b4 <+150>: addi sp,sp,144
0xffffffe00020b3b6 <+152>: ret
...
* 0xffffffe00020b61c <+766>: auipc ra,0x7f8
* 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Cooper Qu <cooper.qu@linux.alibaba.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-12-17 19:29:18 +03:00
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
2021-07-21 10:59:36 +03:00
config PHYS_RAM_BASE_FIXED
bool "Explicitly specified physical RAM address"
2022-05-21 22:33:57 +03:00
depends on NONPORTABLE
2021-07-21 10:59:36 +03:00
default n
2021-04-13 09:35:14 +03:00
config PHYS_RAM_BASE
hex "Platform Physical RAM address"
2021-07-21 10:59:36 +03:00
depends on PHYS_RAM_BASE_FIXED
2021-04-13 09:35:14 +03:00
default "0x80000000"
help
This is the physical address of RAM in the system. It has to be
explicitly specified to run early relocations of read-write data
from flash to RAM.
config XIP_KERNEL
bool "Kernel Execute-In-Place from ROM"
2022-05-21 22:33:57 +03:00
depends on MMU && SPARSEMEM && NONPORTABLE
2021-04-13 09:35:14 +03:00
# This prevents XIP from being enabled by all{yes,mod}config, which
# fail to build since XIP doesn't support large kernels.
depends on !COMPILE_TEST
2021-07-21 10:59:36 +03:00
select PHYS_RAM_BASE_FIXED
2021-04-13 09:35:14 +03:00
help
Execute-In-Place allows the kernel to run from non-volatile storage
directly addressable by the CPU, such as NOR flash. This saves RAM
space since the text section of the kernel is not loaded from flash
to RAM. Read-write sections, such as the data section and stack,
are still copied to RAM. The XIP kernel is not compressed since
it has to run directly from flash, so it will take more space to
store it. The flash address used to link the kernel object files,
and for storing it, is configuration dependent. Therefore, if you
say Y here, you must know the proper physical address where to
store the kernel image depending on your own flash memory usage.
Also note that the make target becomes "make xipImage" rather than
"make zImage" or "make Image". The final kernel binary to put in
ROM memory will be arch/riscv/boot/xipImage.
SPARSEMEM is required because the kernel text and rodata that are
flash resident are not backed by memmap, then any attempt to get
a struct page on those regions will trigger a fault.
If unsure, say N.
config XIP_PHYS_ADDR
hex "XIP Kernel Physical Location"
depends on XIP_KERNEL
default "0x21000000"
help
This is the physical address in your flash memory the kernel will
be linked for and stored to. This address is dependent on your
own flash usage.
2023-07-13 15:11:09 +03:00
config RISCV_ISA_FALLBACK
bool "Permit falling back to parsing riscv,isa for extension support by default"
default y
help
Parsing the "riscv,isa" devicetree property has been deprecated and
replaced by a list of explicitly defined strings. For compatibility
with existing platforms, the kernel will fall back to parsing the
"riscv,isa" property if the replacements are not found.
Selecting N here will result in a kernel that does not use the
fallback, unless the commandline "riscv_isa_fallback" parameter is
present.
Please see the dt-binding, located at
Documentation/devicetree/bindings/riscv/extensions.yaml for details
on the replacement properties, "riscv,isa-base" and
"riscv,isa-extensions".
2022-05-20 15:02:30 +03:00
endmenu # "Boot options"
2018-09-20 01:48:15 +03:00
2020-04-14 07:43:24 +03:00
config BUILTIN_DTB
2021-04-13 09:35:14 +03:00
bool
2022-05-21 22:33:57 +03:00
depends on OF && NONPORTABLE
2021-04-13 09:35:14 +03:00
default y if XIP_KERNEL
2020-04-14 07:43:24 +03:00
2022-05-21 22:33:57 +03:00
config PORTABLE
bool
default !NONPORTABLE
select EFI
select MMU
2022-12-19 20:28:37 +03:00
select OF
2022-05-21 22:33:57 +03:00
2017-07-11 04:08:08 +03:00
menu "Power management options"
2018-12-11 14:01:04 +03:00
source "kernel/power/Kconfig"
2017-07-11 04:08:08 +03:00
RISC-V: mark hibernation as nonportable
Hibernation support depends on firmware marking its reserved/PMP
protected regions as not accessible from Linux.
The latest versions of the de-facto SBI implementation (OpenSBI) do
not do this, having dropped the no-map property to enable 1 GiB huge
page mappings by the kernel.
This was exposed by commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages
for the linear mapping"), which made the first 2 MiB of DRAM (where SBI
typically resides) accessible by the kernel.
Attempting to hibernate with either OpenSBI, or other implementations
following its lead, will lead to a kernel panic ([1], [2]) as the
hibernation process will attempt to save/restore any mapped regions,
including the PMP protected regions in use by the SBI implementation.
Mark hibernation as depending on "NONPORTABLE", as only a small subset
of systems are capable of supporting it, until such time that an SBI
implementation independent way to communicate what regions are in use
has been agreed on.
As hibernation support landed in v6.4-rc1, disabling it for most
platforms does not constitute a regression. The alternative would have
been reverting commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for
the linear mapping").
Doing so would permit hibernation on platforms with these SBI
implementations, but would limit the options we have to solve the
protection of the region without causing a regression in hibernation
support.
Reported-by: Song Shuai <suagrfillet@gmail.com>
Link: https://lore.kernel.org/all/CAAYs2=gQvkhTeioMmqRDVGjdtNF_vhB+vm_1dHJxPNi75YDQ_Q@mail.gmail.com/ [1]
Reported-by: JeeHeng Sia <jeeheng.sia@starfivetech.com>
Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ITXwaKfA6z8 [2]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230526-astride-detonator-9ae120051159@wendy
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-05-26 13:59:08 +03:00
# Hibernation is only possible on systems where the SBI implementation has
# marked its reserved memory as not accessible from, or does not run
# from the same memory as, Linux
2023-03-30 09:43:21 +03:00
config ARCH_HIBERNATION_POSSIBLE
RISC-V: mark hibernation as nonportable
Hibernation support depends on firmware marking its reserved/PMP
protected regions as not accessible from Linux.
The latest versions of the de-facto SBI implementation (OpenSBI) do
not do this, having dropped the no-map property to enable 1 GiB huge
page mappings by the kernel.
This was exposed by commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages
for the linear mapping"), which made the first 2 MiB of DRAM (where SBI
typically resides) accessible by the kernel.
Attempting to hibernate with either OpenSBI, or other implementations
following its lead, will lead to a kernel panic ([1], [2]) as the
hibernation process will attempt to save/restore any mapped regions,
including the PMP protected regions in use by the SBI implementation.
Mark hibernation as depending on "NONPORTABLE", as only a small subset
of systems are capable of supporting it, until such time that an SBI
implementation independent way to communicate what regions are in use
has been agreed on.
As hibernation support landed in v6.4-rc1, disabling it for most
platforms does not constitute a regression. The alternative would have
been reverting commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for
the linear mapping").
Doing so would permit hibernation on platforms with these SBI
implementations, but would limit the options we have to solve the
protection of the region without causing a regression in hibernation
support.
Reported-by: Song Shuai <suagrfillet@gmail.com>
Link: https://lore.kernel.org/all/CAAYs2=gQvkhTeioMmqRDVGjdtNF_vhB+vm_1dHJxPNi75YDQ_Q@mail.gmail.com/ [1]
Reported-by: JeeHeng Sia <jeeheng.sia@starfivetech.com>
Link: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ITXwaKfA6z8 [2]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230526-astride-detonator-9ae120051159@wendy
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-05-26 13:59:08 +03:00
def_bool NONPORTABLE
2023-03-30 09:43:21 +03:00
config ARCH_HIBERNATION_HEADER
def_bool HIBERNATION
2023-05-29 13:15:24 +03:00
config ARCH_SUSPEND_POSSIBLE
def_bool y
2022-05-20 15:02:30 +03:00
endmenu # "Power management options"
2020-09-18 01:37:14 +03:00
2022-02-10 08:49:40 +03:00
menu "CPU Power Management"
source "drivers/cpuidle/Kconfig"
2022-11-15 13:51:33 +03:00
source "drivers/cpufreq/Kconfig"
2022-05-20 15:02:30 +03:00
endmenu # "CPU Power Management"
2022-02-10 08:49:40 +03:00
2021-09-27 14:40:01 +03:00
source "arch/riscv/kvm/Kconfig"
2023-05-15 08:49:13 +03:00
source "drivers/acpi/Kconfig"