On Fri, Apr 24, 2015 at 10:18 AM, Toshi Kani <toshi.kani@xxxxxx> wrote:
> On Fri, 2015-04-24 at 09:25 -0700, Dan Williams wrote:
>> On Fri, Apr 24, 2015 at 8:56 AM, Toshi Kani <toshi.kani@xxxxxx> wrote:
>> > On Fri, 2015-04-17 at 21:35 -0400, Dan Williams wrote:
>> >> Most configuration of the nd-subsystem is done via nd-sysfs. However,
>> >> the NFIT specification defines a small set of messages that can be
>> >> passed to the subsystem via platform-firmware-defined methods. The
>> >> command set (as of the current version of the NFIT-DSM spec) is:
>> >>
>> >> NFIT_CMD_SMART: media health and diagnostics
>> >> NFIT_CMD_GET_CONFIG_SIZE: size of the label space
>> >> NFIT_CMD_GET_CONFIG_DATA: read label
>> >> NFIT_CMD_SET_CONFIG_DATA: write label
>> >> NFIT_CMD_VENDOR: vendor-specific command passthrough
>> >> NFIT_CMD_ARS_CAP: report address-range-scrubbing capabilities
>> >> NFIT_CMD_START_ARS: initiate scrubbing
>> >> NFIT_CMD_QUERY_ARS: report on scrubbing state
>> >> NFIT_CMD_SMART_THRESHOLD: configure alarm thresholds for smart events
>> >
>> > "nd/bus.c" provides two features, 1) the top level ND bus driver which
>> > is the central part of the ND, and 2) the ioctl interface specific to
>> > the example-DSM-interface. I think the example-DSM-specific part should
>> > be put into an example-DSM-support module, so that the ND can support
>> > other _DSMs as necessary. Also, _DSM needs to be handled as optional.
>>
>> I don't think it needs to be separated, they'll both end up using the
>> same infrastructure just with different UUIDs on the ACPI device
>> interface or different format-interface-codes. A firmware
>> implementation is also free to disable individual DSMs (see
>> nd_acpi_add_dimm).
>
> Well, ioctl cmd# is essentially func# of the _DSM, and each cmd
> structure needs to match with its _DSM output data structure. So, I do
> not think these cmds will work for other _DSMs. That said, the ND is
> complex enough already, and we should not make it more complicated for
> the initial version... So, how about changing the name of /dev/ndctl0
> to indicate RFIC 0x0201, ex. /dev/nd0201ctl0? That should allow
> separate ioctl()s for other RFICs. The code can be updated when other
> _DSM actually needs to be supported by the ND.
No, all you need is unique command names (see libndctl
ndctl_{bus|dimm}_is_cmd_supported()) and then translate the ND cmd
number to the firmware function number in the "provider". It just so
happens that for these first set of commands the ND cmd number matches
the ACPI device function number in the DSM-interface-example, but
there is no reason that need always be the case.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
