From: "Moore, Robert" <robert.moore@intel.com>
To: "Moore, Robert" <robert.moore@intel.com>,
Toshi Kani <toshi.kani@hpe.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"Williams, Dan J" <dan.j.williams@intel.com>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"devel@acpica.org" <devel@acpica.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: RE: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1
Date: Tue, 1 Mar 2016 17:41:46 +0000 [thread overview]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D782@ORSMSX110.amr.corp.intel.com>
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
ACPICA does not ever do anything with the "data tables" like NFIT, other than handing off the table when requested by a driver.
> -----Original Message-----
> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 01, 2016 9:37 AM
> To: Toshi Kani; rjw@rjwysocki.net; Williams, Dan J
> Cc: linux-nvdimm@lists.01.org; linux-kernel@vger.kernel.org; linux-
> acpi@vger.kernel.org; elliott@hpe.com; devel@acpica.org
> Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> Structure to comply ACPI 6.1
>
>
>
> > -----Original Message-----
> > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > Sent: Tuesday, March 01, 2016 9:37 AM
> > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure
> > to comply ACPI 6.1
> >
> > On Tue, 2016-03-01 at 16:03 +0000, Moore, Robert wrote:
> > > We have a bunch of macros in include/acmacros.h -- like this:
> > >
> > > ACPI_MOVE_16_TO_16(d, s)
> >
> > There is a problem in using the ACPICA byte-swap macros. ACPI is
> > little- endian arch, so the macros are set to perform byte-swappings
> > when the CPU arch is big-endian. This case, however, is the other way
> > around. The fields in question are defined & stored as arrays of bytes.
>
> That's not what I see in the ACPI spec. The fields are defined like any
> other ACPI table.
>
> Vendor ID 2 6
> Identifier indicating the vendor of the NVDIMM.
> This field shall be set to the value of the NVDIMM SPD Module Manufacturer
> ID Code field a with byte 0 set to DDR4 SPD byte
> 320 and byte 1 set to DDR4 SPD byte 321.
>
> Device ID 2 8
> Identifier for the NVDIMM, assigned by the module vendor.
> This field shall be set to the value of the NVDIMM SPD Module Product
> Identifier field b with byte 0 set to SPD byte 192 and byte 1 set to SPD
> byte 193.
>
> Revision ID 2 10
> Revision of the NVDIMM, assigned by the module vendor.
> Byte 1 of this field is reserved.
> Byte 0 of this field shall be set to the value of the NVDIMM SPD Module
> Revision Code field a (i.e., SPD byte 349).
>
>
> Etc.
>
>
> If you treat
> > them as multi-bytes numeric values, then you need to byte-swap them when
> > the CPU arch is little-endian because arrays of bytes have the same
> > addressing as big-endian.
> >
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
> > these fields are always treated as multi-bytes numeric values despite of
> > the spec. If drivers, we need to make sure that only a single driver
> > performs this byte-swapping one time as ACPI tables are global
> structures.
> >
> > I think it is much clearer to define the structure according to the ACPI
> > spec.
> >
> > Thanks,
> > -Toshi
> >
> > > > -----Original Message-----
> > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > Sent: Tuesday, March 01, 2016 8:38 AM
> > > > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > > > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > Structure to comply ACPI 6.1
> > > >
> > > > On Tue, 2016-03-01 at 15:13 +0000, Moore, Robert wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > > > Sent: Monday, February 22, 2016 1:55 PM
> > > > > > To: rjw@rjwysocki.net; Williams, Dan J
> > > > > > Cc: Moore, Robert; Zheng, Lv; elliott@hpe.com;
> > > > > > linux-nvdimm@lists.01.or g; linux-acpi@vger.kernel.org;
> > > > > > linux-kernel@vger.kernel.org; devel@acpica.org; Toshi Kani
> > > > > > Subject: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > > > Structure to comply ACPI 6.1
> > > > > >
> > > > > > ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure
> > > > > > as follows.
> > > > > > - Valid Fields, Manufacturing Location, and Manufacturing Date
> > > > > > are added from reserved range. No change in the structure
> > size.
> > > > > > - IDs defined as SPD values are arrays of bytes. The spec
> > > > > > clarified that they need to be represented as arrays of bytes
> > > > > > as well.
> > > > > >
> > > > > > This patch makes the following changes to support this update.
> > > > > > - Change 'struct acpi_nfit_control_region' to reflect the
> update.
> > > > > > SPD IDs are defined as arrays of bytes, so that they can be
> > > > > > treated in the same way regardless of CPU endianness and are
> > > > > > not miss-treated as little-endian numeric values.
> > > > >
> > > > >
> > > > > I don't think we are going to start changing the ACPI tables
> > > > > defined in the ACPICA headers because of this. We do in fact have
> > > > > macros for this purpose.
> > > >
> > > > Can you elaborate what macros you suggest to use for this purpose?
> > > >
> > > > Thanks,
> > > > -Toshi
> > > N r y b X ǧv ^ ){.n + { i b {ay \x1dʇڙ ,j f h z \x1e w
> > >
> >
> > j:+v w j m zZ+ ݢj" ! i
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Moore, Robert" <robert.moore@intel.com>
To: "Moore, Robert" <robert.moore@intel.com>,
Toshi Kani <toshi.kani@hpe.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"Williams, Dan J" <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"elliott@hpe.com" <elliott@hpe.com>,
"devel@acpica.org" <devel@acpica.org>
Subject: RE: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1
Date: Tue, 1 Mar 2016 17:41:46 +0000 [thread overview]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D782@ORSMSX110.amr.corp.intel.com>
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
ACPICA does not ever do anything with the "data tables" like NFIT, other than handing off the table when requested by a driver.
> -----Original Message-----
> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 01, 2016 9:37 AM
> To: Toshi Kani; rjw@rjwysocki.net; Williams, Dan J
> Cc: linux-nvdimm@lists.01.org; linux-kernel@vger.kernel.org; linux-
> acpi@vger.kernel.org; elliott@hpe.com; devel@acpica.org
> Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> Structure to comply ACPI 6.1
>
>
>
> > -----Original Message-----
> > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > Sent: Tuesday, March 01, 2016 9:37 AM
> > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure
> > to comply ACPI 6.1
> >
> > On Tue, 2016-03-01 at 16:03 +0000, Moore, Robert wrote:
> > > We have a bunch of macros in include/acmacros.h -- like this:
> > >
> > > ACPI_MOVE_16_TO_16(d, s)
> >
> > There is a problem in using the ACPICA byte-swap macros. ACPI is
> > little- endian arch, so the macros are set to perform byte-swappings
> > when the CPU arch is big-endian. This case, however, is the other way
> > around. The fields in question are defined & stored as arrays of bytes.
>
> That's not what I see in the ACPI spec. The fields are defined like any
> other ACPI table.
>
> Vendor ID 2 6
> Identifier indicating the vendor of the NVDIMM.
> This field shall be set to the value of the NVDIMM SPD Module Manufacturer
> ID Code field a with byte 0 set to DDR4 SPD byte
> 320 and byte 1 set to DDR4 SPD byte 321.
>
> Device ID 2 8
> Identifier for the NVDIMM, assigned by the module vendor.
> This field shall be set to the value of the NVDIMM SPD Module Product
> Identifier field b with byte 0 set to SPD byte 192 and byte 1 set to SPD
> byte 193.
>
> Revision ID 2 10
> Revision of the NVDIMM, assigned by the module vendor.
> Byte 1 of this field is reserved.
> Byte 0 of this field shall be set to the value of the NVDIMM SPD Module
> Revision Code field a (i.e., SPD byte 349).
>
>
> Etc.
>
>
> If you treat
> > them as multi-bytes numeric values, then you need to byte-swap them when
> > the CPU arch is little-endian because arrays of bytes have the same
> > addressing as big-endian.
> >
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
> > these fields are always treated as multi-bytes numeric values despite of
> > the spec. If drivers, we need to make sure that only a single driver
> > performs this byte-swapping one time as ACPI tables are global
> structures.
> >
> > I think it is much clearer to define the structure according to the ACPI
> > spec.
> >
> > Thanks,
> > -Toshi
> >
> > > > -----Original Message-----
> > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > Sent: Tuesday, March 01, 2016 8:38 AM
> > > > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > > > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > Structure to comply ACPI 6.1
> > > >
> > > > On Tue, 2016-03-01 at 15:13 +0000, Moore, Robert wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > > > Sent: Monday, February 22, 2016 1:55 PM
> > > > > > To: rjw@rjwysocki.net; Williams, Dan J
> > > > > > Cc: Moore, Robert; Zheng, Lv; elliott@hpe.com;
> > > > > > linux-nvdimm@lists.01.or g; linux-acpi@vger.kernel.org;
> > > > > > linux-kernel@vger.kernel.org; devel@acpica.org; Toshi Kani
> > > > > > Subject: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > > > Structure to comply ACPI 6.1
> > > > > >
> > > > > > ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure
> > > > > > as follows.
> > > > > > - Valid Fields, Manufacturing Location, and Manufacturing Date
> > > > > > are added from reserved range. No change in the structure
> > size.
> > > > > > - IDs defined as SPD values are arrays of bytes. The spec
> > > > > > clarified that they need to be represented as arrays of bytes
> > > > > > as well.
> > > > > >
> > > > > > This patch makes the following changes to support this update.
> > > > > > - Change 'struct acpi_nfit_control_region' to reflect the
> update.
> > > > > > SPD IDs are defined as arrays of bytes, so that they can be
> > > > > > treated in the same way regardless of CPU endianness and are
> > > > > > not miss-treated as little-endian numeric values.
> > > > >
> > > > >
> > > > > I don't think we are going to start changing the ACPI tables
> > > > > defined in the ACPICA headers because of this. We do in fact have
> > > > > macros for this purpose.
> > > >
> > > > Can you elaborate what macros you suggest to use for this purpose?
> > > >
> > > > Thanks,
> > > > -Toshi
> > > N r y b X ǧv ^ ){.n + { i b {ay \x1dʇڙ ,j f h z \x1e w
> > >
> >
> > j:+v w j m zZ+ ݢj" ! i
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
WARNING: multiple messages have this Message-ID (diff)
From: "Moore, Robert" <robert.moore@intel.com>
To: "Moore, Robert" <robert.moore@intel.com>,
Toshi Kani <toshi.kani@hpe.com>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"Williams, Dan J" <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"elliott@hpe.com" <elliott@hpe.com>,
"devel@acpica.org" <devel@acpica.org>
Subject: RE: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1
Date: Tue, 1 Mar 2016 17:41:46 +0000 [thread overview]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D782@ORSMSX110.amr.corp.intel.com>
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
ACPICA does not ever do anything with the "data tables" like NFIT, other than handing off the table when requested by a driver.
> -----Original Message-----
> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 01, 2016 9:37 AM
> To: Toshi Kani; rjw@rjwysocki.net; Williams, Dan J
> Cc: linux-nvdimm@lists.01.org; linux-kernel@vger.kernel.org; linux-
> acpi@vger.kernel.org; elliott@hpe.com; devel@acpica.org
> Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> Structure to comply ACPI 6.1
>
>
>
> > -----Original Message-----
> > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > Sent: Tuesday, March 01, 2016 9:37 AM
> > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure
> > to comply ACPI 6.1
> >
> > On Tue, 2016-03-01 at 16:03 +0000, Moore, Robert wrote:
> > > We have a bunch of macros in include/acmacros.h -- like this:
> > >
> > > ACPI_MOVE_16_TO_16(d, s)
> >
> > There is a problem in using the ACPICA byte-swap macros. ACPI is
> > little- endian arch, so the macros are set to perform byte-swappings
> > when the CPU arch is big-endian. This case, however, is the other way
> > around. The fields in question are defined & stored as arrays of bytes.
>
> That's not what I see in the ACPI spec. The fields are defined like any
> other ACPI table.
>
> Vendor ID 2 6
> Identifier indicating the vendor of the NVDIMM.
> This field shall be set to the value of the NVDIMM SPD Module Manufacturer
> ID Code field a with byte 0 set to DDR4 SPD byte
> 320 and byte 1 set to DDR4 SPD byte 321.
>
> Device ID 2 8
> Identifier for the NVDIMM, assigned by the module vendor.
> This field shall be set to the value of the NVDIMM SPD Module Product
> Identifier field b with byte 0 set to SPD byte 192 and byte 1 set to SPD
> byte 193.
>
> Revision ID 2 10
> Revision of the NVDIMM, assigned by the module vendor.
> Byte 1 of this field is reserved.
> Byte 0 of this field shall be set to the value of the NVDIMM SPD Module
> Revision Code field a (i.e., SPD byte 349).
>
>
> Etc.
>
>
> If you treat
> > them as multi-bytes numeric values, then you need to byte-swap them when
> > the CPU arch is little-endian because arrays of bytes have the same
> > addressing as big-endian.
> >
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
> > these fields are always treated as multi-bytes numeric values despite of
> > the spec. If drivers, we need to make sure that only a single driver
> > performs this byte-swapping one time as ACPI tables are global
> structures.
> >
> > I think it is much clearer to define the structure according to the ACPI
> > spec.
> >
> > Thanks,
> > -Toshi
> >
> > > > -----Original Message-----
> > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > Sent: Tuesday, March 01, 2016 8:38 AM
> > > > To: Moore, Robert; rjw@rjwysocki.net; Williams, Dan J
> > > > Cc: Zheng, Lv; elliott@hpe.com; linux-nvdimm@lists.01.org; linux-
> > > > acpi@vger.kernel.org; linux-kernel@vger.kernel.org; devel@acpica.org
> > > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > Structure to comply ACPI 6.1
> > > >
> > > > On Tue, 2016-03-01 at 15:13 +0000, Moore, Robert wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Toshi Kani [mailto:toshi.kani@hpe.com]
> > > > > > Sent: Monday, February 22, 2016 1:55 PM
> > > > > > To: rjw@rjwysocki.net; Williams, Dan J
> > > > > > Cc: Moore, Robert; Zheng, Lv; elliott@hpe.com;
> > > > > > linux-nvdimm@lists.01.or g; linux-acpi@vger.kernel.org;
> > > > > > linux-kernel@vger.kernel.org; devel@acpica.org; Toshi Kani
> > > > > > Subject: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > > > Structure to comply ACPI 6.1
> > > > > >
> > > > > > ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure
> > > > > > as follows.
> > > > > > - Valid Fields, Manufacturing Location, and Manufacturing Date
> > > > > > are added from reserved range. No change in the structure
> > size.
> > > > > > - IDs defined as SPD values are arrays of bytes. The spec
> > > > > > clarified that they need to be represented as arrays of bytes
> > > > > > as well.
> > > > > >
> > > > > > This patch makes the following changes to support this update.
> > > > > > - Change 'struct acpi_nfit_control_region' to reflect the
> update.
> > > > > > SPD IDs are defined as arrays of bytes, so that they can be
> > > > > > treated in the same way regardless of CPU endianness and are
> > > > > > not miss-treated as little-endian numeric values.
> > > > >
> > > > >
> > > > > I don't think we are going to start changing the ACPI tables
> > > > > defined in the ACPICA headers because of this. We do in fact have
> > > > > macros for this purpose.
> > > >
> > > > Can you elaborate what macros you suggest to use for this purpose?
> > > >
> > > > Thanks,
> > > > -Toshi
> > > N r y b X ǧv ^ ){.n + { i b {ay \x1dʇڙ ,j f h z \x1e w
> > >
> >
> > j:+v w j m zZ+ ݢj" ! i
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
WARNING: multiple messages have this Message-ID (diff)
From: Moore, Robert <robert.moore at intel.com>
To: devel@acpica.org
Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1
Date: Tue, 01 Mar 2016 17:41:46 +0000 [thread overview]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com> (raw)
In-Reply-To: 94F2FBAB4432B54E8AACC7DFDE6C92E37E44D782@ORSMSX110.amr.corp.intel.com
[-- Attachment #1: Type: text/plain, Size: 5823 bytes --]
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
ACPICA does not ever do anything with the "data tables" like NFIT, other than handing off the table when requested by a driver.
> -----Original Message-----
> From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 01, 2016 9:37 AM
> To: Toshi Kani; rjw(a)rjwysocki.net; Williams, Dan J
> Cc: linux-nvdimm(a)lists.01.org; linux-kernel(a)vger.kernel.org; linux-
> acpi(a)vger.kernel.org; elliott(a)hpe.com; devel(a)acpica.org
> Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> Structure to comply ACPI 6.1
>
>
>
> > -----Original Message-----
> > From: Toshi Kani [mailto:toshi.kani(a)hpe.com]
> > Sent: Tuesday, March 01, 2016 9:37 AM
> > To: Moore, Robert; rjw(a)rjwysocki.net; Williams, Dan J
> > Cc: Zheng, Lv; elliott(a)hpe.com; linux-nvdimm(a)lists.01.org; linux-
> > acpi(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; devel(a)acpica.org
> > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure
> > to comply ACPI 6.1
> >
> > On Tue, 2016-03-01 at 16:03 +0000, Moore, Robert wrote:
> > > We have a bunch of macros in include/acmacros.h -- like this:
> > >
> > > ACPI_MOVE_16_TO_16(d, s)
> >
> > There is a problem in using the ACPICA byte-swap macros. ACPI is
> > little- endian arch, so the macros are set to perform byte-swappings
> > when the CPU arch is big-endian. This case, however, is the other way
> > around. The fields in question are defined & stored as arrays of bytes.
>
> That's not what I see in the ACPI spec. The fields are defined like any
> other ACPI table.
>
> Vendor ID 2 6
> Identifier indicating the vendor of the NVDIMM.
> This field shall be set to the value of the NVDIMM SPD Module Manufacturer
> ID Code field a with byte 0 set to DDR4 SPD byte
> 320 and byte 1 set to DDR4 SPD byte 321.
>
> Device ID 2 8
> Identifier for the NVDIMM, assigned by the module vendor.
> This field shall be set to the value of the NVDIMM SPD Module Product
> Identifier field b with byte 0 set to SPD byte 192 and byte 1 set to SPD
> byte 193.
>
> Revision ID 2 10
> Revision of the NVDIMM, assigned by the module vendor.
> Byte 1 of this field is reserved.
> Byte 0 of this field shall be set to the value of the NVDIMM SPD Module
> Revision Code field a (i.e., SPD byte 349).
>
>
> Etc.
>
>
> If you treat
> > them as multi-bytes numeric values, then you need to byte-swap them when
> > the CPU arch is little-endian because arrays of bytes have the same
> > addressing as big-endian.
> >
> > Another issue is that it is not clear who needs to perform the byte-
> > swapping among ACPICA and drivers. If ACPICA, drivers must agree that
> > these fields are always treated as multi-bytes numeric values despite of
> > the spec. If drivers, we need to make sure that only a single driver
> > performs this byte-swapping one time as ACPI tables are global
> structures.
> >
> > I think it is much clearer to define the structure according to the ACPI
> > spec.
> >
> > Thanks,
> > -Toshi
> >
> > > > -----Original Message-----
> > > > From: Toshi Kani [mailto:toshi.kani(a)hpe.com]
> > > > Sent: Tuesday, March 01, 2016 8:38 AM
> > > > To: Moore, Robert; rjw(a)rjwysocki.net; Williams, Dan J
> > > > Cc: Zheng, Lv; elliott(a)hpe.com; linux-nvdimm(a)lists.01.org; linux-
> > > > acpi(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; devel(a)acpica.org
> > > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > Structure to comply ACPI 6.1
> > > >
> > > > On Tue, 2016-03-01 at 15:13 +0000, Moore, Robert wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Toshi Kani [mailto:toshi.kani(a)hpe.com]
> > > > > > Sent: Monday, February 22, 2016 1:55 PM
> > > > > > To: rjw(a)rjwysocki.net; Williams, Dan J
> > > > > > Cc: Moore, Robert; Zheng, Lv; elliott(a)hpe.com;
> > > > > > linux-nvdimm(a)lists.01.or g; linux-acpi(a)vger.kernel.org;
> > > > > > linux-kernel(a)vger.kernel.org; devel(a)acpica.org; Toshi Kani
> > > > > > Subject: [PATCH v2 1/3] ACPI/NFIT: Update Control Region
> > > > > > Structure to comply ACPI 6.1
> > > > > >
> > > > > > ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure
> > > > > > as follows.
> > > > > > - Valid Fields, Manufacturing Location, and Manufacturing Date
> > > > > > are added from reserved range. No change in the structure
> > size.
> > > > > > - IDs defined as SPD values are arrays of bytes. The spec
> > > > > > clarified that they need to be represented as arrays of bytes
> > > > > > as well.
> > > > > >
> > > > > > This patch makes the following changes to support this update.
> > > > > > - Change 'struct acpi_nfit_control_region' to reflect the
> update.
> > > > > > SPD IDs are defined as arrays of bytes, so that they can be
> > > > > > treated in the same way regardless of CPU endianness and are
> > > > > > not miss-treated as little-endian numeric values.
> > > > >
> > > > >
> > > > > I don't think we are going to start changing the ACPI tables
> > > > > defined in the ACPICA headers because of this. We do in fact have
> > > > > macros for this purpose.
> > > >
> > > > Can you elaborate what macros you suggest to use for this purpose?
> > > >
> > > > Thanks,
> > > > -Toshi
> > > N r y b X ǧv ^ ){.n + { i b {ay \x1dʇڙ ,j f h z \x1e w
> > >
> >
> > j:+v w j m zZ+ ݢj" ! i
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
next prev parent reply other threads:[~2016-03-01 17:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 21:55 [PATCH v2 0/3] ACPI 6.1 update for NFIT Control Region Structure Toshi Kani
2016-02-22 21:55 ` Toshi Kani
2016-02-22 21:55 ` [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1 Toshi Kani
2016-02-22 21:55 ` Toshi Kani
2016-03-01 15:13 ` Moore, Robert
2016-03-01 15:13 ` [Devel] " Moore, Robert
2016-03-01 15:13 ` Moore, Robert
2016-03-01 15:13 ` Moore, Robert
2016-03-01 16:38 ` Toshi Kani
2016-03-01 16:38 ` Toshi Kani
2016-03-01 16:38 ` Toshi Kani
2016-03-01 16:03 ` Moore, Robert
2016-03-01 16:03 ` [Devel] " Moore, Robert
2016-03-01 16:03 ` Moore, Robert
2016-03-01 16:03 ` Moore, Robert
2016-03-01 17:36 ` Toshi Kani
2016-03-01 17:36 ` Toshi Kani
2016-03-01 17:36 ` Toshi Kani
2016-03-01 17:37 ` Moore, Robert
2016-03-01 17:37 ` [Devel] " Moore, Robert
2016-03-01 17:37 ` Moore, Robert
2016-03-01 17:37 ` Moore, Robert
2016-03-01 17:41 ` Moore, Robert [this message]
2016-03-01 17:41 ` [Devel] " Moore, Robert
2016-03-01 17:41 ` Moore, Robert
2016-03-01 17:41 ` Moore, Robert
2016-03-01 19:10 ` Toshi Kani
2016-03-01 19:10 ` Toshi Kani
2016-03-01 19:10 ` Toshi Kani
2016-03-01 18:14 ` Dan Williams
2016-03-01 18:14 ` Dan Williams
2016-03-01 18:14 ` Dan Williams
2016-03-01 19:18 ` Toshi Kani
2016-03-01 19:18 ` Toshi Kani
2016-03-01 19:18 ` Toshi Kani
2016-03-01 19:53 ` Toshi Kani
2016-03-01 19:53 ` Toshi Kani
2016-03-01 19:53 ` Toshi Kani
2016-02-22 21:55 ` [PATCH v2 2/3] ACPI/NFIT: Add NVDIMM ID "id" under sysfs Toshi Kani
2016-02-22 21:55 ` Toshi Kani
2016-02-22 21:55 ` [PATCH v2 3/3] nfit_test: Update SPD ID init handlings Toshi Kani
2016-02-22 21:55 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com \
--to=robert.moore@intel.com \
--cc=dan.j.williams@intel.com \
--cc=devel@acpica.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=rjw@rjwysocki.net \
--cc=toshi.kani@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.