On Wed, Sep 20, 2017 at 2:00 PM, Elliott, Robert (Persistent Memory) <[email protected]> wrote: > > > > > -----Original Message----- > > From: Linux-nvdimm [mailto:[email protected]] On Behalf Of > > Brian Stark > > Sent: Wednesday, September 20, 2017 11:11 AM > > To: Dan Williams <[email protected]> > > Cc: Raghu Kulkarni <[email protected]>; [email protected] > > Subject: Re: Access to NVDIMM JEDEC registers > > > > Thanks for the response Dan, > > > > As a developer of NVDIMMs we interface to our controller using the SMBUS > > interface, which is part of the JEDEC standard. In the past we have always > > tested and accessed out NVDIMMs by directly manipulating the SMBUS > > controller defined in the chipsets. As you may be aware this was never a > > very good solution as there is an inherent synchronization problem with any > > other actors that may require SMBUS access, but it was the only method > > available. The solution above was good enough for testing hardware, but is > > a security risk when deploying in an end user environment, not to mention > > the multiple corner cases opened up trying to synchronize SMBUS access with > > TSOD or the BMC. > > > > The DSM interface provides functions 27 and 28 (I2C Read and Write > > respectively) . Most of the other functions provide the required > > functionality for NVDIMMs and is almost a one to one mapping of our own API > > using the method mentioned above. > > Don't expect those DSMs to be available outside of debug modes. > They're too dangerous for the reasons you describe:
Brian, is the JEDEC register data you want to retrieve available via the NFIT or other DSMs? Or, can you point me to the spec that defines the registers in question? I didn't find them in Annex L. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
