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: <20260116194222.0723324a@jic23-huawei>
Date: Fri, 16 Jan 2026 19:42:22 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Francesco Lavra <flavra@...libre.com>
Cc: Ramona Gradinariu <ramona.gradinariu@...log.com>, Antoniu Miclaus
 <antoniu.miclaus@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, Michael
 Hennerich <Michael.Hennerich@...log.com>, 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 v2 3/3] iio: accel: adxl380: Add support for 1 kHz
 sampling frequency

On Thu, 15 Jan 2026 18:53:50 +0100
Francesco Lavra <flavra@...libre.com> 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); in addition,
> constrain the available sampling frequency values based on whether the
> sensor is operating in low-power mode.
> 
> Signed-off-by: Francesco Lavra <flavra@...libre.com>

Hi Francesco,

A similar case to the one Andy pointed out in the earlier patch plus
a trivial comment.  Given how trivial they are and where we are in the
cycle, I'll make them whilst applying.


Thanks,

Jonathan

>  
> +static int adxl380_samp_freq_avail(struct adxl380_state *st, const int **vals,
> +				   int *length)
> +{
> +	bool act_inact_enabled;
> +	int ret;
> +
> +	if (!st->chip_info->has_low_power) {
> +		*vals = st->chip_info->samp_freq_tbl + ADXL380_ODR_DSM;
> +		*length = ADXL380_ODR_MAX - ADXL380_ODR_DSM;
> +		return 0;
> +	}
> +
> +	ret = adxl380_act_inact_enabled(st, &act_inact_enabled);
> +	if (!ret) {
	if (ret)
		return ret;

	/*
	 * Motion detection is only functional in low-power mode, and this 
	 * affects the available sampling frequencies.
	 */
	*vals = st->chip_info->samp_freq_tbl;
	*length = act_inact_enabled ? ADXL380_ODR_DSM : ADXL380_ODR_MAX;

	return 0;
	
> +		/*
> +		 * Motion detection is only functional in low-power mode, and
> +		 * this affects the available sampling frequencies.
> +		 */
> +		*vals = st->chip_info->samp_freq_tbl;
> +		*length = act_inact_enabled ? ADXL380_ODR_DSM : ADXL380_ODR_MAX;
> +	}
> +
> +	return ret;
> +}

> @@ -1261,12 +1296,18 @@ static int adxl380_write_raw(struct iio_dev *indio_dev,
>  			     int val, int val2, long info)
>  {
>  	struct adxl380_state *st = iio_priv(indio_dev);
> +	const int *freq_vals;
> +	int freq_count;
>  	int odr_index, lpf_index, hpf_index, range_index;
> +	int ret;
Might as well combine the new variables on one line or even

  	int odr_index, lpf_index, hpf_index, range_index, freq_count, ret; 



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ