linux-kernel - Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

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: <5cd68e397bb45f606f59038290e4f3ac09d241da.camel@gmail.com>
Date: Thu, 08 Jan 2026 13:45:59 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: Francesco Lavra <flavra@...libre.com>, Ramona Gradinariu	
 <ramona.gradinariu@...log.com>, Antoniu Miclaus
 <antoniu.miclaus@...log.com>,  Lars-Peter Clausen	 <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,  Jonathan Cameron	
 <jic23@...nel.org>, David Lechner <dlechner@...libre.com>, Nuno
 Sá	 <nuno.sa@...log.com>, Andy Shevchenko
 <andy@...nel.org>, 	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling
 frequency

On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote:
> On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote:
> > Hi Francesco,
> > 
> > On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote:
> > > In sensor variants (such as ADXL380 and ADXL382) that support low-power
> > > mode, the SAR signal path allows sampling acceleration data at lower
> > > rates;
> > > more specifically, when the sensor operates in VLP mode, the sampling
> > > frequency is 1 kHz.
> > > To add support for the 1kHz sampling frequency value, modify the
> > > operating
> > > mode selection logic to take into account the sampling frequency, and
> > > configure the decimation filters only when applicable (i.e. when using
> > > a
> > > sampling frequency that relies on the DSM signal path).
> > > 
> > > Signed-off-by: Francesco Lavra <flavra@...libre.com>
> > > ---
> > >  drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++--------------
> > >  drivers/iio/accel/adxl380.h | 10 +++++++-
> > >  2 files changed, 40 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
> > > index bbf1f88ca781..a6919dfce2e9 100644
> > > --- a/drivers/iio/accel/adxl380.c
> > > +++ b/drivers/iio/accel/adxl380.c
> > > @@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct
> > > adxl380_state *st, bool en)
> > >  
> > >                 /*
> > >                  * Activity/Inactivity detection available only in
> > > VLP/ULP
> > > -                * mode and for devices that support low power modes.
> > > Otherwise
> > > -                * go straight to measure mode (same bits as
> > > ADXL380_OP_MODE_HP).
> > > +                * mode and for devices that support low power modes.
> > >                  */
> > >                 if (st->chip_info->has_low_power &&
> > >                     (FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) ||
> > >                      FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl)))
> > > +                       st->odr = ADXL380_ODR_VLP;
> > > +
> > 
> > So before this change we would go to low power mode but still report
> > whatever sampling frequency
> > userspace had configured (which I guess would not correspond to reality)?
> 
> Correct.
> 
> > With the above we'll
> > update the reported odr right?
> 
> Right.
> 
> > Some things/doubts that come to mind:
> > 
> > 1. If I'm right not sure if this shouldn't be treated as a fix.
> 
> Yes, this technically fixes an existing issue, but I didn't advertise it as
> a fix because solving the issue requires adding support for the 1kHz
> frequency, which seems to go beyond the strict definition of a fix and
> sounds more like a new feature.
>  
> > 2. Should we cache the current odr so that we restore it when
> > appropriate?
> 
> Do you mean caching it when activity detection is enabled and restoring it
> when detection is disabled? It could be done.
> 

Just and idea. I think it makes sense since enabling activity detection will change things
under the hood and some users might not realize it. But it is not super important I guess.

> > 3. Other thing that comes to mind is if it makes sense to allow
> > controlling odr if
> > Activity/Inactivity detection is enabled?
> 
> Disallowing odr control when activity detection is enabled could be an
> option, but what error code should be returned if the user tries to set the
> sampling frequency value when not allowed? -EBUSY?

I think it makes sense given the constrains on activity events. EBUSY would be my choice as well.
Out of curiosity, do you know how the chip behaves if we change the odr with activity enabled? Is it
just ignored?

- Nuno Sá