linux-kernel - Re: [PATCH] iio: adc: axp20x_adc: fix charging current reporting on AXP22x

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] [day] [month] [year] [list]

Message-ID: <20210307124625.08109dea@archlinux>
Date:   Sun, 7 Mar 2021 12:46:25 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Evgeny Boger <boger@...enboard.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Quentin Schulz <quentin.schulz@...e-electrons.com>,
        Quentin Schulz <quentin.schulz@...tlin.com>
Subject: Re: [PATCH] iio: adc: axp20x_adc: fix charging current reporting on
 AXP22x

On Sun,  7 Mar 2021 02:52:38 +0300
Evgeny Boger <boger@...enboard.com> wrote:

> Both the charging and discharging currents on AXP22x are stored as
> 12-bit integers, in accordance with the datasheet.
> It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA).
> 
> The scale factor of 0.5 is never mentioned in datasheet, nor in the
> vendor source code. I think it was here to compensate for
> erroneous additional bit in register width.
> 
> Tested on custom A40i+AXP221s board with external ammeter as
> a reference.
> 
> Signed-off-by: Evgeny Boger <boger@...enboard.com>

+CC Quentin's bootlin address.

One comment inline,

Jonathan

> ---
>  drivers/iio/adc/axp20x_adc.c | 14 ++------------
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> index 3e0c0233b431..8db6699c20c3 100644
> --- a/drivers/iio/adc/axp20x_adc.c
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -253,17 +253,7 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev,
>  	struct axp20x_adc_iio *info = iio_priv(indio_dev);
>  	int size;
>  
> -	/*
> -	 * N.B.: Unlike the Chinese datasheets tell, the charging current is
> -	 * stored on 12 bits, not 13 bits. Only discharging current is on 13
> -	 * bits.
> -	 */
> -	if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I)
> -		size = 13;
> -	else
> -		size = 12;
> -
> -	*val = axp20x_read_variable_width(info->regmap, chan->address, size);
> +	*val = axp20x_read_variable_width(info->regmap, chan->address, 12);
>  	if (*val < 0)
>  		return *val;
>  
> @@ -387,7 +377,7 @@ static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,
>  
>  	case IIO_CURRENT:
>  		*val = 0;
> -		*val2 = 500000;
> +		*val2 = 1000000;
>  		return IIO_VAL_INT_PLUS_MICRO;
		*val = 1;
		return IIO_VAL_INT;

Should work if the scale factor is 1.
Note that we could just have reported the channel as _processed in the first place, but
given we didn't better to keep the ABI the same and just have a noop scale factor.

>  
>  	case IIO_TEMP: