[Intel-gfx] [PATCH v5] ACPI: Fix acpi_evaluate_object() return value check

[Bjorn Helgaas]

On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki <rjw at rjwysocki.net> 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 <rjw at rjwysocki.net> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang <wangyijing at huawei.com> 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 <jani.nikula at intel.com>
>> >> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
>> >> > Signed-off-by: Yijing Wang <wangyijing at huawei.com>
>> >> > ---
>> >> > 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