Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44D7A1@ORSMSX110.amr.corp.intel.com>
Date:	Tue, 1 Mar 2016 17:41:46 +0000
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Moore, Robert" <robert.moore@...el.com>,
	Toshi Kani <toshi.kani@....com>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"Williams, Dan J" <dan.j.williams@...el.com>
CC:	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"elliott@....com" <elliott@....com>,
	"devel@...ica.org" <devel@...ica.org>
Subject: RE: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to
 comply ACPI 6.1

> > 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@...ica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 01, 2016 9:37 AM
> To: Toshi Kani; rjw@...ysocki.net; Williams, Dan J
> Cc: linux-nvdimm@...ts.01.org; linux-kernel@...r.kernel.org; linux-
> acpi@...r.kernel.org; elliott@....com; devel@...ica.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@....com]
> > Sent: Tuesday, March 01, 2016 9:37 AM
> > To: Moore, Robert; rjw@...ysocki.net; Williams, Dan J
> > Cc: Zheng, Lv; elliott@....com; linux-nvdimm@...ts.01.org; linux-
> > acpi@...r.kernel.org; linux-kernel@...r.kernel.org; devel@...ica.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@....com]
> > > > Sent: Tuesday, March 01, 2016 8:38 AM
> > > > To: Moore, Robert; rjw@...ysocki.net; Williams, Dan J
> > > > Cc: Zheng, Lv; elliott@....com; linux-nvdimm@...ts.01.org; linux-
> > > > acpi@...r.kernel.org; linux-kernel@...r.kernel.org; devel@...ica.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@....com]
> > > > > > Sent: Monday, February 22, 2016 1:55 PM
> > > > > > To: rjw@...ysocki.net; Williams, Dan J
> > > > > > Cc: Moore, Robert; Zheng, Lv; elliott@....com;
> > > > > > linux-nvdimm@...ts.01.or g; linux-acpi@...r.kernel.org;
> > > > > > linux-kernel@...r.kernel.org; devel@...ica.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 .ʇڙ ,j   f   h   z . w
> > >
> >
> >    j:+v   w j m         zZ+     ݢj"  ! i
> _______________________________________________
> Devel mailing list
> Devel@...ica.org
> https://lists.acpica.org/mailman/listinfo/devel

Powered by blists - more mailing lists