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:	Sat, 2 Jan 2016 18:28:04 +0000
From:	Jonathan Cameron <jic23@...nel.org>
To:	SF Markus Elfring <elfring@...rs.sourceforge.net>,
	linux-iio@...r.kernel.org, Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org,
	Julia Lawall <julia.lawall@...6.fr>
Subject: Re: [PATCH] iio: qcom-spmi-vadc: One check less in
 vadc_measure_ref_points() after error detection

On 26/12/15 13:04, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@...rs.sourceforge.net>
> Date: Sat, 26 Dec 2015 13:53:15 +0100
> 
> This issue was detected by using the Coccinelle software.
> 
> Move the jump label directly before the desired log statement
> so that the variable "ret" does not need to be checked once more
> after it was determined that a function call failed.
> 
> Signed-off-by: Markus Elfring <elfring@...rs.sourceforge.net>
If we are going to change this, I would prefer to see more useful
local error messages and direct returns rather than jumping to
a very generic message at the end.

I'm also less than keen on jumping into conditionals as I find
it slightly less readable. 

We might technically be 'simplifying' the code, but in this case
the gain is very minor for a fair bit of code churn...

Thanks,

Jonathan
> ---
>  drivers/iio/adc/qcom-spmi-vadc.c | 17 +++++++++--------
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
> index c2babe5..391eefa 100644
> --- a/drivers/iio/adc/qcom-spmi-vadc.c
> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
> @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>  	prop = vadc_get_channel(vadc, VADC_REF_1250MV);
>  	ret = vadc_do_conversion(vadc, prop, &read_1);
>  	if (ret)
> -		goto err;
> +		goto report_failure;
In this first case we have already had a report that a conversion failed.
I suppose adding that it was during reference point measurement 'might'
be useful additional information.  I'm not really convinced of it does
however... Hence I'd drop reporting it entirely in this function.
>  
>  	/* Try with buffered 625mV channel first */
>  	prop = vadc_get_channel(vadc, VADC_SPARE1);
> @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>  
>  	ret = vadc_do_conversion(vadc, prop, &read_2);
>  	if (ret)
> -		goto err;
> +		goto report_failure;
>  
>  	if (read_1 == read_2) {
>  		ret = -EINVAL;
I think this one indicates we can't actually read anything at all
for some reason...  It's the only form of error we won't have effectively
already reported so is worthy of some sort of debug message...
> -		goto err;
> +		goto report_failure;
>  	}
>  
>  	vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2;
> @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>  	prop = vadc_get_channel(vadc, VADC_VDD_VADC);
>  	ret = vadc_do_conversion(vadc, prop, &read_1);
>  	if (ret)
> -		goto err;
> +		goto report_failure;
>  
>  	prop = vadc_get_channel(vadc, VADC_GND_REF);
>  	ret = vadc_do_conversion(vadc, prop, &read_2);
>  	if (ret)
> -		goto err;
> +		goto report_failure;
>  
>  	if (read_1 == read_2) {
>  		ret = -EINVAL;
> -		goto err;
> +		goto report_failure;
>  	}
>  
>  	vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2;
>  	vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2;
> -err:
> -	if (ret)
> +	if (ret) {
> +report_failure:
>  		dev_err(vadc->dev, "measure reference points failed\n");
> +	}
>  
>  	return ret;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ