quoted

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

quoted

-----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:

quoted

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

quoted

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.

quoted

I think it is much clearer to define the structure according to the ACPI
spec.

Thanks,
-Toshi

quoted

quoted

-----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:

quoted

quoted

-----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.

quoted

quoted

quoted

quoted

 - 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.

quoted

quoted

quoted

quoted

quoted

   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

quoted

quoted

   j:+v   w j m         zZ+     ݢj"  ! i

_______________________________________________
Devel mailing list
Devel@acpica.org
https://lists.acpica.org/mailman/listinfo/devel