[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1362129175.2262.86.camel@liguang.fnst.cn.fujitsu.com>
Date: Fri, 01 Mar 2013 17:12:55 +0800
From: li guang <lig.fnst@...fujitsu.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86: add e820 descriptor attribute field
can we fix if it breaks anything?
I think there are sound reasons that
ACPI add these extended attributes.
在 2013-02-28四的 21:28 -0800,H. Peter Anvin写道:
> NAK in the extreme. Not only does this break the bootloader protocol, but there are systems in the field that break if you give e820 anything other than a 20-byte buffer.
>
> liguang <lig.fnst@...fujitsu.com> wrote:
>
> >according to ACPI 5.0 Table 15-273
> >Address Range Descriptor Structure,
> >offset 20 is 32-bit field of Extended
> >Attributes for Address Range Descriptor Structure.
> >
> >Signed-off-by: liguang <lig.fnst@...fujitsu.com>
> >---
> > arch/x86/include/uapi/asm/e820.h | 7 ++++++-
> > 1 files changed, 6 insertions(+), 1 deletions(-)
> >
> >diff --git a/arch/x86/include/uapi/asm/e820.h
> >b/arch/x86/include/uapi/asm/e820.h
> >index 2d400b1..eb87284 100644
> >--- a/arch/x86/include/uapi/asm/e820.h
> >+++ b/arch/x86/include/uapi/asm/e820.h
> >@@ -38,6 +38,10 @@
> > #define E820_TYPE_NVS 4
> > #define E820_TYPE_UNUSABLE 5
> >
> >+#define E820_ATTRIB_NV 0x2
> >+#define E820_ATTRIB_SLOW_ACCESS 0x4
> >+#define E820_ATTRIB_ERR_LOG 0x8
> >+
> >
> > /*
> > * reserved RAM used by kernel itself
> >@@ -53,7 +57,8 @@ struct e820entry {
> > __u64 addr; /* start of memory segment */
> > __u64 size; /* size of memory segment */
> > __u32 type; /* type of memory segment */
> >-} __attribute__((packed));
> >+ __u32 attrib;
> >+};
> >
> > struct e820map {
> > __u32 nr_map;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists