arch/Kconfig: fix indentation
authorJuerg Haefliger <juerg.haefliger@canonical.com>
Wed, 1 Feb 2023 16:24:35 +0000 (17:24 +0100)
committerAndrew Morton <akpm@linux-foundation.org>
Fri, 10 Feb 2023 01:03:20 +0000 (17:03 -0800)
The convention for indentation seems to be a single tab.  Help text is
further indented by an additional two whitespaces.  Fix the lines that
violate these rules.

Link: https://lkml.kernel.org/r/20230201162435.218368-1-juerg.haefliger@canonical.com
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Dan Li <ashimida@linux.alibaba.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Juerg Haefliger <juerg.haefliger@canonical.com>
Cc: Marco Elver <elver@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Tom Rix <trix@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
arch/Kconfig

index 12e3ddabac9d3be02f6c9f6c5433bd1ac4b65dbe..e3511afbb7f2f493854242c16c2429a83800984a 100644 (file)
@@ -35,7 +35,7 @@ config HOTPLUG_SMT
        bool
 
 config GENERIC_ENTRY
-       bool
+       bool
 
 config KPROBES
        bool "Kprobes"
@@ -55,26 +55,26 @@ config JUMP_LABEL
        depends on HAVE_ARCH_JUMP_LABEL
        select OBJTOOL if HAVE_JUMP_LABEL_HACK
        help
-        This option enables a transparent branch optimization that
-        makes certain almost-always-true or almost-always-false branch
-        conditions even cheaper to execute within the kernel.
+         This option enables a transparent branch optimization that
+         makes certain almost-always-true or almost-always-false branch
+         conditions even cheaper to execute within the kernel.
 
-        Certain performance-sensitive kernel code, such as trace points,
-        scheduler functionality, networking code and KVM have such
-        branches and include support for this optimization technique.
+         Certain performance-sensitive kernel code, such as trace points,
+         scheduler functionality, networking code and KVM have such
+         branches and include support for this optimization technique.
 
-        If it is detected that the compiler has support for "asm goto",
-        the kernel will compile such branches with just a nop
-        instruction. When the condition flag is toggled to true, the
-        nop will be converted to a jump instruction to execute the
-        conditional block of instructions.
+         If it is detected that the compiler has support for "asm goto",
+         the kernel will compile such branches with just a nop
+         instruction. When the condition flag is toggled to true, the
+         nop will be converted to a jump instruction to execute the
+         conditional block of instructions.
 
-        This technique lowers overhead and stress on the branch prediction
-        of the processor and generally makes the kernel faster. The update
-        of the condition is slower, but those are always very rare.
+         This technique lowers overhead and stress on the branch prediction
+         of the processor and generally makes the kernel faster. The update
+         of the condition is slower, but those are always very rare.
 
-        ( On 32-bit x86, the necessary options added to the compiler
-          flags may increase the size of the kernel slightly. )
+         ( On 32-bit x86, the necessary options added to the compiler
+           flags may increase the size of the kernel slightly. )
 
 config STATIC_KEYS_SELFTEST
        bool "Static key selftest"
@@ -98,9 +98,9 @@ config KPROBES_ON_FTRACE
        depends on KPROBES && HAVE_KPROBES_ON_FTRACE
        depends on DYNAMIC_FTRACE_WITH_REGS
        help
-        If function tracer is enabled and the arch supports full
-        passing of pt_regs to function tracing, then kprobes can
-        optimize on top of function tracing.
+         If function tracer is enabled and the arch supports full
+         passing of pt_regs to function tracing, then kprobes can
+         optimize on top of function tracing.
 
 config UPROBES
        def_bool n
@@ -154,21 +154,21 @@ config HAVE_EFFICIENT_UNALIGNED_ACCESS
 config ARCH_USE_BUILTIN_BSWAP
        bool
        help
-        Modern versions of GCC (since 4.4) have builtin functions
-        for handling byte-swapping. Using these, instead of the old
-        inline assembler that the architecture code provides in the
-        __arch_bswapXX() macros, allows the compiler to see what's
-        happening and offers more opportunity for optimisation. In
-        particular, the compiler will be able to combine the byteswap
-        with a nearby load or store and use load-and-swap or
-        store-and-swap instructions if the architecture has them. It
-        should almost *never* result in code which is worse than the
-        hand-coded assembler in <asm/swab.h>.  But just in case it
-        does, the use of the builtins is optional.
+         Modern versions of GCC (since 4.4) have builtin functions
+         for handling byte-swapping. Using these, instead of the old
+         inline assembler that the architecture code provides in the
+         __arch_bswapXX() macros, allows the compiler to see what's
+         happening and offers more opportunity for optimisation. In
+         particular, the compiler will be able to combine the byteswap
+         with a nearby load or store and use load-and-swap or
+         store-and-swap instructions if the architecture has them. It
+         should almost *never* result in code which is worse than the
+         hand-coded assembler in <asm/swab.h>.  But just in case it
+         does, the use of the builtins is optional.
 
-        Any architecture with load-and-swap or store-and-swap
-        instructions should set this. And it shouldn't hurt to set it
-        on architectures that don't have such instructions.
+         Any architecture with load-and-swap or store-and-swap
+         instructions should set this. And it shouldn't hurt to set it
+         on architectures that don't have such instructions.
 
 config KRETPROBES
        def_bool y
@@ -720,13 +720,13 @@ config LTO_CLANG_FULL
        depends on !COMPILE_TEST
        select LTO_CLANG
        help
-          This option enables Clang's full Link Time Optimization (LTO), which
-          allows the compiler to optimize the kernel globally. If you enable
-          this option, the compiler generates LLVM bitcode instead of ELF
-          object files, and the actual compilation from bitcode happens at
-          the LTO link step, which may take several minutes depending on the
-          kernel configuration. More information can be found from LLVM's
-          documentation:
+         This option enables Clang's full Link Time Optimization (LTO), which
+         allows the compiler to optimize the kernel globally. If you enable
+         this option, the compiler generates LLVM bitcode instead of ELF
+         object files, and the actual compilation from bitcode happens at
+         the LTO link step, which may take several minutes depending on the
+         kernel configuration. More information can be found from LLVM's
+         documentation:
 
            https://llvm.org/docs/LinkTimeOptimization.html
 
@@ -1330,9 +1330,9 @@ config ARCH_HAS_CC_PLATFORM
        bool
 
 config HAVE_SPARSE_SYSCALL_NR
-       bool
-       help
-          An architecture should select this if its syscall numbering is sparse
+       bool
+       help
+         An architecture should select this if its syscall numbering is sparse
          to save space. For example, MIPS architecture has a syscall array with
          entries at 4000, 5000 and 6000 locations. This option turns on syscall
          related optimizations for a given architecture.
@@ -1356,35 +1356,35 @@ config HAVE_PREEMPT_DYNAMIC_CALL
        depends on HAVE_STATIC_CALL
        select HAVE_PREEMPT_DYNAMIC
        help
-          An architecture should select this if it can handle the preemption
-          model being selected at boot time using static calls.
+         An architecture should select this if it can handle the preemption
+         model being selected at boot time using static calls.
 
-          Where an architecture selects HAVE_STATIC_CALL_INLINE, any call to a
-          preemption function will be patched directly.
+         Where an architecture selects HAVE_STATIC_CALL_INLINE, any call to a
+         preemption function will be patched directly.
 
-          Where an architecture does not select HAVE_STATIC_CALL_INLINE, any
-          call to a preemption function will go through a trampoline, and the
-          trampoline will be patched.
+         Where an architecture does not select HAVE_STATIC_CALL_INLINE, any
+         call to a preemption function will go through a trampoline, and the
+         trampoline will be patched.
 
-          It is strongly advised to support inline static call to avoid any
-          overhead.
+         It is strongly advised to support inline static call to avoid any
+         overhead.
 
 config HAVE_PREEMPT_DYNAMIC_KEY
        bool
        depends on HAVE_ARCH_JUMP_LABEL
        select HAVE_PREEMPT_DYNAMIC
        help
-          An architecture should select this if it can handle the preemption
-          model being selected at boot time using static keys.
+         An architecture should select this if it can handle the preemption
+         model being selected at boot time using static keys.
 
-          Each preemption function will be given an early return based on a
-          static key. This 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.
+         Each preemption function will be given an early return based on a
+         static key. This 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.
 
-          This will have greater overhead than using inline static calls as
-          the call to the preemption function cannot be entirely elided.
+         This will have greater overhead than using inline static calls as
+         the call to the preemption function cannot be entirely elided.
 
 config ARCH_WANT_LD_ORPHAN_WARN
        bool
@@ -1407,8 +1407,8 @@ config ARCH_SUPPORTS_PAGE_TABLE_CHECK
 config ARCH_SPLIT_ARG64
        bool
        help
-          If a 32-bit architecture requires 64-bit arguments to be split into
-          pairs of 32-bit arguments, select this option.
+         If a 32-bit architecture requires 64-bit arguments to be split into
+         pairs of 32-bit arguments, select this option.
 
 config ARCH_HAS_ELFCORE_COMPAT
        bool