linux-kernel - Re: [PATCH v2 2/5] iio: add processed write API

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

Message-ID: <2406495.tdWV9SEqCh@fw-rgant>
Date: Fri, 03 Oct 2025 16:35:59 +0200
From: Romain Gantois <romain.gantois@...tlin.com>
To: David Lechner <dlechner@...libre.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jonathan Cameron <jic23@...nel.org>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Hans de Goede <hansg@...nel.org>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
 linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 2/5] iio: add processed write API

On Wednesday, 1 October 2025 12:03:21 CEST David Lechner wrote:
> On Wed, Oct 1, 2025 at 9:19 AM Romain Gantois <romain.gantois@...tlin.com>
> 
...
> > > > +           case IIO_VAL_INT_PLUS_MICRO:
> > > > +           case IIO_VAL_INT_PLUS_NANO:
> > > > +                   break;
> > > > +           case IIO_VAL_FRACTIONAL:
> > > > +                   offset_val /= offset_val2;
> > > > +                   break;
> > > > +           case IIO_VAL_FRACTIONAL_LOG2:
> > > > +                   offset_val >>= offset_val2;
> > > > +                   break;
> > > > +           default:
> > > > +                   return -EINVAL;
> > > > +           }
> > > > +
> > > > +           *raw -= offset_val;
> > > > +   }
> > > 
> > > There are some rounding biases in this function, but I'm not sure if
> > > it is worth trying to make a perfectly fair function.
> > 
> > I'm unfamiliar with the notion of rounding bias, does it mean that nested
> > calls of this function would tend to amplify rounding errors? In this
> > case,
> > would rounding to the nearest integer instead of whatever is being done by
> > the
> > integer division here be a good solution?
> 
> In this case, the issue is when you are taking multiple samples. When you
> look at the average of all of the samples, you will be able to see the
> bias. For example, in one of the drivers I was looking at there is an
> offset of xxxx.6. Since the IIO_VAL_INT_PLUS_MICRO case is just dropping
> any fractional part, the raw value will be on average 0.6 lsb lower that
> the requested value. This could be a problem in an application where high
> precision is required. But probably not noticeable in cases where 1 lsb is
> less than the noise level.
> 

Thanks a lot for the detailed explanation. For the IIO_VAL_INT_PLUS_MICRO/NANO 
cases, I think that scaling by MICRO/NANO, then subtracting the offset, then 
dividing and rounding to the closest would give a small precision improvement 
in some cases. It would be a bit slower though, but for low sample-rate 
devices like the ones in IIO I don't think it would be noticeable. I'll give 
it a try.

> The floor division for IIO_VAL_FRACTIONAL creates a similar bias.
> DIV_ROUND_CLOSEST can help there, but even that has a small bias because
> values of exactly 0.5 always get rounded in the same direction. That kind
> of bias is much smaller though, so easier to ignore.
> 

DIV_ROUND_CLOSEST would indeed reduce the bias at no substantial cost, 
so I think I'll go with that.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)