From: linux-kernel-owner(a)vger.kernel.org [mailto:linux-kernel-
owner(a)vger.kernel.org] On Behalf Of Dan Williams
Sent: Tuesday, June 19, 2018 10:29 AM
Subject: Re: [PATCH v3 1/2] acpi/nfit: Update nfit driver to comply with
> Here are some examples (kernel 4.17):
Note that these values were as reported on a little-endian system.
Ok, so the lowest significant byte of the Micron id is supposed to
0x2c and this text representation matches that. So the bytes are being
endian swapped when written to the SPD?
SPD byte 320 is 0x80. That's the bank number byte (with odd parity).
SPD byte 321 is 0x2c. That's the manufacturer code byte (with odd parity).
If treated as a single 2-byte value, that is:
* 0x802c (32812 in decimal) if interpreted as big-endian
* 0x2c80 (11392 in decimal) if interpreted as little-endian
Reviewing the _show() functions in drivers/acpi/nfit/core.c:
BE id:802c-0f-1612-122f8255 [SPD bytes 320-328]
BE subsystem_vendor:0x8034 [Cypress Semiconductor]
BE vendor:0x802c [Micron]
(BE=fixed big-endian, LE=fixed little-endian, NE=native-endian,
BE and LE will print the same regardless of the endianness
of the system, while NE will vary.
Reviewing the NE sysfs files:
This NFIT field reports an SMBIOS handle (instance ID), a LE number
from 0..n (0x103 on one of my systems). dmidecode shows handles
Handle 0x0016, DMI type 17, 40 bytes
Array Handle: 0x000A
On a big-endian system, I think we'll see
which means 5632 decimal, which is misleading. Fixed LE would
The code that parses _DSM function 0 output, acpi_check_dsm(),
correctly interprets the bitmask as little-endian for internal
calculations. I think a big-endian system will print
dsm_mask:0x763c, which is confusing. Fixed LE would be better.
The override_dsm_mask module parameter needs to match.
This is an internal value, so NE is fine.