11:58 p.m.
On Tue, Apr 12, 2016 at 03:05:47PM -0700, Dan Williams wrote:
On Tue, Apr 12, 2016 at 2:41 PM, Jerry Hoemann
<jerry.hoemann(a)hpe.com> wrote:
> On Mon, Apr 11, 2016 at 05:30:25PM -0700, Dan Williams wrote:
>> On Mon, Apr 11, 2016 at 4:58 PM, Jerry Hoemann <jerry.hoemann(a)hpe.com>
wrote:
>> > On Mon, Apr 11, 2016 at 02:43:39PM -0700, Dan Williams wrote:
>> >> On Mon, Mar 21, 2016 at 12:37 PM, Jerry Hoemann
<jerry.hoemann(a)hpe.com> wrote:
>> >> > NVDIMM DSMs whose functions map to the Intel Example DSM, can
>> >> > be called with the ND_IOCTL_.* ioctl interface. Those that
>> >> > don't map, can only be called with the pass thru command.
>> >> >
>> >> > Save this indication in struct nvdimm to be passed to
>> >> > the sysfs interface.
>> >> >
>> >>
>> >> I'm having trouble understanding the intent of cmd_ioctl. I
don't
>> >> want a flag for "supports Intel Example DSM", I want a mask
of ND
>> >> commands the bus provider knows how to handle in its ->ndctl()
entry
>> >> point for the given dimm. The bus provider is free to provide a
>> >> translation of ND command to the bus specific command. It's just
an
>> >> arbitrary coincidence that the current list of ND commands matches the
>> >> Intel ACPI _DSM command format.
>> >
>> > This is my extension of your earlier RFC patch, so I may
>> > have misunderstood your original intent.
>> >
>> > The commands_show functions prints the listing of commands for that
device.
>> > There is one version for root, and one version for non-root.
>> >
>> > For root commands, both dsm spec match on names and semantics, so no
>> > code works for both nvdimms types.
>> >
>> > But for non-root commands the names/semantics don't match. So, this
>> > is an attempt to show that on an NVDIMM-N, only the pass thru command
>> > is supported.
>>
>> Ah, ok. Rather than telling the core about a dsm_mask and a cmd_ioctl
>> at nvdimm_create() time, it should just be passing the mask of generic
>> ND commands that the dimm supports. For NVDIMM-N that mask will just
>> be (1 << 10) it's up to the nfit driver to manage any ND command to
>> ACPI _DSM command number translation.
>
> dsm_mask is used in both acpi_nfit_ctl and __nd_ioctl to filter calls
> the functions might make. I think dsm_mask and cmd_ioctl need to be
> kept separate, or drop use of filtering by dsm_mask in these two
> functions.
>
> Or another way of controlling what commands_show produces?
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?)
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
This would have acpi_nfit_ctl testing against cmd_mask and __nd_ioctl
testing against dsm_mask.
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......
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------