diff mbox

[1/2] : nfit: Clarify memory device state flags strings

Message ID 1440606024-29873-2-git-send-email-toshi.kani@hp.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Toshi Kani Aug. 26, 2015, 4:20 p.m. UTC 
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(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Ross Zwisler Aug. 27, 2015, 3:07 a.m. UTC | #1 
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Toshi Kani Aug. 27, 2015, 2:18 p.m. UTC | #2 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dan Williams Aug. 27, 2015, 6:57 p.m. UTC | #3 
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Toshi Kani Aug. 27, 2015, 7:02 p.m. UTC | #4 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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 " : "");
 
 	}