Linux-NVDIMM Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Knippers <linda.knippers@hpe.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH 2/3] Allow specifying a default DSM family
Date: Tue, 7 Mar 2017 14:05:41 -0500	[thread overview]
Message-ID: <58BF0485.1090003@hpe.com> (raw)
In-Reply-To: <58BF0336.4090606@hpe.com>

On 03/07/2017 02:00 PM, Linda Knippers wrote:
> On 03/06/2017 08:56 PM, Dan Williams wrote:
>> On Mon, Mar 6, 2017 at 5:33 PM, Linda Knippers <linda.knippers@hpe.com> wrote:
>>> On 03/06/2017 07:39 PM, Dan Williams wrote:
>>>> On Mon, Mar 6, 2017 at 4:25 PM, Linda Knippers <linda.knippers@hpe.com> wrote:
>>>>> Provide the ability to request a default DSM family. If it is not
>>>>> supported, then fall back to the normal discovery order.
>>>>>
>>>>> This is helpful for testing platforms that support multiple DSM families.
>>>>> It will also allow administrators to request the DSM family that their
>>>>> management tools support, which may not be the first one found using
>>>>> the current discovery order.
>>>>>
>>>>> Signed-off-by: Linda Knippers <linda.knippers@hpe.com>
>>>>> ---
>>>>>  drivers/acpi/nfit/core.c | 26 ++++++++++++++++++++++----
>>>>>  1 file changed, 22 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
>>>>> index 97d42ff..78c46a7 100644
>>>>> --- a/drivers/acpi/nfit/core.c
>>>>> +++ b/drivers/acpi/nfit/core.c
>>>>> @@ -55,6 +55,11 @@
>>>>>  module_param(override_dsm_mask, ulong, S_IRUGO);
>>>>>  MODULE_PARM_DESC(override_dsm_mask, "Bitmask of allowed NVDIMM DSM functions");
>>>>>
>>>>> +static int default_dsm_family = -1;
>>>>> +module_param(default_dsm_family, int, S_IRUGO);
>>>>> +MODULE_PARM_DESC(default_dsm_family,
>>>>> +               "Try this DSM type first when identifying NVDIMM family");
>>>>> +
>>>>>  LIST_HEAD(acpi_descs);
>>>>>  DEFINE_MUTEX(acpi_desc_lock);
>>>>>
>>>>> @@ -1371,7 +1376,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
>>>>>         struct device *dev = acpi_desc->dev;
>>>>>         unsigned long dsm_mask;
>>>>>         const u8 *uuid;
>>>>> -       int i;
>>>>> +       int i = -1;
>>>>>
>>>>>         /* nfit test assumes 1:1 relationship between commands and dsms */
>>>>>         nfit_mem->dsm_mask = acpi_desc->dimm_cmd_force_en;
>>>>> @@ -1399,10 +1404,23 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
>>>>>          * Until standardization materializes we need to consider 4
>>>>>          * different command sets.  Note, that checking for function0 (bit0)
>>>>>          * tells us if any commands are reachable through this uuid.
>>>>> +        * First check for a requested default.
>>>>>          */
>>>>> -       for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
>>>>> -               if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
>>>>> -                       break;
>>>>> +       if (default_dsm_family >= NVDIMM_FAMILY_INTEL &&
>>>>> +                       default_dsm_family <= NVDIMM_FAMILY_MSFT) {
>>>>> +               if (acpi_check_dsm(adev_dimm->handle,
>>>>> +                               to_nfit_uuid(default_dsm_family), 1, 1))
>>>>> +                       i = default_dsm_family;
>>>>> +               else
>>>>> +                       dev_dbg(dev, "default_dsm_family %d not supported\n",
>>>>> +                               default_dsm_family);
>>>>> +       }
>>>>> +       if (i == -1) {
>>>>> +               for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
>>>>> +                       if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i),
>>>>> +                                       1, 1))
>>>>> +                               break;
>>>>> +       }
>>>>
>>>> I think we can make this simpler and more deterministic with a "force"
>>>> option? Something like:
>>>>
>>>> @@ -1397,8 +1397,12 @@ static int acpi_nfit_add_dimm(struct
>>>> acpi_nfit_desc *acpi_desc,
>>>>          * tells us if any commands are reachable through this uuid.
>>>>          */
>>>>         for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
>>>> -               if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
>>>> -                       break;
>>>> +               if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1)) {
>>>> +                       if (force_dsm_family < 0)
>>>> +                               break;
>>>> +                       else if (i == force_dsm_family)
>>>> +                               break;
>>>> +               }
>>>>
>>>>         /* limit the supported commands to those that are publicly documented */
>>>>         nfit_mem->family = i;
>>>>
>>>> ...because the user specifying the override should know ahead of time
>>>> if that family is available, and we should fail the detection
>>>> otherwise.
>>>
>>> It's more complicated when you have a mixture of NVDIMM types, where not all
>>> NVDIMMs support the same families.  For example, you could have an Intel
>>> NVDIMM in the same system as an HPE NVDIMM-N.  The reason I called it
>>> "default" is because it should be the default for all devices that support
>>> that family but I didn't want other types of NVDIMMs to end up with
>>> no family at all.
>>>
>>
>> Ok, but I still think we can make the logic a bit simpler. I'm
>> reacting to the new "if (i == -1)" branch and 2 locations where we
>> call "acpi_check_dsm()". How about this to centralize everything?
>>
>> @@ -1397,11 +1397,15 @@ static int acpi_nfit_add_dimm(struct
>> acpi_nfit_desc *acpi_desc,
>>          * tells us if any commands are reachable through this uuid.
>>          */
>>         for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
>> -               if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
>> -                       break;
>> +               if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1)) {
>> +                       if (family < 0 || i == default_dsm_family) {
>> +                               family = i;
>> +                               break;
> 
> This actually doesn't work with the break since the for() will break
> on the first match, just like the current code.  It works if I remove
> the break, but then we cycle through all the families even if the
> default_dsm_family parameter isn't used.  Do you care about that?
> 
> I think it can be simple or efficient but not both.

Something like this does work.

        for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
                if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1)) {
                        if (default_dsm_family != -1) {
                                if (i == default_dsm_family) {
                                        family = i;
                                        break;
                                }
                                if (family < 0)
                                        family = i;
                        }
                        else {
                                family = i;
                                break;
                        }
                }

> 
> -- ljk
>> +                       }
>> +               }
>>
>>         /* limit the supported commands to those that are publicly documented */
>> -       nfit_mem->family = i;
>> +       nfit_mem->family = family;
>>         if (nfit_mem->family == NVDIMM_FAMILY_INTEL) {
>>                 dsm_mask = 0x3fe;
>>                 if (disable_vendor_specific)
>>
> 

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  reply	other threads:[~2017-03-07 19:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07  0:25 [PATCH v2 0/3] apci, nfit: DSM improvements Linda Knippers
2017-03-07  0:25 ` [PATCH 1/3] Allow override of built-in bitmasks for NVDIMM DSMs Linda Knippers
2017-03-07  8:53   ` Johannes Thumshirn
2017-03-07  0:25 ` [PATCH 2/3] Allow specifying a default DSM family Linda Knippers
2017-03-07  0:39   ` Dan Williams
2017-03-07  1:33     ` Linda Knippers
2017-03-07  1:56       ` Dan Williams
2017-03-07  2:13         ` Linda Knippers
2017-03-07 19:00         ` Linda Knippers
2017-03-07 19:05           ` Linda Knippers [this message]
2017-03-07 19:26           ` Dan Williams
2017-03-07  0:25 ` [PATCH 3/3] Remove unnecessary newline Linda Knippers
2017-03-07  8:53   ` Johannes Thumshirn
  -- strict thread matches above, loose matches on Subject: below --
2017-03-07 21:35 [PATCH v3 0/3] apci, nfit: DSM improvements Linda Knippers
2017-03-07 21:35 ` [PATCH 2/3] Allow specifying a default DSM family Linda Knippers
2017-02-13 16:27 [PATCH 0/3] apci, nfit: DSM improvements Linda Knippers
2017-02-13 16:27 ` [PATCH 2/3] Allow specifying a default DSM family Linda Knippers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58BF0485.1090003@hpe.com \
    --to=linda.knippers@hpe.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox