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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 12 Mar 2023 16:51:00 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Matti Vaittinen <mazziesaccount@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Shreeya Patel <shreeya.patel@...labora.com>,
        Paul Gazzillo <paul@...zz.com>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        Zhigang Shi <Zhigang.Shi@...eon.com>,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH v3 2/6] iio: light: Add gain-time-scale helpers

On Mon, 6 Mar 2023 14:52:57 +0200
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Mon, Mar 06, 2023 at 11:17:15AM +0200, Matti Vaittinen wrote:
> > Some light sensors can adjust both the HW-gain and integration time.
> > There are cases where adjusting the integration time has similar impact
> > to the scale of the reported values as gain setting has.
> > 
> > IIO users do typically expect to handle scale by a single writable 'scale'
> > entry. Driver should then adjust the gain/time accordingly.
> > 
> > It however is difficult for a driver to know whether it should change
> > gain or integration time to meet the requested scale. Usually it is
> > preferred to have longer integration time which usually improves
> > accuracy, but there may be use-cases where long measurement times can be
> > an issue. Thus it can be preferable to allow also changing the
> > integration time - but mitigate the scale impact by also changing the gain
> > underneath. Eg, if integration time change doubles the measured values,
> > the driver can reduce the HW-gain to half.
> > 
> > The theory of the computations of gain-time-scale is simple. However,
> > some people (undersigned) got that implemented wrong for more than once.
> > 
> > Add some gain-time-scale helpers in order to not dublicate errors in all
> > drivers needing these computations.  
> 
> ...
> 
> > +/*  
> 
> If it's deliberately not a kernel doc, why to bother to have it looking as one?
> It's really a provocative to some people who will come with a patches to "fix"
> this...

Just make it kernel-doc.

> 
> > + * iio_gts_get_gain - Convert scale to total gain
> > + *
> > + * Internal helper for converting scale to total gain.
> > + *
> > + * @max:	Maximum linearized scale. As an example, when scale is created
> > + *		in magnitude of NANOs and max scale is 64.1 - The linearized
> > + *		scale is 64 100 000 000.
> > + * @scale:	Linearized scale to compte the gain for.
> > + *
> > + * Return:	(floored) gain corresponding to the scale. -EINVAL if scale
> > + *		is invalid.
> > + */

> ...
> 
> > +EXPORT_SYMBOL_NS_GPL(iio_gts_total_gain_to_scale, IIO_GTS_HELPER);  
> 
> I would say _HELPER part is too much, but fine with me.

Hmm. I think I like the HELPER bit as separates it from being a driver.
Of course I might change my mind after a few sleeps.





> > +++ b/drivers/iio/light/iio-gts-helper.h  
> 
> Is it _only_ for a Light type of sensors?

I'd move it up a directory and allow for other users.

Jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ