On Wed, Apr 1, 2020 at 8:08 PM Dan Williams wrote:
[..]
> > * "locked" : Indicating that nvdimm contents cant be modified
> >until next power cycle.
>
> There is the generic NDD_LOCKED flag, can you use that? ...and in
> general I wonder if we should try to unify all the
Vaibhav Jain writes:
> Thanks for reviewing this patch Mpe,
> Michael Ellerman writes:
>> Vaibhav Jain writes:
...
>>
>>> + /* Check for various masks in bitmap and set the buffer */
>>> + if (health & PAPR_SCM_DIMM_UNARMED_MASK)
>>> + rc += sprintf(buf, "not_armed ");
>>
>> I
Vaibhav Jain writes:
> Implement support for fetching nvdimm health information via
> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
> of 64-bit big-endian integers which are then stored in 'struct
> papr_scm_priv' and subsequently partially exposed to user-space via
>
On Tue, Mar 31, 2020 at 7:33 AM Vaibhav Jain wrote:
>
> Implement support for fetching nvdimm health information via
> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
> of 64-bit big-endian integers which are then stored in 'struct
> papr_scm_priv' and subsequently partially
Vaibhav Jain writes:
> Implement support for fetching nvdimm health information via
> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
> of 64-bit big-endian integers which are then stored in 'struct
> papr_scm_priv' and subsequently partially exposed to user-space via
>
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
of 64-bit big-endian integers which are then stored in 'struct
papr_scm_priv' and subsequently partially exposed to user-space via
newly introduced dimm specific
