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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52e5cea72b99fc23c922cf74d7dce3403f43c9cd.camel@gmail.com>
Date: Wed, 07 Jan 2026 13:56:12 +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

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)? With the above we'll
update the reported odr right? Some things/doubts that come to mind:

1. If I'm right not sure if this shouldn't be treated as a fix.
2. Should we cache the current odr so that we restore it when appropriate?
3. Other thing that comes to mind is if it makes sense to allow controlling odr if
Activity/Inactivity detection is enabled?

Thx!
- Nuno Sá