On 2/9/2017 9:02 PM, Dan Williams wrote: > On Thu, Feb 9, 2017 at 11:45 AM, Soccer Liu <[email protected]> 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 > [email protected] > https://lists.01.org/mailman/listinfo/linux-nvdimm > _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
