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 1/3] Allow all supported HPE DSM functions to be called
Date: Mon, 13 Feb 2017 13:17:46 -0500 [thread overview]
Message-ID: <58A1F84A.2090605@hpe.com> (raw)
In-Reply-To: <CAPcyv4gRNeuQFwDtwGzBbs+CKZnkYibCMm0UXCD2ZWyOZN0GJg@mail.gmail.com>
On 02/13/2017 12:28 PM, Dan Williams wrote:
> On Mon, Feb 13, 2017 at 8:27 AM, Linda Knippers <linda.knippers@hpe.com> wrote:
>> As it is today, we can't enable or test new functions in firmware without
>> changing the kernel.
>>
>> With this patch we allow function 0 for the HPE DSM families,
>> as is already allowed with the MS family. We now only restrict
>> the functions to the currently documented set if the module parameter
>> "disable_vendor_specific" is set. Since the module parameter
>> description says "Limit commands to the publicly specified set",
>> this approach seems correct.
>>
>
> My concern is that this makes the kernel less strict by default. Given
> this is only a test capability lets add a module option to override
> the default dsm_mask.
This part isn't strictly a test capability. It's also to allow older
kernels to be supported with newer NVDIMM hardware, firmware, and management tools.
We shouldn't need a customer to update their production kernel just to support
an NVDIMM management tool.
As for less secure by default, the default is to allow undocumented
functions of the "vendor specific" type. How is the really different?
-- ljk
> That would also seem to combine well with the
> new 'default_dsm_family' option.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-02-13 18:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 16:27 [PATCH 0/3] apci, nfit: DSM improvements Linda Knippers
2017-02-13 16:27 ` [PATCH 1/3] Allow all supported HPE DSM functions to be called Linda Knippers
2017-02-13 17:28 ` Dan Williams
2017-02-13 18:17 ` Linda Knippers [this message]
2017-02-13 18:30 ` Dan Williams
2017-02-15 23:19 ` Linda Knippers
2017-02-16 0:29 ` Dan Williams
2017-02-16 0:45 ` Linda Knippers
2017-02-16 2:03 ` Dan Williams
2017-02-16 18:51 ` Linda Knippers
2017-02-16 19:35 ` Dan Williams
2017-02-16 20:13 ` Linda Knippers
2017-02-16 20:48 ` Dan Williams
2017-02-16 21:07 ` Dan Williams
2017-02-16 22:40 ` Linda Knippers
2017-02-16 22:43 ` Dan Williams
2017-02-16 22:47 ` Linda Knippers
2017-02-16 22:49 ` Dan Williams
2017-02-16 22:52 ` Linda Knippers
2017-02-16 22:33 ` Linda Knippers
2017-02-19 16:28 ` Boaz Harrosh
2017-02-13 16:27 ` [PATCH 2/3] Allow specifying a default DSM family Linda Knippers
2017-02-13 16:27 ` [PATCH 3/3] Remove unnecessary newline Linda Knippers
2017-02-13 17:32 ` Dan Williams
2017-02-13 18:02 ` 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=58A1F84A.2090605@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.