From: Dan Williams [mailto:firstname.lastname@example.org]
Sent: Monday, June 18, 2018 2:47 PM
To: Kani, Toshi <toshi.kani(a)hpe.com>
Cc: linux-kernel(a)vger.kernel.org; linux-nvdimm(a)lists.01.org; Moore, Robert
<robert.moore(a)intel.com>; Li, Juston <juston.li(a)intel.com>;
rjw(a)rjwysocki.net; linux-acpi(a)vger.kernel.org; Elliott, Robert (Persistent
Subject: Re: [PATCH v3 1/2] acpi/nfit: Update nfit driver to comply with
On Mon, Jun 18, 2018 at 12:39 PM, Kani, Toshi <toshi.kani(a)hpe.com> wrote:
> On Mon, 2018-06-18 at 12:01 -0700, Dan Williams wrote:
>> On Mon, Apr 25, 2016 at 2:43 PM Toshi Kani <toshi.kani(a)hpe.com> wrote:
>> > 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 (SPD values) are stored as arrays of bytes (i.e. big-endian
>> > format). The spec clarifies that they need to be represented
>> > as arrays of bytes as well.
>> Circling back on this a couple years too late... where are you reading
>> this "arrays of bytes" note. As far as I can see this is wrong.
>> says that vendor id is stored LSB of the id is stored at the lowest
>> byte in SPD, which is little endian. So it seems Linux has showing the
>> incorrect value for a long time now.
> This follows ACPI 6.2a section 184.108.40.206 NVDIMM Representation Format,
> which Robert cited in his comment below:
Right, the representation format has the fields big-endian for some
reason, but the individual values for sysfs should be show
little-endian as far as I can see. What am I missing?
In practice, the serial numbers from three major DDR4 DIMM manufacturers
are being assigned as big-endian, like in this set of NVDIMM-Ns:
and this set of regular DIMMs:
Of the possible approaches for the sysfs nfit field decodes:
matches printed label content (text and barcode)
matches ACPI display advice for management tools
probably matches SMBIOS Serial Number string format (although
that depends on the system firmware)
requires user to know that this OS uses big-endian
has been upstream for a while now
harder to see that cd812f12 matches 122f81cd seen elsewhere
harder to notice that B4516839 is a peer of 4C136839
might match other little-endian-only OSes
requires user to know that this OS uses little-endian
config/status files referencing the DIMMs are not portable
requires user to know that this OS uses native endianness
requires user to know the CPU endianness
was upstream several years ago