| Message ID | 1440606024-29873-2-git-send-email-toshi.kani@hp.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, Aug 26, 2015 at 10:20:23AM -0600, Toshi Kani wrote: > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c > index c3fe206..6993ff2 100644 > --- a/drivers/acpi/nfit.c > +++ b/drivers/acpi/nfit.c > @@ -701,12 +701,13 @@ static ssize_t flags_show(struct device *dev, > { > u16 flags = to_nfit_memdev(dev)->flags; > > - return sprintf(buf, "%s%s%s%s%s\n", > - flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "", > - flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " : "", > - flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "", > - flags & ACPI_NFIT_MEM_ARMED ? "arm " : "", > - flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart " : ""); > + return sprintf(buf, "%s%s%s%s%s%s\n", > + flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "", > + flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "", > + flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "", > + flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : "", Assuming we do want to update these strings to be more friendly, "not_armed" probably makes more sense than "not_arm". Also applies to the 2nd hunk below. > + flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "", > + flags & ACPI_NFIT_MEM_HEALTH_ENABLED ? "notify_enabled " : ""); > } > static DEVICE_ATTR_RO(flags); > > @@ -834,11 +835,11 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc) > continue; > > dev_info(acpi_desc->dev, "%s: failed: %s%s%s%s\n", > - nvdimm_name(nvdimm), > - mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "", > - mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " : "", > - mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "", > - mem_flags & ACPI_NFIT_MEM_ARMED ? "arm " : ""); > + nvdimm_name(nvdimm), > + mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "", > + mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail ":"", > + mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "", > + mem_flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : ""); While you're in here, is there a reason not to include the last two flags (smart_event and notify_enabled) in this dev_info() output?
On Wed, 2015-08-26 at 21:07 -0600, Ross Zwisler wrote: > On Wed, Aug 26, 2015 at 10:20:23AM -0600, Toshi Kani wrote: > > diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c > > index c3fe206..6993ff2 100644 > > --- a/drivers/acpi/nfit.c > > +++ b/drivers/acpi/nfit.c > > @@ -701,12 +701,13 @@ static ssize_t flags_show(struct device *dev, > > { > > u16 flags = to_nfit_memdev(dev)->flags; > > > > - return sprintf(buf, "%s%s%s%s%s\n", > > - flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : > > "", > > - flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore > > " : "", > > - flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : > > "", > > - flags & ACPI_NFIT_MEM_ARMED ? "arm " : "", > > - flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart > > " : ""); > > + return sprintf(buf, "%s%s%s%s%s%s\n", > > + flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "", > > + flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " > > : "", > > + flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : > > "", > > + flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : "", > > Assuming we do want to update these strings to be more friendly, > "not_armed" probably makes more sense than "not_arm". Also applies to the > 2nd hunk below. Agreed. (Will update if this patch gets ever resurrected. :-) > > + flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " > > : "", > > + flags & ACPI_NFIT_MEM_HEALTH_ENABLED ? "notify_enabled > > " : ""); > > } > > static DEVICE_ATTR_RO(flags); > > > > @@ -834,11 +835,11 @@ static int acpi_nfit_register_dimms(struct > > acpi_nfit_desc *acpi_desc) > > continue; > > > > dev_info(acpi_desc->dev, "%s: failed: %s%s%s%s\n", > > - nvdimm_name(nvdimm), > > - mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " > > : "", > > - mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? > > "restore " : "", > > - mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush > > " : "", > > - mem_flags & ACPI_NFIT_MEM_ARMED ? "arm " : ""); > > + nvdimm_name(nvdimm), > > + mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " > > : "", > > + mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? > > "restore_fail ":"", > > + mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail > > " : "", > > + mem_flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : ""); > > While you're in here, is there a reason not to include the last two flags > (smart_event and notify_enabled) in this dev_info() output? This dev_info() logs any failure in NVDIMM, and the last two flags are not failure conditions. Thanks, -Toshi
On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani <toshi.kani@hp.com> wrote: > ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines > NVDIMM status as follows. These bits indicate multiple info, > such as failures, pending event, and capability. > > Bit [0] set to 1 to indicate that the previous SAVE to the > Memory Device failed. > Bit [1] set to 1 to indicate that the last RESTORE from the > Memory Device failed. > Bit [2] set to 1 to indicate that platform flush of data to > Memory Device failed. As a result, the restored data content > may be inconsistent even if SAVE and RESTORE do not indicate > failure. > Bit [3] set to 1 to indicate that the Memory Device is observed > to be not armed prior to OSPM hand off. A Memory Device is > considered armed if it is able to accept persistent writes. > Bit [4] set to 1 to indicate that the Memory Device observed > SMART and health events prior to OSPM handoff. > Bit [5] is set to 1 to indicate that platform firmware is > enabled to notify OSPM on SMART and health events related to > the memory device using Notify codes as specified in Section > 5.6.6. > > /sys/bus/nd/devices/nmemX/nfit/flags shows this flags info. > The output strings associated with the bits are "save", "restore", > "smart", etc., which can be confusing as they may be interpreted > as positive status, i.e. save succeeded. > > Change the strings to be more descriptive per the ACPI spec. > Also add a string to bit 5 for completeness. Ok I'm going to push this upstream for 4.2 with the "not_armed" fixup that Ross suggested, but I'll defer adding bit5 since that is separate from the urgent fix to get the polarities properly reflected and we can add support for it later.
On Thu, 2015-08-27 at 11:57 -0700, Dan Williams wrote: > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani <toshi.kani@hp.com> wrote: > > ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines > > NVDIMM status as follows. These bits indicate multiple info, > > such as failures, pending event, and capability. > > > > Bit [0] set to 1 to indicate that the previous SAVE to the > > Memory Device failed. > > Bit [1] set to 1 to indicate that the last RESTORE from the > > Memory Device failed. > > Bit [2] set to 1 to indicate that platform flush of data to > > Memory Device failed. As a result, the restored data content > > may be inconsistent even if SAVE and RESTORE do not indicate > > failure. > > Bit [3] set to 1 to indicate that the Memory Device is observed > > to be not armed prior to OSPM hand off. A Memory Device is > > considered armed if it is able to accept persistent writes. > > Bit [4] set to 1 to indicate that the Memory Device observed > > SMART and health events prior to OSPM handoff. > > Bit [5] is set to 1 to indicate that platform firmware is > > enabled to notify OSPM on SMART and health events related to > > the memory device using Notify codes as specified in Section > > 5.6.6. > > > > /sys/bus/nd/devices/nmemX/nfit/flags shows this flags info. > > The output strings associated with the bits are "save", "restore", > > "smart", etc., which can be confusing as they may be interpreted > > as positive status, i.e. save succeeded. > > > > Change the strings to be more descriptive per the ACPI spec. > > Also add a string to bit 5 for completeness. > > Ok I'm going to push this upstream for 4.2 with the "not_armed" fixup > that Ross suggested, but I'll defer adding bit5 since that is separate > from the urgent fix to get the polarities properly reflected and we > can add support for it later. Great!! Thanks Dan! (and sorry for making more work to you...) -Toshi
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c index c3fe206..6993ff2 100644 --- a/drivers/acpi/nfit.c +++ b/drivers/acpi/nfit.c @@ -701,12 +701,13 @@ static ssize_t flags_show(struct device *dev, { u16 flags = to_nfit_memdev(dev)->flags; - return sprintf(buf, "%s%s%s%s%s\n", - flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "", - flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " : "", - flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "", - flags & ACPI_NFIT_MEM_ARMED ? "arm " : "", - flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart " : ""); + return sprintf(buf, "%s%s%s%s%s%s\n", + flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "", + flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "", + flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "", + flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : "", + flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "", + flags & ACPI_NFIT_MEM_HEALTH_ENABLED ? "notify_enabled " : ""); } static DEVICE_ATTR_RO(flags); @@ -834,11 +835,11 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc) continue; dev_info(acpi_desc->dev, "%s: failed: %s%s%s%s\n", - nvdimm_name(nvdimm), - mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "", - mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " : "", - mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "", - mem_flags & ACPI_NFIT_MEM_ARMED ? "arm " : ""); + nvdimm_name(nvdimm), + mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "", + mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail ":"", + mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "", + mem_flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : ""); }
ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines NVDIMM status as follows. These bits indicate multiple info, such as failures, pending event, and capability. Bit [0] set to 1 to indicate that the previous SAVE to the Memory Device failed. Bit [1] set to 1 to indicate that the last RESTORE from the Memory Device failed. Bit [2] set to 1 to indicate that platform flush of data to Memory Device failed. As a result, the restored data content may be inconsistent even if SAVE and RESTORE do not indicate failure. Bit [3] set to 1 to indicate that the Memory Device is observed to be not armed prior to OSPM hand off. A Memory Device is considered armed if it is able to accept persistent writes. Bit [4] set to 1 to indicate that the Memory Device observed SMART and health events prior to OSPM handoff. Bit [5] is set to 1 to indicate that platform firmware is enabled to notify OSPM on SMART and health events related to the memory device using Notify codes as specified in Section 5.6.6. /sys/bus/nd/devices/nmemX/nfit/flags shows this flags info. The output strings associated with the bits are "save", "restore", "smart", etc., which can be confusing as they may be interpreted as positive status, i.e. save succeeded. Change the strings to be more descriptive per the ACPI spec. Also add a string to bit 5 for completeness. Change also the dev_info() message in acpi_nfit_register_dimms() to be consistent with the sysfs flags strings. Reported-by: Robert Elliott <elliott@hp.com> Signed-off-by: Toshi Kani <toshi.kani@hp.com> Cc: Dan Williams <dan.j.williams@intel.com> --- drivers/acpi/nfit.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)