On Fri, Mar 20, 2020 at 2:25 AM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > > Hi Dan, > > > Dan Williams <dan.j.willi...@intel.com> writes: > > ... > > > > > >> > >> Or are you suggesting that application should not infer any of those > >> details looking at persistence_domain value? If so what is the purpose > >> of exporting that attribute? > > > > The way the patch was worded I thought it was referring to an explicit > > mechanism outside cpu cache flushes, i.e. a mechanism that required a > > driver call. > > > > This patch is blocked because I am not expressing the details correctly. > I updates this as below. Can you suggest if this is ok? If not what > alternate wording do you suggest to document "memory controller" > > > commit 329b46e88f8cd30eee4776b0de7913ab4d496bd8 > Author: Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> > Date: Wed Dec 18 13:53:16 2019 +0530 > > libnvdimm: Update persistence domain value for of_pmem and papr_scm device > > Currently, kernel shows the below values > "persistence_domain":"cpu_cache" > "persistence_domain":"memory_controller" > "persistence_domain":"unknown" > > "cpu_cache" indicates no extra instructions is needed to ensure the > persistence > of data in the pmem media on power failure. > > "memory_controller" indicates cpu cache flush instructions is required to > flush > the data. Platform provides mechanisms to automatically flush outstanding > write data from memory controler to pmem on system power loss. > > Based on the above use memory_controller for non volatile regions on > ppc64.
Looks good to me, want to resend via git-format-patch?
