On Mon, Dec 5, 2016 at 1:27 PM, Vishal Verma <vishal.l.ve...@intel.com> wrote: > ACPI DSMs can have an 'extended' status which can be non-zero to convey > additional information about the command. In the xlat_status routine, > where we translate the command statuses, we were returning an error for > a non-zero extended status, even if the primary status indicated success. > > Cc: Dan Williams <dan.j.willi...@intel.com> > Signed-off-by: Vishal Verma <vishal.l.ve...@intel.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 71a7d07..d14f09b 100644 > --- a/drivers/acpi/nfit/core.c > +++ b/drivers/acpi/nfit/core.c > @@ -169,7 +169,7 @@ static int xlat_status(void *buf, unsigned int cmd, u32 > status) > } > > /* all other non-zero status results in an error */ > - if (status) > + if (status & 0xffff) > return -EIO;
I don't think this is right, because we have no idea at this point whether extended status is fatal or not. Each 'case' statement in that 'switch' should be returning 0 if it does not see any errors. Because that's the only part of the function with per-command knowledge of extended being benign / informational vs fatal. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
