1:35 p.m.
The first two patches in this series are motivated by feedback
from distribution developers, test engineers, and management tool
developers. We need the ability to test and support Linux and
management tools on systems that support more than one DSM family
for NVDIMM-N.
We also need the ability to test and support new functions without
requiring users to update their kernel. These changes will also
facilate development as we move toward DSM standardization.
The ability to restrict DSM functions to the currently documented
set is still in place.
The third patch cleans up a cosmetic/modinfo parsing issue with one
of the existing module parameters.
Changes in v3:
- Simplified dsm address family determination based on Dan's feedback.
Changes in v2:
- Switched from allowing all functions advertised by the
firmware through function 0 to an override module parameter.
Linda Knippers (3):
Allow override of built-in bitmasks for NVDIMM DSMs
Allow specifying a default DSM family
Remove unnecessary newline
drivers/acpi/nfit/core.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--
1.8.3.1
1:35 p.m.
New subject: [PATCH 1/3] Allow override of built-in bitmasks for NVDIMM DSMs
As it is today, we can't enable or test new NVDIMM management functions
provided by new firmware and tools without changing the kernel. We also
can't prevent documented DSM functions from being called in the
case of buggy firmware. This patch provides a module parameter that
overrides the DSM function mask that is built into the kernel.
If the "disable_vendor_specific" module parameter is also used
we ignore the new parameter.
Signed-off-by: Linda Knippers <linda.knippers(a)hpe.com>
---
drivers/acpi/nfit/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 662036b..97d42ff 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -51,6 +51,10 @@
MODULE_PARM_DESC(disable_vendor_specific,
"Limit commands to the publicly specified set\n");
+static unsigned long override_dsm_mask;
+module_param(override_dsm_mask, ulong, S_IRUGO);
+MODULE_PARM_DESC(override_dsm_mask, "Bitmask of allowed NVDIMM DSM
functions");
+
LIST_HEAD(acpi_descs);
DEFINE_MUTEX(acpi_desc_lock);
@@ -1402,7 +1406,9 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
/* limit the supported commands to those that are publicly documented */
nfit_mem->family = i;
- if (nfit_mem->family == NVDIMM_FAMILY_INTEL) {
+ if (override_dsm_mask && !disable_vendor_specific)
+ dsm_mask = override_dsm_mask;
+ else if (nfit_mem->family == NVDIMM_FAMILY_INTEL) {
dsm_mask = 0x3fe;
if (disable_vendor_specific)
dsm_mask &= ~(1 << ND_CMD_VENDOR);
--
1.8.3.1
1:35 p.m.
New subject: [PATCH 2/3] Allow specifying a default DSM family
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(a)hpe.com>
---
drivers/acpi/nfit/core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 97d42ff..0564cd6 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);
@@ -1372,6 +1377,7 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
unsigned long dsm_mask;
const u8 *uuid;
int i;
+ int family = -1;
/* nfit test assumes 1:1 relationship between commands and dsms */
nfit_mem->dsm_mask = acpi_desc->dimm_cmd_force_en;
@@ -1402,10 +1408,11 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
*/
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 (family < 0 || i == default_dsm_family)
+ family = i;
/* limit the supported commands to those that are publicly documented */
- nfit_mem->family = i;
+ nfit_mem->family = family;
if (override_dsm_mask && !disable_vendor_specific)
dsm_mask = override_dsm_mask;
else if (nfit_mem->family == NVDIMM_FAMILY_INTEL) {
--
1.8.3.1
1:35 p.m.
New subject: [PATCH 3/3] Remove unnecessary newline
The newline in MODULE_PARM_DESC causes modinfo to print the parameter
data type on a separate line, which is different from all the other
module parameters and could potentially cause a problem for someone
parsing the output of modinfo.
Signed-off-by: Linda Knippers <linda.knippers(a)hpe.com>
---
drivers/acpi/nfit/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 0564cd6..0a51b75 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -49,7 +49,7 @@
static bool disable_vendor_specific;
module_param(disable_vendor_specific, bool, S_IRUGO);
MODULE_PARM_DESC(disable_vendor_specific,
- "Limit commands to the publicly specified set\n");
+ "Limit commands to the publicly specified set");
static unsigned long override_dsm_mask;
module_param(override_dsm_mask, ulong, S_IRUGO);
--
1.8.3.1
2:01 a.m.
On Tue, Mar 07, 2017 at 04:35:11PM -0500, Linda Knippers wrote:
The first two patches in this series are motivated by feedback
from distribution developers, test engineers, and management tool
developers. We need the ability to test and support Linux and
management tools on systems that support more than one DSM family
for NVDIMM-N.
We also need the ability to test and support new functions without
requiring users to update their kernel. These changes will also
facilate development as we move toward DSM standardization.
The ability to restrict DSM functions to the currently documented
set is still in place.
The third patch cleans up a cosmetic/modinfo parsing issue with one
of the existing module parameters.
Hi Linda and Dan,
Can you tell me the status of this series? I haven't seen it in Dan's
tree and can't remember a reason why it's not merged.
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn(a)suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
6:19 a.m.
On 03/31/2017 05:01 AM, Johannes Thumshirn wrote:
On Tue, Mar 07, 2017 at 04:35:11PM -0500, Linda Knippers wrote:
> The first two patches in this series are motivated by feedback
> from distribution developers, test engineers, and management tool
> developers. We need the ability to test and support Linux and
> management tools on systems that support more than one DSM family
> for NVDIMM-N.
>
> We also need the ability to test and support new functions without
> requiring users to update their kernel. These changes will also
> facilate development as we move toward DSM standardization.
> The ability to restrict DSM functions to the currently documented
> set is still in place.
>
> The third patch cleans up a cosmetic/modinfo parsing issue with one
> of the existing module parameters.
Hi Linda and Dan,
Can you tell me the status of this series? I haven't seen it in Dan's
tree and can't remember a reason why it's not merged.
I assume/hope it's just waiting for the next merge window.
At this point I think Dan is just pulling in critical fixes.
If there's some other reason, I'd like to hear about it too.
-- ljk
Thanks,
Johannes
6:31 a.m.
On Fri, Mar 31, 2017 at 09:19:17AM -0400, Linda Knippers wrote:
On 03/31/2017 05:01 AM, Johannes Thumshirn wrote:
> On Tue, Mar 07, 2017 at 04:35:11PM -0500, Linda Knippers wrote:
>> The first two patches in this series are motivated by feedback
>> from distribution developers, test engineers, and management tool
>> developers. We need the ability to test and support Linux and
>> management tools on systems that support more than one DSM family
>> for NVDIMM-N.
>>
>> We also need the ability to test and support new functions without
>> requiring users to update their kernel. These changes will also
>> facilate development as we move toward DSM standardization.
>> The ability to restrict DSM functions to the currently documented
>> set is still in place.
>>
>> The third patch cleans up a cosmetic/modinfo parsing issue with one
>> of the existing module parameters.
>
> Hi Linda and Dan,
>
> Can you tell me the status of this series? I haven't seen it in Dan's
> tree and can't remember a reason why it's not merged.
I assume/hope it's just waiting for the next merge window.
At this point I think Dan is just pulling in critical fixes.
If there's some other reason, I'd like to hear about it too.
OK.
Dan is it possible to do a for-next branch or a for-4.12 branch?
That'll make my life a _much_ easier.
Thanks,
Johanens
--
Johannes Thumshirn Storage
jthumshirn(a)suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
6:54 a.m.
On Fri, Mar 31, 2017 at 6:31 AM, Johannes Thumshirn <jthumshirn(a)suse.de> wrote:
On Fri, Mar 31, 2017 at 09:19:17AM -0400, Linda Knippers wrote:
> On 03/31/2017 05:01 AM, Johannes Thumshirn wrote:
> > On Tue, Mar 07, 2017 at 04:35:11PM -0500, Linda Knippers wrote:
> >> The first two patches in this series are motivated by feedback
> >> from distribution developers, test engineers, and management tool
> >> developers. We need the ability to test and support Linux and
> >> management tools on systems that support more than one DSM family
> >> for NVDIMM-N.
> >>
> >> We also need the ability to test and support new functions without
> >> requiring users to update their kernel. These changes will also
> >> facilate development as we move toward DSM standardization.
> >> The ability to restrict DSM functions to the currently documented
> >> set is still in place.
> >>
> >> The third patch cleans up a cosmetic/modinfo parsing issue with one
> >> of the existing module parameters.
> >
> > Hi Linda and Dan,
> >
> > Can you tell me the status of this series? I haven't seen it in Dan's
> > tree and can't remember a reason why it's not merged.
>
> I assume/hope it's just waiting for the next merge window.
> At this point I think Dan is just pulling in critical fixes.
> If there's some other reason, I'd like to hear about it too.
OK.
Dan is it possible to do a for-next branch or a for-4.12 branch?
That'll make my life a _much_ easier.
Yes, it's queued. I had been holding back updating my for-next branch
while debugging some test regressions in other for-4.12 patches.
However, I'll just kick those other patches out of the branch and post
these. Thanks for the nudge.
6:58 a.m.
On Fri, Mar 31, 2017 at 06:54:13AM -0700, Dan Williams wrote:
Yes, it's queued. I had been holding back updating my for-next
branch
while debugging some test regressions in other for-4.12 patches.
However, I'll just kick those other patches out of the branch and post
these. Thanks for the nudge.
Thanks a lot.
Joahnnes
--
Johannes Thumshirn Storage
jthumshirn(a)suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
1391
days inactive
1415
days old
8 comments
3 participants
participants (3)
-
Dan Williams -
Johannes Thumshirn -
Linda Knippers