lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 7 Apr 2017 21:10:19 +0930
From:   Jonathan Woithe <jwoithe@...t42.net>
To:     Micha?? K??pie?? <kernel@...pniu.pl>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
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?? <kernel@...pniu.pl>
> ---
> 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 <jwoithe@...t42.net>

Regards
  jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ