I guess my understanding was that the ACPI method was already deployed. I was expecting this to be just a matter of replacing my kernel driver with system calls using this method. I am not trying to re-invent a wheel, I just want to implement the standard methodology. Most of our existing customers require access to the JEDEC registers so that they can actively monitor the health of the NVDIMM, this requires SMBUS access to the JEDEC registers (7 bit Address 0x4X). My assumption was that this support now built in to the kernel. The reason I mentioned the direct access functions is that the standard does provide for vendor specific registers. What I really want to know is how much of the ACPI interface is implemented so I know what I have to work with.
Brian 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: > > * collisions with other entities trying to use the SMBus controllers > (CLTT/TSOD, BMICs, SMI handlers, etc.) > > * lack of higher-level mutual exclusion. JEDEC BAEBI register > accesses require performing several I2C transactions without > interruption. For example, the OPEN_PAGE register controls what > registers are actually being accessed. Some registers are in > pairs that must be read and written together to have coherent > meaning. > > * lack of security. This would let the caller do things like change > the arming, trigger a restore, download new firmware, inject errors, > etc. > > We've discussed defining an ACPI method that software could call to > arbitrate for ownership of the SMBus controller (and give it back). > This would facilitate OS-based online firmware download tools, for example. > > One stumbling block is error handling; what if some entity wins control > but doesn't give it back? There's no way to cleanly kick it off, prevent > it from touching the SMBus controller registers if it does wake up, > and clean up whatever transactions it had in progress. > > Another problem is not all the SMBus controller capabilities are > necessarily supported by a system. Although software could program it > to run at 1 MHz, signal integrity might only be good for 100 kHz > or 400 kHz. Only system firmware knows those restrictions. > > Functionality-based DSMs are much safer and let system-provided code > (the ACPI machine language code executed in the OS context, system > firmware executed in SMM context, and system firmware executed > during the next boot) figure out how to implement the request. > > > --- > Robert Elliott, HPE Persistent Memory > > > -- CONFIDENTIALITY This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof. ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
