[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <154751742416.1617064.8252289468130584022.stgit@dwillia2-desk3.amr.corp.intel.com>
Date: Mon, 14 Jan 2019 17:57:04 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: linux-nvdimm@...ts.01.org
Cc: stable@...r.kernel.org, stuart hayes <stuart.w.hayes@...il.com>,
Sujith Pandel <sujith_pandel@...l.com>,
Jeff Moyer <jmoyer@...hat.com>,
Vishal Verma <vishal.l.verma@...el.com>,
linux-kernel@...r.kernel.org, vishal.l.verma@...el.com
Subject: [PATCH v2 0/2] acpi/nfit: Fix command-supported detection
Changes since v1 [1]:
* Include another patch make sure that function-number zero can be
safely used as an invalid function number (Jeff)
* Add a comment clarifying why zero is an invalid function number (Jeff)
* Pass nfit_mem to cmd_to_func() (Jeff)
* Collect a Tested-by from Sujith
[1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019435.html
---
Quote patch2 changelog:
The _DSM function number validation only happens to succeed when the
generic Linux command number translation corresponds with a
DSM-family-specific function number. This breaks NVDIMM-N
implementations that correctly implement _LSR, _LSW, and _LSI, but do
not happen to publish support for DSM function numbers 4, 5, and 6.
Recall that the support for _LS{I,R,W} family of methods results in the
DIMM being marked as supporting those command numbers at
acpi_nfit_register_dimms() time. The DSM function mask is only used for
ND_CMD_CALL support of non-NVDIMM_FAMILY_INTEL devices.
---
Dan Williams (2):
acpi/nfit: Block function zero DSMs
acpi/nfit: Fix command-supported detection
drivers/acpi/nfit/core.c | 53 ++++++++++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 14 deletions(-)
Powered by blists - more mailing lists