Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value. Also
add some detailed debug info when acpi_evaluate_object() failed.
Reviewed-by: Jani Nikula <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Yijing Wang <[email protected]>
---
v4->v5: Add some detailed debug info for acpi_evaluate_object()
failure suggested by Bjorn.
v3->v4: Fix spell error, add Jani Nikula reviewed-by.
v2->v3: Fix compile error pointed out by Hanjun.
v1->v2: Add CC to related subsystem MAINTAINERS
---
drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
drivers/pci/pci-label.c | 10 +++++--
4 files changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..e7b526b 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
static int intel_dsm(acpi_handle handle, int func)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
u32 result;
- int ret = 0;
+ acpi_status status;
+ int ret;
input.count = 4;
input.pointer = params;
@@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
params[3].package.count = 0;
params[3].package.elements = NULL;
- ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
- if (ret) {
- DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
- return ret;
+ status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
+ DRM_DEBUG_DRIVER(
+ "failed to evaluate _DSM for %s, exit status %u\n",
+ (char *)string.pointer, (unsigned int)status);
+ kfree(string.pointer);
+ return -EINVAL;
}
obj = (union acpi_object *)output.pointer;
@@ -138,10 +144,12 @@ static char *intel_dsm_mux_type(u8 type)
static void intel_dsm_platform_mux_info(void)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *pkg;
- int i, ret;
+ acpi_status status;
+ int i;
input.count = 4;
input.pointer = params;
@@ -156,10 +164,15 @@ static void intel_dsm_platform_mux_info(void)
params[3].package.count = 0;
params[3].package.elements = NULL;
- ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
- &output);
- if (ret) {
- DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
+ acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
+ "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(intel_dsm_priv.dhandle,
+ ACPI_FULL_PATHNAME, &string);
+ DRM_DEBUG_DRIVER(
+ "failed to evaluate _DSM for %s, exit status %u\n",
+ (char *)string.pointer, (unsigned int)status);
+ kfree(string.pointer);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
index 1291204..c30ee88 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
@@ -112,17 +112,22 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
};
struct acpi_object_list list = { ARRAY_SIZE(args), args };
struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_handle handle;
- int ret;
+ acpi_status status;
handle = ACPI_HANDLE(&device->pdev->dev);
if (!handle)
return false;
- ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
- if (ret) {
- nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
+ status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
+ nv_debug(mxm, "DSM MXMS failed for %s: exit status %u\n",
+ (char *)string.pointer,
+ (unsigned int)status);
+ kfree(string.pointer);
return false;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index ba0183f..53d24a7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
- int i, err;
+ acpi_status status;
+ int i;
char args_buff[4];
input.count = 4;
@@ -101,10 +102,12 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *
args_buff[i] = (arg >> i * 8) & 0xFF;
params[3].buffer.pointer = args_buff;
- err = acpi_evaluate_object(handle, "_DSM", &input, &output);
- if (err) {
- printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
- return err;
+ status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_info(handle,
+ "failed to evaluate _DSM, exit status %u\n",
+ (unsigned int)status);
+ return -EINVAL;
}
obj = (union acpi_object *)output.pointer;
@@ -134,7 +137,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
- int err;
+ acpi_status status;
input.count = 4;
input.pointer = params;
@@ -148,10 +151,12 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
params[3].type = ACPI_TYPE_INTEGER;
params[3].integer.value = arg;
- err = acpi_evaluate_object(handle, "_DSM", &input, &output);
- if (err) {
- printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
- return err;
+ status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_info(handle,
+ "failed to evaluate _DSM, exit status %u\n",
+ (unsigned int)status);
+ return -EINVAL;
}
obj = (union acpi_object *)output.pointer;
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index d51f45a..0216094 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -213,7 +213,7 @@ dsm_get_label(acpi_handle handle, int func,
union acpi_object *obj;
int len = 0;
- int err;
+ acpi_status status;
input.count = 4;
input.pointer = params;
@@ -228,9 +228,13 @@ dsm_get_label(acpi_handle handle, int func,
params[3].package.count = 0;
params[3].package.elements = NULL;
- err = acpi_evaluate_object(handle, "_DSM", &input, output);
- if (err)
+ status = acpi_evaluate_object(handle, "_DSM", &input, output);
+ if (ACPI_FAILURE(status)) {
+ acpi_handle_info(handle,
+ "failed to evaluate _DSM, exit status %u\n",
+ (unsigned int)status);
return -1;
+ }
obj = (union acpi_object *)output->pointer;
--
1.7.1
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value. Also
> add some detailed debug info when acpi_evaluate_object() failed.
>
> Reviewed-by: Jani Nikula <[email protected]>
> Acked-by: Bjorn Helgaas <[email protected]>
> Signed-off-by: Yijing Wang <[email protected]>
> ---
> v4->v5: Add some detailed debug info for acpi_evaluate_object()
> failure suggested by Bjorn.
> v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> v2->v3: Fix compile error pointed out by Hanjun.
> v1->v2: Add CC to related subsystem MAINTAINERS
> ---
> drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
> drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
> drivers/pci/pci-label.c | 10 +++++--
> 4 files changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
> index dfff090..e7b526b 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
> static int intel_dsm(acpi_handle handle, int func)
> {
> struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_object_list input;
> union acpi_object params[4];
> union acpi_object *obj;
> u32 result;
> - int ret = 0;
> + acpi_status status;
> + int ret;
>
> input.count = 4;
> input.pointer = params;
> @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
> params[3].package.count = 0;
> params[3].package.elements = NULL;
>
> - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> - return ret;
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
> + DRM_DEBUG_DRIVER(
> + "failed to evaluate _DSM for %s, exit status %u\n",
> + (char *)string.pointer, (unsigned int)status);
> + kfree(string.pointer);
> + return -EINVAL;
I said "too bad there isn't an *easy* way" to include more
information. IMHO this is too ugly and error-prone to use
consistently. And if you are going to add more information, why did
you only do it for some of the calls and not others?
I considered adding a %p extension to print the pathname; I don't know
if that's worthwhile or not. I think it would be ideal if we had a
struct device and could use dev_info(), and then a way to connect the
struct device with an ACPI path, like maybe a dmesg note when we
create the struct device corresponding to an ACPI Device node.
Bjorn
> }
>
> obj = (union acpi_object *)output.pointer;
> @@ -138,10 +144,12 @@ static char *intel_dsm_mux_type(u8 type)
> static void intel_dsm_platform_mux_info(void)
> {
> struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_object_list input;
> union acpi_object params[4];
> union acpi_object *pkg;
> - int i, ret;
> + acpi_status status;
> + int i;
>
> input.count = 4;
> input.pointer = params;
> @@ -156,10 +164,15 @@ static void intel_dsm_platform_mux_info(void)
> params[3].package.count = 0;
> params[3].package.elements = NULL;
>
> - ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
> - &output);
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> + acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
> + "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + acpi_get_name(intel_dsm_priv.dhandle,
> + ACPI_FULL_PATHNAME, &string);
> + DRM_DEBUG_DRIVER(
> + "failed to evaluate _DSM for %s, exit status %u\n",
> + (char *)string.pointer, (unsigned int)status);
> + kfree(string.pointer);
> goto out;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> index 1291204..c30ee88 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> @@ -112,17 +112,22 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
> };
> struct acpi_object_list list = { ARRAY_SIZE(args), args };
> struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
> + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> union acpi_object *obj;
> acpi_handle handle;
> - int ret;
> + acpi_status status;
>
> handle = ACPI_HANDLE(&device->pdev->dev);
> if (!handle)
> return false;
>
> - ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> - if (ret) {
> - nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
> + status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> + if (ACPI_FAILURE(status)) {
> + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
> + nv_debug(mxm, "DSM MXMS failed for %s: exit status %u\n",
> + (char *)string.pointer,
> + (unsigned int)status);
> + kfree(string.pointer);
> return false;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index ba0183f..53d24a7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *
> struct acpi_object_list input;
> union acpi_object params[4];
> union acpi_object *obj;
> - int i, err;
> + acpi_status status;
> + int i;
> char args_buff[4];
>
> input.count = 4;
> @@ -101,10 +102,12 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t *
> args_buff[i] = (arg >> i * 8) & 0xFF;
> params[3].buffer.pointer = args_buff;
>
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> - printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> - return err;
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + acpi_handle_info(handle,
> + "failed to evaluate _DSM, exit status %u\n",
> + (unsigned int)status);
> + return -EINVAL;
> }
>
> obj = (union acpi_object *)output.pointer;
> @@ -134,7 +137,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
> struct acpi_object_list input;
> union acpi_object params[4];
> union acpi_object *obj;
> - int err;
> + acpi_status status;
>
> input.count = 4;
> input.pointer = params;
> @@ -148,10 +151,12 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
> params[3].type = ACPI_TYPE_INTEGER;
> params[3].integer.value = arg;
>
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> - printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> - return err;
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + acpi_handle_info(handle,
> + "failed to evaluate _DSM, exit status %u\n",
> + (unsigned int)status);
> + return -EINVAL;
> }
>
> obj = (union acpi_object *)output.pointer;
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index d51f45a..0216094 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -213,7 +213,7 @@ dsm_get_label(acpi_handle handle, int func,
> union acpi_object *obj;
> int len = 0;
>
> - int err;
> + acpi_status status;
>
> input.count = 4;
> input.pointer = params;
> @@ -228,9 +228,13 @@ dsm_get_label(acpi_handle handle, int func,
> params[3].package.count = 0;
> params[3].package.elements = NULL;
>
> - err = acpi_evaluate_object(handle, "_DSM", &input, output);
> - if (err)
> + status = acpi_evaluate_object(handle, "_DSM", &input, output);
> + if (ACPI_FAILURE(status)) {
> + acpi_handle_info(handle,
> + "failed to evaluate _DSM, exit status %u\n",
> + (unsigned int)status);
> return -1;
> + }
>
> obj = (union acpi_object *)output->pointer;
>
> --
> 1.7.1
>
>
On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
> > Since acpi_evaluate_object() returns acpi_status and not plain int,
> > ACPI_FAILURE() should be used for checking its return value. Also
> > add some detailed debug info when acpi_evaluate_object() failed.
> >
> > Reviewed-by: Jani Nikula <[email protected]>
> > Acked-by: Bjorn Helgaas <[email protected]>
> > Signed-off-by: Yijing Wang <[email protected]>
> > ---
> > v4->v5: Add some detailed debug info for acpi_evaluate_object()
> > failure suggested by Bjorn.
> > v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> > v2->v3: Fix compile error pointed out by Hanjun.
> > v1->v2: Add CC to related subsystem MAINTAINERS
> > ---
> > drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
> > drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
> > drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
> > drivers/pci/pci-label.c | 10 +++++--
> > 4 files changed, 54 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
> > index dfff090..e7b526b 100644
> > --- a/drivers/gpu/drm/i915/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
> > @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
> > static int intel_dsm(acpi_handle handle, int func)
> > {
> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> > + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> > struct acpi_object_list input;
> > union acpi_object params[4];
> > union acpi_object *obj;
> > u32 result;
> > - int ret = 0;
> > + acpi_status status;
> > + int ret;
> >
> > input.count = 4;
> > input.pointer = params;
> > @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
> > params[3].package.count = 0;
> > params[3].package.elements = NULL;
> >
> > - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> > - if (ret) {
> > - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> > - return ret;
> > + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> > + if (ACPI_FAILURE(status)) {
> > + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
> > + DRM_DEBUG_DRIVER(
> > + "failed to evaluate _DSM for %s, exit status %u\n",
> > + (char *)string.pointer, (unsigned int)status);
> > + kfree(string.pointer);
> > + return -EINVAL;
>
> I said "too bad there isn't an *easy* way" to include more
> information. IMHO this is too ugly and error-prone to use
> consistently. And if you are going to add more information, why did
> you only do it for some of the calls and not others?
>
> I considered adding a %p extension to print the pathname; I don't know
> if that's worthwhile or not. I think it would be ideal if we had a
> struct device and could use dev_info(), and then a way to connect the
> struct device with an ACPI path, like maybe a dmesg note when we
> create the struct device corresponding to an ACPI Device node.
Well, we can generally print something like that from pci_acpi_setup().
What about the below? Wouldn't it generate too much output on some systems?
Rafael
---
drivers/pci/pci-acpi.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-pm/drivers/pci/pci-acpi.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -330,6 +330,8 @@ static void pci_acpi_setup(struct device
if (!adev)
return;
+ acpi_handle_info(adev->handle, "bound to %s\n", dev_name(dev));
+
pci_acpi_add_pm_notifier(adev, pci_dev);
if (!adev->wakeup.flags.valid)
return;
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
>> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> > ACPI_FAILURE() should be used for checking its return value. Also
>> > add some detailed debug info when acpi_evaluate_object() failed.
>> >
>> > Reviewed-by: Jani Nikula <[email protected]>
>> > Acked-by: Bjorn Helgaas <[email protected]>
>> > Signed-off-by: Yijing Wang <[email protected]>
>> > ---
>> > v4->v5: Add some detailed debug info for acpi_evaluate_object()
>> > failure suggested by Bjorn.
>> > v3->v4: Fix spell error, add Jani Nikula reviewed-by.
>> > v2->v3: Fix compile error pointed out by Hanjun.
>> > v1->v2: Add CC to related subsystem MAINTAINERS
>> > ---
>> > drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
>> > drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
>> > drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
>> > drivers/pci/pci-label.c | 10 +++++--
>> > 4 files changed, 54 insertions(+), 27 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
>> > index dfff090..e7b526b 100644
>> > --- a/drivers/gpu/drm/i915/intel_acpi.c
>> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
>> > @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
>> > static int intel_dsm(acpi_handle handle, int func)
>> > {
>> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
>> > + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
>> > struct acpi_object_list input;
>> > union acpi_object params[4];
>> > union acpi_object *obj;
>> > u32 result;
>> > - int ret = 0;
>> > + acpi_status status;
>> > + int ret;
>> >
>> > input.count = 4;
>> > input.pointer = params;
>> > @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
>> > params[3].package.count = 0;
>> > params[3].package.elements = NULL;
>> >
>> > - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> > - if (ret) {
>> > - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>> > - return ret;
>> > + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> > + if (ACPI_FAILURE(status)) {
>> > + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
>> > + DRM_DEBUG_DRIVER(
>> > + "failed to evaluate _DSM for %s, exit status %u\n",
>> > + (char *)string.pointer, (unsigned int)status);
>> > + kfree(string.pointer);
>> > + return -EINVAL;
>>
>> I said "too bad there isn't an *easy* way" to include more
>> information. IMHO this is too ugly and error-prone to use
>> consistently. And if you are going to add more information, why did
>> you only do it for some of the calls and not others?
>>
>> I considered adding a %p extension to print the pathname; I don't know
>> if that's worthwhile or not. I think it would be ideal if we had a
>> struct device and could use dev_info(), and then a way to connect the
>> struct device with an ACPI path, like maybe a dmesg note when we
>> create the struct device corresponding to an ACPI Device node.
>
> Well, we can generally print something like that from pci_acpi_setup().
>
> What about the below? Wouldn't it generate too much output on some systems?
Yeah, that probably would generate an awful lot of output. I was just
hoping to avoid treating ACPI pathnames as first-class objects. What
do you think about a %p extension? I played with that once, but I
seem to have lost the patch.
> ---
> drivers/pci/pci-acpi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-pm/drivers/pci/pci-acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-acpi.c
> +++ linux-pm/drivers/pci/pci-acpi.c
> @@ -330,6 +330,8 @@ static void pci_acpi_setup(struct device
> if (!adev)
> return;
>
> + acpi_handle_info(adev->handle, "bound to %s\n", dev_name(dev));
> +
> pci_acpi_add_pm_notifier(adev, pci_dev);
> if (!adev->wakeup.flags.valid)
> return;
>
On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
> >> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
> >> > Since acpi_evaluate_object() returns acpi_status and not plain int,
> >> > ACPI_FAILURE() should be used for checking its return value. Also
> >> > add some detailed debug info when acpi_evaluate_object() failed.
> >> >
> >> > Reviewed-by: Jani Nikula <[email protected]>
> >> > Acked-by: Bjorn Helgaas <[email protected]>
> >> > Signed-off-by: Yijing Wang <[email protected]>
> >> > ---
> >> > v4->v5: Add some detailed debug info for acpi_evaluate_object()
> >> > failure suggested by Bjorn.
> >> > v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> >> > v2->v3: Fix compile error pointed out by Hanjun.
> >> > v1->v2: Add CC to related subsystem MAINTAINERS
> >> > ---
> >> > drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
> >> > drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
> >> > drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
> >> > drivers/pci/pci-label.c | 10 +++++--
> >> > 4 files changed, 54 insertions(+), 27 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
> >> > index dfff090..e7b526b 100644
> >> > --- a/drivers/gpu/drm/i915/intel_acpi.c
> >> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
> >> > @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
> >> > static int intel_dsm(acpi_handle handle, int func)
> >> > {
> >> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> >> > + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> >> > struct acpi_object_list input;
> >> > union acpi_object params[4];
> >> > union acpi_object *obj;
> >> > u32 result;
> >> > - int ret = 0;
> >> > + acpi_status status;
> >> > + int ret;
> >> >
> >> > input.count = 4;
> >> > input.pointer = params;
> >> > @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
> >> > params[3].package.count = 0;
> >> > params[3].package.elements = NULL;
> >> >
> >> > - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> >> > - if (ret) {
> >> > - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> >> > - return ret;
> >> > + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> >> > + if (ACPI_FAILURE(status)) {
> >> > + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
> >> > + DRM_DEBUG_DRIVER(
> >> > + "failed to evaluate _DSM for %s, exit status %u\n",
> >> > + (char *)string.pointer, (unsigned int)status);
> >> > + kfree(string.pointer);
> >> > + return -EINVAL;
> >>
> >> I said "too bad there isn't an *easy* way" to include more
> >> information. IMHO this is too ugly and error-prone to use
> >> consistently. And if you are going to add more information, why did
> >> you only do it for some of the calls and not others?
> >>
> >> I considered adding a %p extension to print the pathname; I don't know
> >> if that's worthwhile or not. I think it would be ideal if we had a
> >> struct device and could use dev_info(), and then a way to connect the
> >> struct device with an ACPI path, like maybe a dmesg note when we
> >> create the struct device corresponding to an ACPI Device node.
> >
> > Well, we can generally print something like that from pci_acpi_setup().
> >
> > What about the below? Wouldn't it generate too much output on some systems?
>
> Yeah, that probably would generate an awful lot of output. I was just
> hoping to avoid treating ACPI pathnames as first-class objects. What
> do you think about a %p extension? I played with that once, but I
> seem to have lost the patch.
Well, it may be worth doing. However, that information is readily available from
sysfs anyway, you only need to follow the firmware_node link in the PCI device's
sysfs directory and read the path attribute from there. For example, on my
system:
$ cat /sys/devices/pci0000:00/0000:00:1c.4/0000:0b:00.0/firmware_node/path
\_SB_.PCI0.RP05.PXSX
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
>> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki <[email protected]> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
>> >> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> >> > ACPI_FAILURE() should be used for checking its return value. Also
>> >> > add some detailed debug info when acpi_evaluate_object() failed.
>> >> >
>> >> > Reviewed-by: Jani Nikula <[email protected]>
>> >> > Acked-by: Bjorn Helgaas <[email protected]>
>> >> > Signed-off-by: Yijing Wang <[email protected]>
>> >> > ---
>> >> > v4->v5: Add some detailed debug info for acpi_evaluate_object()
>> >> > failure suggested by Bjorn.
>> >> > v3->v4: Fix spell error, add Jani Nikula reviewed-by.
>> >> > v2->v3: Fix compile error pointed out by Hanjun.
>> >> > v1->v2: Add CC to related subsystem MAINTAINERS
>> >> > ---
>> >> > drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
>> >> > drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
>> >> > drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
>> >> > drivers/pci/pci-label.c | 10 +++++--
>> >> > 4 files changed, 54 insertions(+), 27 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
>> >> > index dfff090..e7b526b 100644
>> >> > --- a/drivers/gpu/drm/i915/intel_acpi.c
>> >> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
>> >> > @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
>> >> > static int intel_dsm(acpi_handle handle, int func)
>> >> > {
>> >> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
>> >> > + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
>> >> > struct acpi_object_list input;
>> >> > union acpi_object params[4];
>> >> > union acpi_object *obj;
>> >> > u32 result;
>> >> > - int ret = 0;
>> >> > + acpi_status status;
>> >> > + int ret;
>> >> >
>> >> > input.count = 4;
>> >> > input.pointer = params;
>> >> > @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
>> >> > params[3].package.count = 0;
>> >> > params[3].package.elements = NULL;
>> >> >
>> >> > - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> >> > - if (ret) {
>> >> > - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>> >> > - return ret;
>> >> > + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> >> > + if (ACPI_FAILURE(status)) {
>> >> > + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
>> >> > + DRM_DEBUG_DRIVER(
>> >> > + "failed to evaluate _DSM for %s, exit status %u\n",
>> >> > + (char *)string.pointer, (unsigned int)status);
>> >> > + kfree(string.pointer);
>> >> > + return -EINVAL;
>> >>
>> >> I said "too bad there isn't an *easy* way" to include more
>> >> information. IMHO this is too ugly and error-prone to use
>> >> consistently. And if you are going to add more information, why did
>> >> you only do it for some of the calls and not others?
>> >>
>> >> I considered adding a %p extension to print the pathname; I don't know
>> >> if that's worthwhile or not. I think it would be ideal if we had a
>> >> struct device and could use dev_info(), and then a way to connect the
>> >> struct device with an ACPI path, like maybe a dmesg note when we
>> >> create the struct device corresponding to an ACPI Device node.
>> >
>> > Well, we can generally print something like that from pci_acpi_setup().
>> >
>> > What about the below? Wouldn't it generate too much output on some systems?
>>
>> Yeah, that probably would generate an awful lot of output. I was just
>> hoping to avoid treating ACPI pathnames as first-class objects. What
>> do you think about a %p extension? I played with that once, but I
>> seem to have lost the patch.
>
> Well, it may be worth doing. However, that information is readily available from
> sysfs anyway, you only need to follow the firmware_node link in the PCI device's
> sysfs directory and read the path attribute from there. For example, on my
> system:
>
> $ cat /sys/devices/pci0000:00/0000:00:1c.4/0000:0b:00.0/firmware_node/path
> \_SB_.PCI0.RP05.PXSX
That's perfect. If we had a struct device, we could just use
dev_info() for these messages. But I have no idea how hard it would
be to get at the struct device.
Bjorn
On Friday, January 24, 2014 08:25:23 AM Bjorn Helgaas wrote:
> On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki <[email protected]> wrote:
> > On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
> >> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki <[email protected]> wrote:
> >> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
> >> >> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <[email protected]> wrote:
> >> >> > Since acpi_evaluate_object() returns acpi_status and not plain int,
> >> >> > ACPI_FAILURE() should be used for checking its return value. Also
> >> >> > add some detailed debug info when acpi_evaluate_object() failed.
> >> >> >
> >> >> > Reviewed-by: Jani Nikula <[email protected]>
> >> >> > Acked-by: Bjorn Helgaas <[email protected]>
> >> >> > Signed-off-by: Yijing Wang <[email protected]>
> >> >> > ---
> >> >> > v4->v5: Add some detailed debug info for acpi_evaluate_object()
> >> >> > failure suggested by Bjorn.
> >> >> > v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> >> >> > v2->v3: Fix compile error pointed out by Hanjun.
> >> >> > v1->v2: Add CC to related subsystem MAINTAINERS
> >> >> > ---
> >> >> > drivers/gpu/drm/i915/intel_acpi.c | 33 ++++++++++++++++-------
> >> >> > drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++++++---
> >> >> > drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++++++++++-------
> >> >> > drivers/pci/pci-label.c | 10 +++++--
> >> >> > 4 files changed, 54 insertions(+), 27 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c b/drivers/gpu/drm/i915/intel_acpi.c
> >> >> > index dfff090..e7b526b 100644
> >> >> > --- a/drivers/gpu/drm/i915/intel_acpi.c
> >> >> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
> >> >> > @@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
> >> >> > static int intel_dsm(acpi_handle handle, int func)
> >> >> > {
> >> >> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> >> >> > + struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
> >> >> > struct acpi_object_list input;
> >> >> > union acpi_object params[4];
> >> >> > union acpi_object *obj;
> >> >> > u32 result;
> >> >> > - int ret = 0;
> >> >> > + acpi_status status;
> >> >> > + int ret;
> >> >> >
> >> >> > input.count = 4;
> >> >> > input.pointer = params;
> >> >> > @@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
> >> >> > params[3].package.count = 0;
> >> >> > params[3].package.elements = NULL;
> >> >> >
> >> >> > - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> >> >> > - if (ret) {
> >> >> > - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> >> >> > - return ret;
> >> >> > + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> >> >> > + if (ACPI_FAILURE(status)) {
> >> >> > + acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
> >> >> > + DRM_DEBUG_DRIVER(
> >> >> > + "failed to evaluate _DSM for %s, exit status %u\n",
> >> >> > + (char *)string.pointer, (unsigned int)status);
> >> >> > + kfree(string.pointer);
> >> >> > + return -EINVAL;
> >> >>
> >> >> I said "too bad there isn't an *easy* way" to include more
> >> >> information. IMHO this is too ugly and error-prone to use
> >> >> consistently. And if you are going to add more information, why did
> >> >> you only do it for some of the calls and not others?
> >> >>
> >> >> I considered adding a %p extension to print the pathname; I don't know
> >> >> if that's worthwhile or not. I think it would be ideal if we had a
> >> >> struct device and could use dev_info(), and then a way to connect the
> >> >> struct device with an ACPI path, like maybe a dmesg note when we
> >> >> create the struct device corresponding to an ACPI Device node.
> >> >
> >> > Well, we can generally print something like that from pci_acpi_setup().
> >> >
> >> > What about the below? Wouldn't it generate too much output on some systems?
> >>
> >> Yeah, that probably would generate an awful lot of output. I was just
> >> hoping to avoid treating ACPI pathnames as first-class objects. What
> >> do you think about a %p extension? I played with that once, but I
> >> seem to have lost the patch.
> >
> > Well, it may be worth doing. However, that information is readily available from
> > sysfs anyway, you only need to follow the firmware_node link in the PCI device's
> > sysfs directory and read the path attribute from there. For example, on my
> > system:
> >
> > $ cat /sys/devices/pci0000:00/0000:00:1c.4/0000:0b:00.0/firmware_node/path
> > \_SB_.PCI0.RP05.PXSX
>
> That's perfect. If we had a struct device, we could just use
> dev_info() for these messages. But I have no idea how hard it would
> be to get at the struct device.
>From the pci_dev side that is trivial: use ACPI_COMPANION(). The other way
around is rather more difficult as browsing a list would be involved.
Rafael