@@ -1131,11 +1131,11 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
/*
* Until standardization materializes we need to consider up to 3
- * different command sets. Note, that checking for zero functions
- * tells us if any commands might be reachable through this uuid.
+ * different command sets. Note, that checking for function0 (bit0)
+ * tells us if any commands are reachable through this uuid.
*/
for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_HPE2; i++)
- if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 0))
+ if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
break;
/* limit the supported commands to those that are publicly documented */
@@ -1151,9 +1151,10 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc,
if (disable_vendor_specific)
dsm_mask &= ~(1 << 8);
} else {
- dev_err(dev, "unknown dimm command family\n");
+ dev_dbg(dev, "unknown dimm command family\n");
nfit_mem->family = -1;
- return force_enable_dimms ? 0 : -ENODEV;
+ /* DSMs are optional, continue loading the driver... */
+ return 0;
}
uuid = to_nfit_uuid(nfit_mem->family);
@@ -680,6 +680,9 @@ bool acpi_check_dsm(acpi_handle handle, const u8 *uuid, u64 rev, u64 funcs)
u64 mask = 0;
union acpi_object *obj;
+ if (funcs == 0)
+ return false;
+
obj = acpi_evaluate_dsm(handle, uuid, rev, 0, NULL);
if (!obj)
return false;
@@ -692,9 +695,6 @@ bool acpi_check_dsm(acpi_handle handle, const u8 *uuid, u64 rev, u64 funcs)
mask |= (((u64)obj->buffer.pointer[i]) << (i * 8));
ACPI_FREE(obj);
- if (funcs == 0)
- return true;
-
/*
* Bit 0 indicates whether there's support for any functions other than
* function 0 for the specified UUID and revision.
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a regression fix for a problem that was introduced in v4.7-rc6. In 4.7-rc1 we introduced auto-probing for the ACPI DSM (device- specific-method) format that the platform firmware implements for nvdimm devices. We initially fixed a regression in probing the QEMU DSM implementation by making acpi_check_dsm() tolerant of the way QEMU reports the "0 DSMs supported" condition. However, that broke HPE platforms since that tolerance caused the driver to mistakenly match the 1-zero-byte response those platforms give to "unknown" commands. Instead, we simply make the driver tolerant of not finding any supported DSMs. This has been tested to work with both QEMU and HPE platforms. This commit has appeared in a -next release with no reported issues. The following changes since commit a99cde438de0c4c0cecc1d1af1a55a75b10bfdef: Linux 4.7-rc6 (2016-07-03 23:01:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes for you to fetch changes up to a72255983f12f31f0c8d8275fb1a781546cfacb7: nfit: make DIMM DSMs optional (2016-07-19 12:32:39 -0700) ---------------------------------------------------------------- Dan Williams (1): nfit: make DIMM DSMs optional drivers/acpi/nfit.c | 11 ++++++----- drivers/acpi/utils.c | 6 +++--- 2 files changed, 9 insertions(+), 8 deletions(-) commit a72255983f12f31f0c8d8275fb1a781546cfacb7 Author: Dan Williams <dan.j.williams@intel.com> Date: Tue Jul 19 12:32:39 2016 -0700 nfit: make DIMM DSMs optional Commit 4995734e973a "acpi, nfit: fix acpi_check_dsm() vs zero functions implemented" attempted to fix a QEMU regression by supporting its usage of a zero-mask as a valid response to a DSM-family probe request. However, this behavior breaks HP platforms that return a zero-mask by default causing the probe to misidentify the DSM-family. Instead, the QEMU regression can be fixed by simply not requiring the DSM family to be identified. This effectively reverts commit 4995734e973a, and removes the DSM requirement from the init path. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com> Cc: Linda Knippers <linda.knippers@hpe.com> Fixes: 4995734e973a ("acpi, nfit: fix acpi_check_dsm() vs zero functions implemented") Reported-by: Jerry Hoemann <jerry.hoemann@hpe.com> Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>