[RESEND PATCH] x86/setup: Fix typos

[RESEND PATCH] x86/setup: Fix typos

[Cao jin]

BIOSen -> BIOSes; paing -> paging.
And improve comments via 640"Kb".

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
---
git client finally works after configuration update.

 arch/x86/kernel/setup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 77ea96b794bd..56ac9ff12461 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -459,7 +459,7 @@ static void __init memblock_x86_reserve_range_setup_data(void)
  * due to mapping restrictions.
  *
  * On 64bit, kdump kernel need be restricted to be under 64TB, which is
- * the upper limit of system RAM in 4-level paing mode. Since the kdump
+ * the upper limit of system RAM in 4-level paging mode. Since the kdump
  * jumping could be from 5-level to 4-level, the jumping will fail if
  * kernel is put above 64TB, and there's no way to detect the paging mode
  * of the kernel which will be loaded for dumping during the 1st kernel
@@ -743,8 +743,8 @@ static void __init trim_bios_range(void)
 	e820__range_update(0, PAGE_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
 
 	/*
-	 * special case: Some BIOSen report the PC BIOS
-	 * area (640->1Mb) as ram even though it is not.
+	 * special case: Some BIOSes report the PC BIOS
+	 * area (640Kb->1Mb) as ram even though it is not.
 	 * take them out.
 	 */
 	e820__range_remove(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_TYPE_RAM, 1);
-- 
2.21.0

[tip: x86/cleanups] x86: Fix typos in comments

[tip-bot2 for Cao jin]

The following commit has been merged into the x86/cleanups branch of tip:

Commit-ID:     11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
Gitweb:        https://git.kernel.org/tip/11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
Author:        Cao jin <caoj.fnst@cn.fujitsu.com>
AuthorDate:    Mon, 18 Nov 2019 15:00:12 +08:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Mon, 18 Nov 2019 10:03:26 +01:00

x86: Fix typos in comments

BIOSen -> BIOSes; paing -> paging. Append to 640 its proper unit "Kb".
encomapssing -> encompassing.

 [ bp: Merge into a single patch, fix one more typo, massage. ]

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Robert Richter <rrichter@marvell.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191118070012.27850-1-caoj.fnst@cn.fujitsu.com
---
 arch/x86/kernel/setup.c | 6 +++---
 arch/x86/mm/numa.c      | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 77ea96b..35b3f3a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -459,7 +459,7 @@ static void __init memblock_x86_reserve_range_setup_data(void)
  * due to mapping restrictions.
  *
  * On 64bit, kdump kernel need be restricted to be under 64TB, which is
- * the upper limit of system RAM in 4-level paing mode. Since the kdump
+ * the upper limit of system RAM in 4-level paging mode. Since the kdump
  * jumping could be from 5-level to 4-level, the jumping will fail if
  * kernel is put above 64TB, and there's no way to detect the paging mode
  * of the kernel which will be loaded for dumping during the 1st kernel
@@ -743,8 +743,8 @@ static void __init trim_bios_range(void)
 	e820__range_update(0, PAGE_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
 
 	/*
-	 * special case: Some BIOSen report the PC BIOS
-	 * area (640->1Mb) as ram even though it is not.
+	 * special case: Some BIOSes report the PC BIOS
+	 * area (640Kb -> 1Mb) as RAM even though it is not.
 	 * take them out.
 	 */
 	e820__range_remove(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_TYPE_RAM, 1);
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 4123100..99f7a68 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -699,7 +699,7 @@ static int __init dummy_numa_init(void)
  * x86_numa_init - Initialize NUMA
  *
  * Try each configured NUMA initialization method until one succeeds.  The
- * last fallback is dummy single node config encomapssing whole memory and
+ * last fallback is dummy single node config encompassing whole memory and
  * never fails.
  */
 void __init x86_numa_init(void)

Re: [tip: x86/cleanups] x86: Fix typos in comments

[Ingo Molnar]

* tip-bot2 for Cao jin <tip-bot2@linutronix.de> wrote:

> The following commit has been merged into the x86/cleanups branch of tip:
> 
> Commit-ID:     11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
> Gitweb:        https://git.kernel.org/tip/11a98f37a5c11fd3cec9c7a566dfa902bceb5bde
> Author:        Cao jin <caoj.fnst@cn.fujitsu.com>
> AuthorDate:    Mon, 18 Nov 2019 15:00:12 +08:00
> Committer:     Borislav Petkov <bp@suse.de>
> CommitterDate: Mon, 18 Nov 2019 10:03:26 +01:00
> 
> x86: Fix typos in comments
> 
> BIOSen -> BIOSes; paing -> paging. Append to 640 its proper unit "Kb".
> encomapssing -> encompassing.
> 
>  [ bp: Merge into a single patch, fix one more typo, massage. ]
> 
> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Robert Richter <rrichter@marvell.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
> Cc: x86-ml <x86@kernel.org>
> Link: https://lkml.kernel.org/r/20191118070012.27850-1-caoj.fnst@cn.fujitsu.com
> ---
>  arch/x86/kernel/setup.c | 6 +++---
>  arch/x86/mm/numa.c      | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 77ea96b..35b3f3a 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -459,7 +459,7 @@ static void __init memblock_x86_reserve_range_setup_data(void)
>   * due to mapping restrictions.
>   *
>   * On 64bit, kdump kernel need be restricted to be under 64TB, which is
> - * the upper limit of system RAM in 4-level paing mode. Since the kdump
> + * the upper limit of system RAM in 4-level paging mode. Since the kdump
>   * jumping could be from 5-level to 4-level, the jumping will fail if
>   * kernel is put above 64TB, and there's no way to detect the paging mode
>   * of the kernel which will be loaded for dumping during the 1st kernel

Beyond the typo, this whole paragraph is hard to read and inconsistent 
throughout.

How about something like this, on top? [ Feel free to backmerge, but can 
do a separate commit too - in which case I'll probably read the rest of 
the file too ;-) ]

Thanks,

	Ingo

 arch/x86/kernel/setup.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d398afd206b8..e9fa944d4ed8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -468,15 +468,15 @@ static void __init memblock_x86_reserve_range_setup_data(void)
 /*
  * Keep the crash kernel below this limit.
  *
- * On 32 bits earlier kernels would limit the kernel to the low 512 MiB
+ * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
  * due to mapping restrictions.
  *
- * On 64bit, kdump kernel need be restricted to be under 64TB, which is
+ * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
  * the upper limit of system RAM in 4-level paging mode. Since the kdump
- * jumping could be from 5-level to 4-level, the jumping will fail if
- * kernel is put above 64TB, and there's no way to detect the paging mode
- * of the kernel which will be loaded for dumping during the 1st kernel
- * bootup.
+ * jump could be from 5-level paging to 4-level paging, the jump will fail if
+ * the kernel is put above 64 TB, and during the 1st kernel bootup there's
+ * no good way to detect the paging mode of the target kernel which will be
+ * loaded for dumping.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_ADDR_LOW_MAX	SZ_512M

Re: [tip: x86/cleanups] x86: Fix typos in comments

[Borislav Petkov]

On Mon, Nov 18, 2019 at 01:10:27PM +0100, Ingo Molnar wrote:
> Beyond the typo, this whole paragraph is hard to read and inconsistent 
> throughout.
> 
> How about something like this, on top? [ Feel free to backmerge, but can 
> do a separate commit too - in which case I'll probably read the rest of 
> the file too ;-) ]
> 
> Thanks,
> 
> 	Ingo
> 
>  arch/x86/kernel/setup.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d398afd206b8..e9fa944d4ed8 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -468,15 +468,15 @@ static void __init memblock_x86_reserve_range_setup_data(void)
>  /*
>   * Keep the crash kernel below this limit.
>   *
> - * On 32 bits earlier kernels would limit the kernel to the low 512 MiB
> + * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
>   * due to mapping restrictions.
>   *
> - * On 64bit, kdump kernel need be restricted to be under 64TB, which is
> + * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
>   * the upper limit of system RAM in 4-level paging mode. Since the kdump
> - * jumping could be from 5-level to 4-level, the jumping will fail if
> - * kernel is put above 64TB, and there's no way to detect the paging mode
> - * of the kernel which will be loaded for dumping during the 1st kernel
> - * bootup.
> + * jump could be from 5-level paging to 4-level paging, the jump will fail if
> + * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> + * no good way to detect the paging mode of the target kernel which will be
> + * loaded for dumping.
>   */
>  #ifdef CONFIG_X86_32
>  # define CRASH_ADDR_LOW_MAX	SZ_512M

Yap, sure.

Except that tglx committed another patch ontop of x86/cleanups in the
meantime. I leave it up to you to decide what to do. I'd backmerge and
rebase but this is just me.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH] Re: [tip: x86/cleanups] x86: Fix typos in comments

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> >  /*
> >   * Keep the crash kernel below this limit.
> >   *
> > - * On 32 bits earlier kernels would limit the kernel to the low 512 MiB
> > + * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
> >   * due to mapping restrictions.
> >   *
> > - * On 64bit, kdump kernel need be restricted to be under 64TB, which is
> > + * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
> >   * the upper limit of system RAM in 4-level paging mode. Since the kdump
> > - * jumping could be from 5-level to 4-level, the jumping will fail if
> > - * kernel is put above 64TB, and there's no way to detect the paging mode
> > - * of the kernel which will be loaded for dumping during the 1st kernel
> > - * bootup.
> > + * jump could be from 5-level paging to 4-level paging, the jump will fail if
> > + * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> > + * no good way to detect the paging mode of the target kernel which will be
> > + * loaded for dumping.
> >   */
> >  #ifdef CONFIG_X86_32
> >  # define CRASH_ADDR_LOW_MAX	SZ_512M
> 
> Yap, sure.
> 
> Except that tglx committed another patch ontop of x86/cleanups in the 
> meantime. I leave it up to you to decide what to do. I'd backmerge and 
> rebase but this is just me.

Well, I did the two patches on top: once shrinks the number of #include 
lines from 90 to 30, the other improves most of the comments, with a 
bunch of other typo/grammar fixes, but more importantly I tried to 
clarify/extend/fix the comments where they were misleading or 
meaningless:

  9dcc69c4ea5c: x86/setup: Enhance the comments
  c1877650f3c9: x86/setup: Clean up the header portion of setup.c

Attached below as well.

Thanks,

	Ingo


===============>
commit 9dcc69c4ea5c0cd4031a4dde645c71b66bea04f8
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Nov 18 16:03:39 2019 +0100

    x86/setup: Enhance the comments
    
    Update various comments, fix outright mistakes and meaningless descriptions.
    
    Also harmonize the style across the file, both in form and in language.
    
    Cc: linux-kernel@vger.kernel.org
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 5f483eb14d44..c7774af9f8a1 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -41,11 +41,11 @@
 #include <asm/vsyscall.h>
 
 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped:     highest direct mapped pfn over 4GB
+ * max_low_pfn_mapped: highest directly mapped pfn < 4 GB
+ * max_pfn_mapped:     highest directly mapped pfn > 4 GB
  *
  * The direct mapping only covers E820_TYPE_RAM regions, so the ranges and gaps are
- * represented by pfn_mapped
+ * represented by pfn_mapped[].
  */
 unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;
@@ -55,14 +55,23 @@ RESERVE_BRK(dmi_alloc, 65536);
 #endif
 
 
-static __initdata unsigned long _brk_start = (unsigned long)__brk_base;
-unsigned long _brk_end = (unsigned long)__brk_base;
+/*
+ * Range of the BSS area. The size of the BSS area is determined
+ * at link time, with RESERVE_BRK*() facility reserving additional
+ * chunks.
+ */
+static __initdata
+unsigned long _brk_start = (unsigned long)__brk_base;
+unsigned long _brk_end   = (unsigned long)__brk_base;
 
 struct boot_params boot_params;
 
 /*
- * Machine setup..
+ * These are the four main kernel memory regions, we put them into
+ * the resource tree so that kdump tools and other debugging tools
+ * recover it:
  */
+
 static struct resource rodata_resource = {
 	.name	= "Kernel rodata",
 	.start	= 0,
@@ -93,16 +102,16 @@ static struct resource bss_resource = {
 
 
 #ifdef CONFIG_X86_32
-/* cpu data as detected by the assembly code in head_32.S */
+/* CPU data as detected by the assembly code in head_32.S */
 struct cpuinfo_x86 new_cpu_data;
 
-/* common cpu data for all cpus */
+/* Common CPU data for all CPUs */
 struct cpuinfo_x86 boot_cpu_data __read_mostly;
 EXPORT_SYMBOL(boot_cpu_data);
 
 unsigned int def_to_bigsmp;
 
-/* for MCA, but anyone else can use it if they want */
+/* For MCA, but anyone else can use it if they want */
 unsigned int machine_id;
 unsigned int machine_submodel_id;
 unsigned int BIOS_revision;
@@ -382,15 +391,15 @@ static void __init memblock_x86_reserve_range_setup_data(void)
 /*
  * Keep the crash kernel below this limit.
  *
- * On 32 bits earlier kernels would limit the kernel to the low 512 MiB
+ * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
  * due to mapping restrictions.
  *
- * On 64bit, kdump kernel need be restricted to be under 64TB, which is
+ * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
  * the upper limit of system RAM in 4-level paging mode. Since the kdump
- * jumping could be from 5-level to 4-level, the jumping will fail if
- * kernel is put above 64TB, and there's no way to detect the paging mode
- * of the kernel which will be loaded for dumping during the 1st kernel
- * bootup.
+ * jump could be from 5-level paging to 4-level paging, the jump will fail if
+ * the kernel is put above 64 TB, and during the 1st kernel bootup there's
+ * no good way to detect the paging mode of the target kernel which will be
+ * loaded for dumping.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_ADDR_LOW_MAX	SZ_512M
@@ -801,7 +810,7 @@ void __init setup_arch(char **cmdline_p)
 	/*
 	 * Note: Quark X1000 CPUs advertise PGE incorrectly and require
 	 * a cr3 based tlb flush, so the following __flush_tlb_all()
-	 * will not flush anything because the cpu quirk which clears
+	 * will not flush anything because the CPU quirk which clears
 	 * X86_FEATURE_PGE has not been invoked yet. Though due to the
 	 * load_cr3() above the TLB has been flushed already. The
 	 * quirk is invoked before subsequent calls to __flush_tlb_all()

commit c1877650f3c9fb8568f8dce3fc804ab45125cf78
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Nov 18 15:49:22 2019 +0100

    x86/setup: Clean up the header portion of setup.c
    
    In 20 years we accumulated 89 #include lines in setup.c,
    but we only need 30 of them (!) ...
    
    Get rid of the excessive ones, and while at it, sort the
    remaining ones alphabetically.
    
    Also get rid of the incomplete changelogs at the header of the file,
    and explain better what this file does.
    
    Cc: linux-kernel@vger.kernel.org
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ea6496f2debb..5f483eb14d44 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -2,123 +2,43 @@
 /*
  *  Copyright (C) 1995  Linus Torvalds
  *
- *  Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
- *
- *  Memory region support
- *	David Parsons <orc@pell.chi.il.us>, July-August 1999
- *
- *  Added E820 sanitization routine (removes overlapping memory regions);
- *  Brian Moyle <bmoyle@mvista.com>, February 2001
- *
- * Moved CPU detection code to cpu/${cpu}.c
- *    Patrick Mochel <mochel@osdl.org>, March 2002
- *
- *  Provisions for empty E820 memory regions (reported by certain BIOSes).
- *  Alex Achenbach <xela@slit.de>, December 2002.
- *
+ * This file contains the setup_arch() code, which handles the architecture-dependent
+ * parts of early kernel initialization.
  */
-
-/*
- * This file handles the architecture-dependent parts of initialization
- */
-
-#include <linux/sched.h>
-#include <linux/mm.h>
-#include <linux/mmzone.h>
-#include <linux/screen_info.h>
-#include <linux/ioport.h>
-#include <linux/acpi.h>
-#include <linux/sfi.h>
-#include <linux/apm_bios.h>
-#include <linux/initrd.h>
-#include <linux/memblock.h>
-#include <linux/seq_file.h>
 #include <linux/console.h>
-#include <linux/root_dev.h>
-#include <linux/highmem.h>
-#include <linux/export.h>
+#include <linux/crash_dump.h>
+#include <linux/dmi.h>
 #include <linux/efi.h>
-#include <linux/init.h>
-#include <linux/edd.h>
+#include <linux/init_ohci1394_dma.h>
+#include <linux/initrd.h>
 #include <linux/iscsi_ibft.h>
-#include <linux/nodemask.h>
-#include <linux/kexec.h>
-#include <linux/dmi.h>
-#include <linux/pfn.h>
+#include <linux/memblock.h>
 #include <linux/pci.h>
-#include <asm/pci-direct.h>
-#include <linux/init_ohci1394_dma.h>
-#include <linux/kvm_para.h>
-#include <linux/dma-contiguous.h>
-#include <xen/xen.h>
-#include <uapi/linux/mount.h>
-
-#include <linux/errno.h>
-#include <linux/kernel.h>
-#include <linux/stddef.h>
-#include <linux/unistd.h>
-#include <linux/ptrace.h>
-#include <linux/user.h>
-#include <linux/delay.h>
-
-#include <linux/kallsyms.h>
-#include <linux/cpufreq.h>
-#include <linux/dma-mapping.h>
-#include <linux/ctype.h>
-#include <linux/uaccess.h>
-
-#include <linux/percpu.h>
-#include <linux/crash_dump.h>
+#include <linux/root_dev.h>
+#include <linux/sfi.h>
 #include <linux/tboot.h>
-#include <linux/jiffies.h>
-#include <linux/mem_encrypt.h>
-#include <linux/sizes.h>
-
 #include <linux/usb/xhci-dbgp.h>
-#include <video/edid.h>
 
-#include <asm/mtrr.h>
-#include <asm/apic.h>
-#include <asm/realmode.h>
-#include <asm/e820/api.h>
-#include <asm/mpspec.h>
-#include <asm/setup.h>
-#include <asm/efi.h>
-#include <asm/timer.h>
-#include <asm/i8259.h>
-#include <asm/sections.h>
-#include <asm/io_apic.h>
-#include <asm/ist.h>
-#include <asm/setup_arch.h>
+#include <uapi/linux/mount.h>
+
+#include <xen/xen.h>
+
 #include <asm/bios_ebda.h>
-#include <asm/cacheflush.h>
-#include <asm/processor.h>
 #include <asm/bugs.h>
-#include <asm/kasan.h>
-
-#include <asm/vsyscall.h>
 #include <asm/cpu.h>
-#include <asm/desc.h>
-#include <asm/dma.h>
-#include <asm/iommu.h>
+#include <asm/efi.h>
 #include <asm/gart.h>
-#include <asm/mmu_context.h>
-#include <asm/proto.h>
-
-#include <asm/paravirt.h>
 #include <asm/hypervisor.h>
-#include <asm/olpc_ofw.h>
-
-#include <asm/percpu.h>
-#include <asm/topology.h>
-#include <asm/apicdef.h>
-#include <asm/amd_nb.h>
+#include <asm/kasan.h>
+#include <asm/kaslr.h>
 #include <asm/mce.h>
-#include <asm/alternative.h>
+#include <asm/mtrr.h>
+#include <asm/olpc_ofw.h>
+#include <asm/pci-direct.h>
 #include <asm/prom.h>
-#include <asm/microcode.h>
-#include <asm/kaslr.h>
+#include <asm/proto.h>
 #include <asm/unwind.h>
+#include <asm/vsyscall.h>
 
 /*
  * max_low_pfn_mapped: highest direct mapped pfn under 4GB