2017-04-06 06:46:20

by Michał Kępień

[permalink] [raw]
Subject: [PATCH] platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()

Update debug message logged when the acpi_evaluate_integer() call inside
call_fext_func() fails so that it covers a broader set of possible
errors.

Signed-off-by: Michał Kępień <[email protected]>
---
This patch is a follow-up to v1 of the call_fext_func() cleanup series
and as such, it should be applied to for-next.

drivers/platform/x86/fujitsu-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 26149f58dba7..928778ccc4c1 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -232,7 +232,7 @@ static int call_fext_func(int func, int op, int feature, int state)
status = acpi_evaluate_integer(fujitsu_laptop->acpi_handle, "FUNC",
&arg_list, &value);
if (ACPI_FAILURE(status)) {
- vdbg_printk(FUJLAPTOP_DBG_ERROR, "FUNC interface is not present\n");
+ vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n");
return -ENODEV;
}

--
2.12.2


2017-04-07 11:41:29

by Jonathan Woithe

[permalink] [raw]
Subject: Re: [PATCH] platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()

On Thu, Apr 06, 2017 at 08:46:10AM +0200, Micha?? K??pie?? wrote:
> Update debug message logged when the acpi_evaluate_integer() call inside
> call_fext_func() fails so that it covers a broader set of possible
> errors.
>
> Signed-off-by: Micha?? K??pie?? <[email protected]>
> ---
> This patch is a follow-up to v1 of the call_fext_func() cleanup series
> and as such, it should be applied to for-next.
>
> drivers/platform/x86/fujitsu-laptop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index 26149f58dba7..928778ccc4c1 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -232,7 +232,7 @@ static int call_fext_func(int func, int op, int feature, int state)
> status = acpi_evaluate_integer(fujitsu_laptop->acpi_handle, "FUNC",
> &arg_list, &value);
> if (ACPI_FAILURE(status)) {
> - vdbg_printk(FUJLAPTOP_DBG_ERROR, "FUNC interface is not present\n");
> + vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n");
> return -ENODEV;
> }

As per discussions on the list, this change is fine, is consistent with the
generic nature of possible failure modes and makes sense in the context of
the other recent changes.

Reviewed-by: Jonathan Woithe <[email protected]>

Regards
jonathan

2017-04-07 17:51:17

by Darren Hart

[permalink] [raw]
Subject: Re: [PATCH] platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()

On Fri, Apr 07, 2017 at 09:10:19PM +0930, Jonathan Woithe wrote:
> On Thu, Apr 06, 2017 at 08:46:10AM +0200, Micha?? K??pie?? wrote:
> > Update debug message logged when the acpi_evaluate_integer() call inside
> > call_fext_func() fails so that it covers a broader set of possible
> > errors.
> >
> > Signed-off-by: Micha?? K??pie?? <[email protected]>
> > ---
> > This patch is a follow-up to v1 of the call_fext_func() cleanup series
> > and as such, it should be applied to for-next.
> >
> > drivers/platform/x86/fujitsu-laptop.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> > index 26149f58dba7..928778ccc4c1 100644
> > --- a/drivers/platform/x86/fujitsu-laptop.c
> > +++ b/drivers/platform/x86/fujitsu-laptop.c
> > @@ -232,7 +232,7 @@ static int call_fext_func(int func, int op, int feature, int state)
> > status = acpi_evaluate_integer(fujitsu_laptop->acpi_handle, "FUNC",
> > &arg_list, &value);
> > if (ACPI_FAILURE(status)) {
> > - vdbg_printk(FUJLAPTOP_DBG_ERROR, "FUNC interface is not present\n");
> > + vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n");
> > return -ENODEV;
> > }
>
> As per discussions on the list, this change is fine, is consistent with the
> generic nature of possible failure modes and makes sense in the context of
> the other recent changes.
>
> Reviewed-by: Jonathan Woithe <[email protected]>

Queued to testing, thanks.

--
Darren Hart
VMware Open Source Technology Center