6:28 a.m.
On 2/9/2017 9:02 PM, Dan Williams wrote:
On Thu, Feb 9, 2017 at 11:45 AM, Soccer Liu
<soccer_liu(a)yahoo.com> wrote:
> Hi:
>
> I am trying to figure out what changes might be needed in the NVDIMM driver set for
adding a new Region format interface code.
> After some researching, I found the following constants were defined in the NFIT
header file but never really got referenced in the driver code. (It's used in the test
code)
> 64 #define NFIT_FIC_BYTE cpu_to_le16(0x101) /* byte-addressable energy backed */
> 65 #define NFIT_FIC_BLK cpu_to_le16(0x201) /* block-addressable non-energy backed
*/
> 66 #define NFIT_FIC_BYTEN cpu_to_le16(0x301) /* byte-addressable non-energy backed
*/
>
> Am I missing anything?
No, you're not missing anything. Linux simply doesn't care about the
format interface code and instead relies on the "Address Range Type
GUID" from the "System Physical Address (SPA) Range Structure" in the
NFIT. In other words Linux does not differentiate support for 0x101
and 0x301 because in both cases we end up with a "Byte Addressable
Persistent Memory (PM) Region" in the NFIT. We also don't care about
NFIT_FIC_BLK because that code is redundant with the definition of
block windows in the NFIT.
I suppose we could care about FIC in the future if there is a device
that doesn't quite fit the current driver, perhaps requiring something
special with initialization or management or error handling, but it
would depend on what the new device is.
The FIC is exposed through /sys so a management tool might care.
-- ljk
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm(a)lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm