2:49 a.m.
On Thu, Apr 14, 2016 at 3:58 PM, Jerry Hoemann <jerry.hoemann(a)hpe.com> wrote:
On Tue, Apr 12, 2016 at 03:05:47PM -0700, Dan Williams wrote:
[..]
> I was thinking that the dsm_mask cease being a pointer in struct
> nvdimm and instead be a cmd_mask (of ND function numbers). struct
> nfit_mem would maintain the dsm_mask. acpi_nfit_ctl is charged with
> translating from the nd command to the acpi dsm. This "just works"
> for the existing sysfs interface, and we can export the dsm_mask in
> the nfit-specific attributes of the nme device.
Not sure I understand.
Are you suggesting that struct nfit_mem have both a dsm_mask and a cmd_mask
and when nvdimm_create is called we pass just cmd_mask and assign it to
new field u64 cmd_mask (deleting the old pointer to dsm_mask?)
Yes.
For NVDIMM-N, the cmd_mask would just be (1<<ND_CMD_CALL) and
for the
pre-existent nvdimm it would be (1<<ND_CMD_CALL)|dsm_mask
Yes.
This would have acpi_nfit_ctl testing against cmd_mask and
__nd_ioctl
testing against dsm_mask.
__nd_ioctl would only test against cmd_mask.
acpi_nfit_ctl would check if it can translate the cmd to a DSM. In
the case of ND_CMD_SMART..ND_CMD_VENDOR it translate to the
corresponding DSM (currently a nop for Intel DIMMs and not applicable
to HP DIMMs). In the case of ND_CMD_CALL it will check the nfit_mem's
dsm_mask to see if the DSM is supported and passes it through.
I don't know how nvdimm_create would get the nd_cmd_mask if its
not determined in acpi_nfit_add_dimm when we determine uuid......
nfit_mem will have a cmd_mask and dsm_mask both initialized at
acpi_nfit_add_dimm() time. At nvdimm_create we just pass
nfit_mem->cmd_mask.