linux-kernel - Re: [PATCH v3 11/15] iio: accel: adxl345: add g-range configuration

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: <20250315174749.179f4033@jic23-huawei>
Date: Sat, 15 Mar 2025 17:47:49 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 eraretuya@...il.com
Subject: Re: [PATCH v3 11/15] iio: accel: adxl345: add g-range configuration

On Thu, 13 Mar 2025 17:47:08 +0100
Lothar Rubusch <l.rubusch@...il.com> wrote:

> On Tue, Mar 4, 2025 at 2:40 PM Jonathan Cameron <jic23@...nel.org> wrote:
> >
> > On Thu, 20 Feb 2025 10:42:30 +0000
> > Lothar Rubusch <l.rubusch@...il.com> wrote:
> >  
> > > Introduce means to configure and work with the available g-ranges
> > > keeping the precision of 13 digits.
> > >
> > > This is in preparation for the activity/inactivity feature.  
> >
> > I'm not really following why adding range control is anything
> > much to do with that. Mostly we do this to improve accuracy for
> > low accelerations.
> >  
> 
> As you probably saw the connection comes a bit over the link in
> adjusting the activity/inactivity
> parameters (times and threshold) by a given range in the follow up patches.
> 
> If the question is rather why at all adding this g-range control. My
> idea was that adjusting i.e. lowering precision, less odr, etc might
> also help adjusting power consumption. In other words
> from a user perspective I assume there is more configuration
> possibility. I did not pretend to tune
> the implementation for lowest possible power consumption, though. It
> was just an idea.
> 
> [Also, I was curious about implementing it here. My patch here is
> rather meant as a proposal,
> if you strongly oppose the idea, pls let me know.]

Control is fine (and lots of drivers do it). It was just that comment
that had me confused. To me this is a mostly unrelated feature.

It used to be the case when I last regularly used multirange accelerometers
that they had approximately matched the quality of the ADC with that of
the sensor.  So normal reason to reduce range was that it actually gave
you better accuracy as long as you didn't saturate. Mind you, for
the applications I had with sensors on sprinters shoes, all accelerometers
used to saturate even on the highest range setting! Not sure if the
reducing range for noise improvements is true on this particular sensor.

Jonathan