linux-kernel - Re: [PATCH v10 0/2] Add MAX14001/MAX14002 support

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: <20250903171105.00003dcd@huawei.com>
Date: Wed, 3 Sep 2025 17:11:05 +0100
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: David Lechner <dlechner@...libre.com>
CC: Marilene Andrade Garcia <marilene.agarcia@...il.com>,
	<linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>, Kim Seer Paller <kimseer.paller@...log.com>,
	Jonathan Cameron <jic23@...nel.org>, Nuno Sá
	<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Lars-Peter Clausen
	<lars@...afoo.de>, Michael Hennerich <Michael.Hennerich@...log.com>, "Rob
 Herring" <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, "Conor
 Dooley" <conor+dt@...nel.org>, Marcelo Schmitt <marcelo.schmitt1@...il.com>,
	Marcelo Schmitt <Marcelo.Schmitt@...log.com>, Ceclan Dumitru
	<dumitru.ceclan@...log.com>, Jonathan Santos <Jonathan.Santos@...log.com>,
	Dragos Bogdan <dragos.bogdan@...log.com>
Subject: Re: [PATCH v10 0/2] Add MAX14001/MAX14002 support

> 
> > because of the unique way this device handles communication, such as 
> > inverting bits before sending a message, updating the write enable register 
> > before writing any other register, and updating it again afterward. However, 
> > as I am still new to the IIO kernel code, I may be missing something. If you 
> > could provide further explanation or an example, I would be grateful.
> > 
> > Regarding locking, Kim’s original code implemented it, and it remains in 
> > the driver.
> > 
> > I still have a question about using _mean_raw (IIO_CHAN_INFO_AVERAGE_RAW) 
> > to read the register containing the latest filtered average ADC readings. 
> > Should I create a v11 version with a patch to include in_voltageY_mean_raw 
> > in the file /linux/Documentation/ABI/testing/sysfs-bus-iio?   
> 
> There is already "/sys/bus/iio/devices/iio:deviceX/in_Y_mean_raw" which
> I think is intended to cover that.
> 
> > The idea is to use in_voltageY_mean_raw to return the filtered average and 
> > also to set how many ADC readings (0, 2, 4, or 8) are included in the mean 

0 is an odd value, I assume 1 given average of 0 readings is effectively undefined.

> > calculation. Any feedback on using IIO_CHAN_INFO_AVERAGE_RAW this way would 
> > be appreciated.

Sorry I missed this question in earlier versions.  I'm terrible at reading
cover letters!

Definitely don't use the in_voltage_mean_raw value for the control of the averaging
width.  That is too obscure and normal convention is read and write of
sysfs attributes should see effectively the same value (or not all
either read or write)

This is a little unusual as normally when we see this sort of thing it
easily maps to oversampling but in this case it's a moving window average
rather than a downsampling style.

So a few options come to mind.
1. Treat it as a filter on a channel. Describe with 3dB point and type as
   box filter.
   We probably want to describe it as an additional channel to do this or
   we could have assumption that to read unfiltered, you set the
   filter 3dB to inf (see other discussion ongoing about that).

2. Add another attribute to add richer info to the in_voltage_mean_raw
   Something like in_voltage_mean_num.
   Bit of a special case but we have had the mean_raw interface a long time
   so we can't get rid of that and it seems illogical to force use of filter
   ABI to control it.

> > 
Other stuff from David followed but I have nothing to add to that.

Jonathan