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]
Message-ID: <20210704175352.586c9ae8@jic23-huawei>
Date:   Sun, 4 Jul 2021 17:53:52 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Liam Beguin <liambeguin@...il.com>
Cc:     peda@...ntia.se, lars@...afoo.de, pmeerw@...erw.net,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, robh+dt@...nel.org
Subject: Re: [PATCH v3 06/10] iio: afe: rescale: add offset support

On Wed, 30 Jun 2021 21:00:30 -0400
Liam Beguin <liambeguin@...il.com> wrote:

> From: Liam Beguin <lvb@...hos.com>
> 
> This is a preparatory change required for the addition of temperature
> sensing front ends.
> 
> Signed-off-by: Liam Beguin <lvb@...hos.com>
Hi Liam.

A few remaining things inline.

Looking good in general.

Jonathan

> ---
>  drivers/iio/afe/iio-rescale.c | 63 +++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
> index 8f79c582519c..c8750286c308 100644
> --- a/drivers/iio/afe/iio-rescale.c
> +++ b/drivers/iio/afe/iio-rescale.c
> @@ -32,6 +32,7 @@ struct rescale {
>  	bool chan_processed;
>  	s32 numerator;
>  	s32 denominator;
> +	s32 offset;
>  };
>  
>  static int rescale_read_raw(struct iio_dev *indio_dev,
> @@ -39,6 +40,8 @@ static int rescale_read_raw(struct iio_dev *indio_dev,
>  			    int *val, int *val2, long mask)
>  {
>  	struct rescale *rescale = iio_priv(indio_dev);
> +	int scale, scale2;
> +	int schan_off = 0;
>  	s64 tmp, tmp2;
>  	u32 factor;
>  	int ret;
> @@ -99,6 +102,62 @@ static int rescale_read_raw(struct iio_dev *indio_dev,
>  			dev_err(&indio_dev->dev, "unsupported type %d\n", ret);
>  			return -EOPNOTSUPP;
>  		}
> +	case IIO_CHAN_INFO_OFFSET:
> +		/*
> +		 * Processed channels are scaled 1-to-1 and source offset is
> +		 * already taken into account.
> +		 *
> +		 * In other cases, the final offset value is defined by:
> +		 *	offset = schan_offset + rescaler_offset / schan_scale

Maths is right, but perhaps useful to express how this is derived as I had
to scribble it down to check.

		Want to express real world measurement as:
		scale * (raw + offset)
		Given we applying scale and offset recursively we have.
		rescaler_scale * (schan_scale * (raw + schan_offset) + rescaler_offset) 
		which can be rearrange into the correct form at.
		rescaler_scale *schan_scale* (raw + (schan_offset + rescaler_offset/schan_scale))
		Thus the scale and offset we expose to userspace should be.
		scale = rescaler_scale * schan_scale
		offset = schan_offset + rescaler_offset/schan_scale;


> +		 */
> +		if (rescale->chan_processed) {
> +			*val = rescale->offset;
> +			return IIO_VAL_INT;
> +		}
> +
> +		if (iio_channel_has_info(rescale->source->channel,
> +					 IIO_CHAN_INFO_OFFSET)) {
> +			ret = iio_read_channel_offset(rescale->source,
> +						      &schan_off, NULL);
> +			if (ret < 0)
> +				return ret;
if you've returned in the first branch of the if, no need to worry about the
else for checking the second condition.

			if (ret != IIO_VAL_INT)
				return...


> +			else if (ret != IIO_VAL_INT)
> +				return -EOPNOTSUPP;
> +		}
> +
> +		ret = iio_read_channel_scale(rescale->source, &scale, &scale2);
> +		switch (ret) {
> +		case IIO_VAL_FRACTIONAL:
> +			tmp = (s64)rescale->offset * scale2;
> +			*val = div_s64(tmp, scale) + schan_off;
> +			return IIO_VAL_INT;
> +		case IIO_VAL_INT:
> +			*val = div_s64(rescale->offset, scale) + schan_off;
> +			return IIO_VAL_INT;
> +		case IIO_VAL_FRACTIONAL_LOG2:
> +			tmp = (s64)rescale->offset * (1 << scale2);
> +			*val = div_s64(tmp, scale) + schan_off;
> +			return IIO_VAL_INT;
> +		case IIO_VAL_INT_PLUS_NANO:
> +			tmp = (s64)rescale->offset * 1000000000UL;
> +			tmp2 = ((s64)scale * 1000000000UL) + scale2;
> +			factor = gcd(tmp, tmp2);
> +			tmp /= factor;
> +			tmp2 /= factor;

What is the benefit to doing gcd division before div_s64?

> +			*val = div_s64(tmp, tmp2) + schan_off;
> +			return IIO_VAL_INT;
> +		case IIO_VAL_INT_PLUS_MICRO:
> +			tmp = (s64)rescale->offset * 1000000UL;
> +			tmp2 = ((s64)scale * 1000000UL) + scale2;
> +			factor = gcd(tmp, tmp2);
> +			tmp /= factor;
> +			tmp2 /= factor;
> +			*val = div_s64(tmp, tmp2) + schan_off;
> +			return IIO_VAL_INT;
> +		default:
> +			dev_err(&indio_dev->dev, "unsupported type %d\n", ret);
> +			return -EOPNOTSUPP;
> +		}
>  	default:
>  		return -EINVAL;
>  	}
> @@ -175,6 +234,9 @@ static int rescale_configure_channel(struct device *dev,
>  	chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>  		BIT(IIO_CHAN_INFO_SCALE);
>  
> +	if (rescale->offset)
> +	    chan->info_mask_separate |= BIT(IIO_CHAN_INFO_OFFSET);
> +
>  	/*
>  	 * Using .read_avail() is fringe to begin with and makes no sense
>  	 * whatsoever for processed channels, so we make sure that this cannot
> @@ -339,6 +401,7 @@ static int rescale_probe(struct platform_device *pdev)
>  	rescale->cfg = of_device_get_match_data(dev);
>  	rescale->numerator = 1;
>  	rescale->denominator = 1;
> +	rescale->offset = 0;
>  
>  	ret = rescale->cfg->props(dev, rescale);
>  	if (ret)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ