linux-kernel - Re: [PATCH v1 15/15] iio: adc: ad7768-1: add filter type and decimation rate attributes

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: <20250112130426.29b660b1@jic23-huawei>
Date: Sun, 12 Jan 2025 13:04:26 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Jonathan Santos <Jonathan.Santos@...log.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, lars@...afoo.de,
 Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, marcelo.schmitt1@...il.com, PopPaul2021
 <paul.pop@...log.com>
Subject: Re: [PATCH v1 15/15] iio: adc: ad7768-1: add filter type and
 decimation rate attributes

On Tue, 7 Jan 2025 17:50:56 -0600
David Lechner <dlechner@...libre.com> wrote:

> On 1/7/25 9:27 AM, Jonathan Santos wrote:
> > Separate filter type and decimation rate from the sampling frequency
> > attribute. The new filter type attribute enables SINC3 and WIDEBAND
> > filters, which were previously unavailable.  
> 
> See related comments in my reply to the documentation patches about wideband vs.
> FIR and decimation rate vs. -3dB cutoff.
> 
> > 
> > Previously, combining decimation and MCLK divider in the sampling
> > frequency obscured performance trade-offs. Lower MCLK divider
> > settings increase power usage, while lower decimation rates reduce
> > precision by decreasing averaging. By creating a decimation attribute,
> > users gain finer control over performance.  
> 
> It seems like we would also want a power_mode attribute. We already have an
> attribute for this for used by accelerometers so there is some precedent for
> such an attribute.

I'm not sure that attribute was ever a good idea :(
So would prefer we don't use it again unless we are really really stuck.

Usual assumption tends to be if anyone wants to reduce power they
should be able to do so with other controls (i.e. reduce sampling rate or
oversampling). Those are easier to interpret than magic low power mode
attributes.

Jonathan


> 
> > 
> > The addition of those attributes allows a wider range of sampling
> > frequencies and more access to the device features.  
> 
>