The header arch/x86/include/uapi/asm/e820.h isn't used by any source file any
more. The e820 related items are defined in arch/x86/include/asm/e820/types.h.
So clean it up.

Signed-off-by: Changbin Du <changbin.du@huawei.com>
---
 arch/x86/include/uapi/asm/e820.h | 82 --------------------------------
 1 file changed, 82 deletions(-)
 delete mode 100644 arch/x86/include/uapi/asm/e820.h

diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
deleted file mode 100644
index 55bc66867156..000000000000
--- a/arch/x86/include/uapi/asm/e820.h
+++ /dev/null
@@ -1,82 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_ASM_X86_E820_H
-#define _UAPI_ASM_X86_E820_H
-#define E820MAP	0x2d0		/* our map */
-#define E820MAX	128		/* number of entries in E820MAP */
-
-/*
- * Legacy E820 BIOS limits us to 128 (E820MAX) nodes due to the
- * constrained space in the zeropage.  If we have more nodes than
- * that, and if we've booted off EFI firmware, then the EFI tables
- * passed us from the EFI firmware can list more nodes.  Size our
- * internal memory map tables to have room for these additional
- * nodes, based on up to three entries per node for which the
- * kernel was built: MAX_NUMNODES == (1 << CONFIG_NODES_SHIFT),
- * plus E820MAX, allowing space for the possible duplicate E820
- * entries that might need room in the same arrays, prior to the
- * call to sanitize_e820_map() to remove duplicates.  The allowance
- * of three memory map entries per node is "enough" entries for
- * the initial hardware platform motivating this mechanism to make
- * use of additional EFI map entries.  Future platforms may want
- * to allow more than three entries per node or otherwise refine
- * this size.
- */
-
-#ifndef __KERNEL__
-#define E820_X_MAX E820MAX
-#endif
-
-#define E820NR	0x1e8		/* # entries in E820MAP */
-
-#define E820_RAM	1
-#define E820_RESERVED	2
-#define E820_ACPI	3
-#define E820_NVS	4
-#define E820_UNUSABLE	5
-#define E820_PMEM	7
-
-/*
- * This is a non-standardized way to represent ADR or NVDIMM regions that
- * persist over a reboot.  The kernel will ignore their special capabilities
- * unless the CONFIG_X86_PMEM_LEGACY option is set.
- *
- * ( Note that older platforms also used 6 for the same type of memory,
- *   but newer versions switched to 12 as 6 was assigned differently.  Some
- *   time they will learn... )
- */
-#define E820_PRAM	12
-
-/*
- * reserved RAM used by kernel itself
- * if CONFIG_INTEL_TXT is enabled, memory of this type will be
- * included in the S3 integrity calculation and so should not include
- * any memory that BIOS might alter over the S3 transition
- */
-#define E820_RESERVED_KERN        128
-
-#ifndef __ASSEMBLER__
-#include <linux/types.h>
-struct e820entry {
-	__u64 addr;	/* start of memory segment */
-	__u64 size;	/* size of memory segment */
-	__u32 type;	/* type of memory segment */
-} __attribute__((packed));
-
-struct e820map {
-	__u32 nr_map;
-	struct e820entry map[E820_X_MAX];
-};
-
-#define ISA_START_ADDRESS	0xa0000
-#define ISA_END_ADDRESS		0x100000
-
-#define BIOS_BEGIN		0x000a0000
-#define BIOS_END		0x00100000
-
-#define BIOS_ROM_BASE		0xffe00000
-#define BIOS_ROM_END		0xffffffff
-
-#endif /* __ASSEMBLER__ */
-
-
-#endif /* _UAPI_ASM_X86_E820_H */
-- 
2.43.0

* Changbin Du <changbin.du@huawei.com> wrote:

> The header arch/x86/include/uapi/asm/e820.h isn't used by any source file any
> more. The e820 related items are defined in arch/x86/include/asm/e820/types.h.
> So clean it up.
> 
> Signed-off-by: Changbin Du <changbin.du@huawei.com>
> ---
>  arch/x86/include/uapi/asm/e820.h | 82 --------------------------------
>  1 file changed, 82 deletions(-)
>  delete mode 100644 arch/x86/include/uapi/asm/e820.h

This is part of the specification of the bootloader protocol between 
bootloaders and the Linux kernel and thus should not be removed.

The kernel has its internal types that adhere to the same 
specification, but that's not grounds to remove this header.

Thanks,

	Ingo

Hi, Ingo,
On Tue, Apr 22, 2025 at 08:56:49AM +0200, Ingo Molnar wrote:
> 
> * Changbin Du <changbin.du@huawei.com> wrote:
> 
> > The header arch/x86/include/uapi/asm/e820.h isn't used by any source file any
> > more. The e820 related items are defined in arch/x86/include/asm/e820/types.h.
> > So clean it up.
> > 
> > Signed-off-by: Changbin Du <changbin.du@huawei.com>
> > ---
> >  arch/x86/include/uapi/asm/e820.h | 82 --------------------------------
> >  1 file changed, 82 deletions(-)
> >  delete mode 100644 arch/x86/include/uapi/asm/e820.h
> 
> This is part of the specification of the bootloader protocol between 
> bootloaders and the Linux kernel and thus should not be removed.
> 
> The kernel has its internal types that adhere to the same 
> specification, but that's not grounds to remove this header.
>
Regarding the e820 definitions used in the boot protocol, the main components
involved are 'struct boot_params::e820_table' and the SETUP_E820_EXT node. Both
of these utilize the 'struct boot_e820_entry' defined in arch/x86/include/uapi/asm/setup_data.h,
which is also part of the UAPI.

The header arch/x86/include/uapi/asm/e820.h is not referenced by boot protocol
definitions. In this scenario, can the header file arch/x86/include/uapi/asm/e820.h
be safely removed?

> Thanks,
> 
> 	Ingo
> 

-- 
Cheers,
Changbin Du

* duchangbin <changbin.du@huawei.com> wrote:

> Hi, Ingo,
> On Tue, Apr 22, 2025 at 08:56:49AM +0200, Ingo Molnar wrote:
> > 
> > * Changbin Du <changbin.du@huawei.com> wrote:
> > 
> > > The header arch/x86/include/uapi/asm/e820.h isn't used by any source file any
> > > more. The e820 related items are defined in arch/x86/include/asm/e820/types.h.
> > > So clean it up.
> > > 
> > > Signed-off-by: Changbin Du <changbin.du@huawei.com>
> > > ---
> > >  arch/x86/include/uapi/asm/e820.h | 82 --------------------------------
> > >  1 file changed, 82 deletions(-)
> > >  delete mode 100644 arch/x86/include/uapi/asm/e820.h
> > 
> > This is part of the specification of the bootloader protocol between 
> > bootloaders and the Linux kernel and thus should not be removed.
> > 
> > The kernel has its internal types that adhere to the same 
> > specification, but that's not grounds to remove this header.
> >
>
> Regarding the e820 definitions used in the boot protocol, the main 
> components involved are 'struct boot_params::e820_table' and the 
> SETUP_E820_EXT node. Both of these utilize the 'struct 
> boot_e820_entry' defined in arch/x86/include/uapi/asm/setup_data.h, 
> which is also part of the UAPI.

True.

> The header arch/x86/include/uapi/asm/e820.h is not referenced by boot 
> protocol definitions. In this scenario, can the header file 
> arch/x86/include/uapi/asm/e820.h be safely removed?

Probably/possibly ...

Thanks,

	Ingo