All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Verma, Vishal L" <vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Williams,
	Dan J" <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org"
	<ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	"oceanhehy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<oceanhehy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Jiang,
	Dave" <dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org"
	<hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org>,
	"rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org"
	<rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
Cc: "linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>
Subject: Re: [External]  Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at startup
Date: Mon, 6 Aug 2018 17:18:38 +0000	[thread overview]
Message-ID: <1533575914.25865.2.camel@intel.com> (raw)
In-Reply-To: <HK0PR03MB3170E6D5D62D14B02F39FAE089200-7SfLTKn9UgQizmvzqrKYQ682SN/2zMuYvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>

On Mon, 2018-08-06 at 07:15 +0000, Ocean HY1 He wrote:
> > -----Original Message-----
> > From: Verma, Vishal L <vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Sent: Saturday, August 04, 2018 1:12 AM
> > To: Williams, Dan J <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org;
> > oceanhehy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Jiang, Dave <dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
> > rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org
> > Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org; linux-
> > acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Ocean HY1 He <hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org>
> > Subject: [External] Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at
> > startup
> > 
> > 
> > On Fri, 2018-08-03 at 05:39 -0400, Ocean He wrote:
> > > From: Ocean He <hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org>
> > > 
> > > In the beginning of acpi_nfit_add, if fail to find NFIT table then
> > > should
> > > return -ENODEV, instead of 0.
> > > 
> > > Signed-off-by: Ocean He <hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org>
> > > ---
> > >  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 7c47900..1790d7c 100644
> > > --- a/drivers/acpi/nfit/core.c
> > > +++ b/drivers/acpi/nfit/core.c
> > > @@ -3355,7 +3355,7 @@ static int acpi_nfit_add(struct acpi_device
> > > *adev)
> > >  	if (ACPI_FAILURE(status)) {
> > >  		/* This is ok, we could have an nvdimm hotplugged
> > > later */
> > >  		dev_dbg(dev, "failed to find NFIT at startup\n");
> > > -		return 0;
> > > +		return -ENODEV;
> > 
> > Hm, the comment directly above this says this is ok..
> > Has this caused any problems in practice?
> > 
> 
> Thanks for your comments. After going through related codes and some test, I am 
> now thinking it's right to keep "return 0" if NFIT not found at boot time.
> 
> Per chapter 9.20.2 NVDIMM Root Device in ACPI 6.2 spec:
> The NVDIMM root device is represented by an ACPI namespace device with a _HID 
> of "ACPI0012". This device allows the OS to trigger enumeration of NVDIMMs 
> through NFIT at boot time and re-enumeration at root level via the _FIT method 
> during runtime. 
> 
> The acpi_nfit_driver is registered to ACPI bus to support "ACPI0012". 
> The acpi_nfit_driver.acpi_nfit_add is used to enumerate NVDIMMs through NFIT 
> at boot time; The acpi_nfit_driver.acpi_nfit_notify is used to enumerate 
> NVDIMMs during runtime.
> 
> In my Lenovo ThinkSystem SR630 which support NVDIMMs, If I remove 
> all NVDIMMs, the NFIT table is gone after system boot up. If keep "return 0" 
> in acpi_nfit_add, then acpi_nfit_driver would still be attached to "ACPI0012". 
> Once a NVDIMM is hotplugged into system during runtime, then 
> acpi_nfit_driver.acpi_nfit_notify can be called to enumerate NVDIMMs (I could
> not do hotplug test because firmware doesn't support). 
> Otherwise, "return -ENODEV" would block NVDIMM enumeration during runtime.
> 
> How do you think to adjust annotation as following?
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 7c47900..1673161 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -3353,7 +3353,13 @@ static int acpi_nfit_add(struct acpi_device *adev)
>  
>         status = acpi_get_table(ACPI_SIG_NFIT, 0, &tbl);
>         if (ACPI_FAILURE(status)) {
> -               /* This is ok, we could have an nvdimm hotplugged later */
> +               /* The NVDIMM root device allows OS to trigger enumeration of 
> +                * NVDIMMs through NFIT at boot time and re-enumeration at 
> +                * root level via the _FIT method during runtime.
> +                * This is ok to return 0 here, we could have an nvdimm 
> +                * hotplugged later and evaluate _FIT method which returns 
> +                * data in the format of a series of NFIT Structures.
> +                */
>                 dev_dbg(dev, "failed to find NFIT at startup\n");
>                 return 0;
>         }

Yes, this sounds reasonable to me.

Thanks,
	-Vishal

> 
> Ocean.
> 
> > >  	}
> > > 
> > >  	rc = devm_add_action_or_reset(dev, acpi_nfit_put_table,
> > > tbl);

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"oceanhehy@gmail.com" <oceanhehy@gmail.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"hehy1@lenovo.com" <hehy1@lenovo.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [External]  Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at startup
Date: Mon, 6 Aug 2018 17:18:38 +0000	[thread overview]
Message-ID: <1533575914.25865.2.camel@intel.com> (raw)
In-Reply-To: <HK0PR03MB3170E6D5D62D14B02F39FAE089200@HK0PR03MB3170.apcprd03.prod.outlook.com>

On Mon, 2018-08-06 at 07:15 +0000, Ocean HY1 He wrote:
> > -----Original Message-----
> > From: Verma, Vishal L <vishal.l.verma@intel.com>
> > Sent: Saturday, August 04, 2018 1:12 AM
> > To: Williams, Dan J <dan.j.williams@intel.com>; ross.zwisler@linux.intel.com;
> > oceanhehy@gmail.com; Jiang, Dave <dave.jiang@intel.com>; lenb@kernel.org;
> > rjw@rjwysocki.net
> > Cc: linux-kernel@vger.kernel.org; linux-nvdimm@lists.01.org; linux-
> > acpi@vger.kernel.org; Ocean HY1 He <hehy1@lenovo.com>
> > Subject: [External] Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at
> > startup
> > 
> > 
> > On Fri, 2018-08-03 at 05:39 -0400, Ocean He wrote:
> > > From: Ocean He <hehy1@lenovo.com>
> > > 
> > > In the beginning of acpi_nfit_add, if fail to find NFIT table then
> > > should
> > > return -ENODEV, instead of 0.
> > > 
> > > Signed-off-by: Ocean He <hehy1@lenovo.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 7c47900..1790d7c 100644
> > > --- a/drivers/acpi/nfit/core.c
> > > +++ b/drivers/acpi/nfit/core.c
> > > @@ -3355,7 +3355,7 @@ static int acpi_nfit_add(struct acpi_device
> > > *adev)
> > >  	if (ACPI_FAILURE(status)) {
> > >  		/* This is ok, we could have an nvdimm hotplugged
> > > later */
> > >  		dev_dbg(dev, "failed to find NFIT at startup\n");
> > > -		return 0;
> > > +		return -ENODEV;
> > 
> > Hm, the comment directly above this says this is ok..
> > Has this caused any problems in practice?
> > 
> 
> Thanks for your comments. After going through related codes and some test, I am 
> now thinking it's right to keep "return 0" if NFIT not found at boot time.
> 
> Per chapter 9.20.2 NVDIMM Root Device in ACPI 6.2 spec:
> The NVDIMM root device is represented by an ACPI namespace device with a _HID 
> of "ACPI0012". This device allows the OS to trigger enumeration of NVDIMMs 
> through NFIT at boot time and re-enumeration at root level via the _FIT method 
> during runtime. 
> 
> The acpi_nfit_driver is registered to ACPI bus to support "ACPI0012". 
> The acpi_nfit_driver.acpi_nfit_add is used to enumerate NVDIMMs through NFIT 
> at boot time; The acpi_nfit_driver.acpi_nfit_notify is used to enumerate 
> NVDIMMs during runtime.
> 
> In my Lenovo ThinkSystem SR630 which support NVDIMMs, If I remove 
> all NVDIMMs, the NFIT table is gone after system boot up. If keep "return 0" 
> in acpi_nfit_add, then acpi_nfit_driver would still be attached to "ACPI0012". 
> Once a NVDIMM is hotplugged into system during runtime, then 
> acpi_nfit_driver.acpi_nfit_notify can be called to enumerate NVDIMMs (I could
> not do hotplug test because firmware doesn't support). 
> Otherwise, "return -ENODEV" would block NVDIMM enumeration during runtime.
> 
> How do you think to adjust annotation as following?
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 7c47900..1673161 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -3353,7 +3353,13 @@ static int acpi_nfit_add(struct acpi_device *adev)
>  
>         status = acpi_get_table(ACPI_SIG_NFIT, 0, &tbl);
>         if (ACPI_FAILURE(status)) {
> -               /* This is ok, we could have an nvdimm hotplugged later */
> +               /* The NVDIMM root device allows OS to trigger enumeration of 
> +                * NVDIMMs through NFIT at boot time and re-enumeration at 
> +                * root level via the _FIT method during runtime.
> +                * This is ok to return 0 here, we could have an nvdimm 
> +                * hotplugged later and evaluate _FIT method which returns 
> +                * data in the format of a series of NFIT Structures.
> +                */
>                 dev_dbg(dev, "failed to find NFIT at startup\n");
>                 return 0;
>         }

Yes, this sounds reasonable to me.

Thanks,
	-Vishal

> 
> Ocean.
> 
> > >  	}
> > > 
> > >  	rc = devm_add_action_or_reset(dev, acpi_nfit_put_table,
> > > tbl);
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"oceanhehy@gmail.com" <oceanhehy@gmail.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"hehy1@lenovo.com" <hehy1@lenovo.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [External]  Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at startup
Date: Mon, 6 Aug 2018 17:18:38 +0000	[thread overview]
Message-ID: <1533575914.25865.2.camel@intel.com> (raw)
In-Reply-To: <HK0PR03MB3170E6D5D62D14B02F39FAE089200@HK0PR03MB3170.apcprd03.prod.outlook.com>

On Mon, 2018-08-06 at 07:15 +0000, Ocean HY1 He wrote:
> > -----Original Message-----
> > From: Verma, Vishal L <vishal.l.verma@intel.com>
> > Sent: Saturday, August 04, 2018 1:12 AM
> > To: Williams, Dan J <dan.j.williams@intel.com>; ross.zwisler@linux.intel.com;
> > oceanhehy@gmail.com; Jiang, Dave <dave.jiang@intel.com>; lenb@kernel.org;
> > rjw@rjwysocki.net
> > Cc: linux-kernel@vger.kernel.org; linux-nvdimm@lists.01.org; linux-
> > acpi@vger.kernel.org; Ocean HY1 He <hehy1@lenovo.com>
> > Subject: [External] Re: [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at
> > startup
> > 
> > 
> > On Fri, 2018-08-03 at 05:39 -0400, Ocean He wrote:
> > > From: Ocean He <hehy1@lenovo.com>
> > > 
> > > In the beginning of acpi_nfit_add, if fail to find NFIT table then
> > > should
> > > return -ENODEV, instead of 0.
> > > 
> > > Signed-off-by: Ocean He <hehy1@lenovo.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 7c47900..1790d7c 100644
> > > --- a/drivers/acpi/nfit/core.c
> > > +++ b/drivers/acpi/nfit/core.c
> > > @@ -3355,7 +3355,7 @@ static int acpi_nfit_add(struct acpi_device
> > > *adev)
> > >  	if (ACPI_FAILURE(status)) {
> > >  		/* This is ok, we could have an nvdimm hotplugged
> > > later */
> > >  		dev_dbg(dev, "failed to find NFIT at startup\n");
> > > -		return 0;
> > > +		return -ENODEV;
> > 
> > Hm, the comment directly above this says this is ok..
> > Has this caused any problems in practice?
> > 
> 
> Thanks for your comments. After going through related codes and some test, I am 
> now thinking it's right to keep "return 0" if NFIT not found at boot time.
> 
> Per chapter 9.20.2 NVDIMM Root Device in ACPI 6.2 spec:
> The NVDIMM root device is represented by an ACPI namespace device with a _HID 
> of "ACPI0012". This device allows the OS to trigger enumeration of NVDIMMs 
> through NFIT at boot time and re-enumeration at root level via the _FIT method 
> during runtime. 
> 
> The acpi_nfit_driver is registered to ACPI bus to support "ACPI0012". 
> The acpi_nfit_driver.acpi_nfit_add is used to enumerate NVDIMMs through NFIT 
> at boot time; The acpi_nfit_driver.acpi_nfit_notify is used to enumerate 
> NVDIMMs during runtime.
> 
> In my Lenovo ThinkSystem SR630 which support NVDIMMs, If I remove 
> all NVDIMMs, the NFIT table is gone after system boot up. If keep "return 0" 
> in acpi_nfit_add, then acpi_nfit_driver would still be attached to "ACPI0012". 
> Once a NVDIMM is hotplugged into system during runtime, then 
> acpi_nfit_driver.acpi_nfit_notify can be called to enumerate NVDIMMs (I could
> not do hotplug test because firmware doesn't support). 
> Otherwise, "return -ENODEV" would block NVDIMM enumeration during runtime.
> 
> How do you think to adjust annotation as following?
> 
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 7c47900..1673161 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -3353,7 +3353,13 @@ static int acpi_nfit_add(struct acpi_device *adev)
>  
>         status = acpi_get_table(ACPI_SIG_NFIT, 0, &tbl);
>         if (ACPI_FAILURE(status)) {
> -               /* This is ok, we could have an nvdimm hotplugged later */
> +               /* The NVDIMM root device allows OS to trigger enumeration of 
> +                * NVDIMMs through NFIT at boot time and re-enumeration at 
> +                * root level via the _FIT method during runtime.
> +                * This is ok to return 0 here, we could have an nvdimm 
> +                * hotplugged later and evaluate _FIT method which returns 
> +                * data in the format of a series of NFIT Structures.
> +                */
>                 dev_dbg(dev, "failed to find NFIT at startup\n");
>                 return 0;
>         }

Yes, this sounds reasonable to me.

Thanks,
	-Vishal

> 
> Ocean.
> 
> > >  	}
> > > 
> > >  	rc = devm_add_action_or_reset(dev, acpi_nfit_put_table,
> > > tbl);

  parent reply	other threads:[~2018-08-06 17:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-03  9:39 [PATCH] ACPI: nfit: return -ENODEV if fail to find NFIT at startup Ocean He
2018-08-03  9:39 ` Ocean He
2018-08-03  9:39 ` Ocean He
     [not found] ` <1533289198-11400-1-git-send-email-oceanhehy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-08-03  9:43   ` Johannes Thumshirn
2018-08-03  9:43     ` Johannes Thumshirn
2018-08-03  9:43     ` Johannes Thumshirn
2018-08-03 17:11   ` Verma, Vishal L
2018-08-03 17:11     ` Verma, Vishal L
2018-08-03 17:11     ` Verma, Vishal L
     [not found]     ` <1533316299.8557.71.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-08-06  7:15       ` [External] " Ocean HY1 He
2018-08-06  7:15         ` Ocean HY1 He
2018-08-06  7:15         ` Ocean HY1 He
     [not found]         ` <HK0PR03MB3170E6D5D62D14B02F39FAE089200-7SfLTKn9UgQizmvzqrKYQ682SN/2zMuYvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-08-06 17:18           ` Verma, Vishal L [this message]
2018-08-06 17:18             ` Verma, Vishal L
2018-08-06 17:18             ` Verma, Vishal L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1533575914.25865.2.camel@intel.com \
    --to=vishal.l.verma-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=hehy1-6jq1YtArVR3QT0dZR+AlfA@public.gmane.org \
    --cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
    --cc=oceanhehy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.