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-next>] [day] [month] [year] [list]
Message-Id: <cover.1756816682.git.marilene.agarcia@gmail.com>
Date: Tue,  2 Sep 2025 10:14:39 -0300
From: Marilene Andrade Garcia <marilene.agarcia@...il.com>
To: linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Cc: Marilene Andrade Garcia <marilene.agarcia@...il.com>,
	Kim Seer Paller <kimseer.paller@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	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: [PATCH v10 0/2] Add MAX14001/MAX14002 support

Hello everyone,

Thank you for your input on how to handle the situation with the driver code. 
Kim, I also apologize for the unexpected situation involving your previous 
code.

Based on the suggestions, I applied my v1 code changes to v9 of Kim’s code, 
resulting in this v10 version that combines both. 
Compared to v9, the updates are:

- Added support for max14002.
- Added a function to write a single register, since the write enable 
register must be updated before writing to any others and updated again 
afterward.
- Renamed the init function to better reflect its purpose, which is to 
disable the memory verification fault. I also replaced the one-by-one 
handling of registers verification values with a loop, since they are in 
sequential ascending order.
- Replaced the old regulator APIs with the new ones.
- Updated the device tree documentation to align with the datasheet 
nomenclature for voltage suppliers.
- Used IIO_CHAN_INFO_AVERAGE_RAW to return the filtered average of ADC 
readings.

One of the reviews I received about my v1 version suggested using a custom 
regmap. I attempted to implement that, but I feel that most of the default 
regmap functions (e.g., regmap_update_bits) would need to be overridden 
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? 
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 
calculation. Any feedback on using IIO_CHAN_INFO_AVERAGE_RAW this way would 
be appreciated.

The v10 changes were tested on a Raspberry Pi 5 using a modified kernel 
(rpi-6.12). The MAX14001PMB evaluation board, which contains two MAX14001 
devices, was used for testing. One device measures current, and the other 
measures voltage. The evaluation board introduces an offset to allow 
measuring negative values. These board-specific characteristics were not 
included in the driver code (neither the offset nor the current channel 
capability), but they were considered in the calculation of the values read 
by the devices. Should the code that applies these board configuration 
parameters be added as an additional driver file inside the IIO subsystem, 
or should it remain only in a user application?

I plan to continue sending patches to cover all the features of the device. 
This includes adding interrupt handling for faults and for when the signal 
exceeds the upper or lower threshold, implementing the inrush current 
feature, and completing the filtered average reading functionality by 
adding the ability to set the number of readings used in the mean 
calculation.

And I would like to thank again my GSoC mentors Marcelo Schmitt, Ceclan 
Dumitru, Jonathan Santos and Dragos Bogdan for their help with the code.

Thank you for your time,
Best regards,
Marilene Andrade Garcia.

Marilene Andrade Garcia (2):
  dt-bindings: iio: adc: add max14001
  iio: adc: max14001: New driver

 .../bindings/iio/adc/adi,max14001.yaml        |  79 ++++
 MAINTAINERS                                   |   9 +
 drivers/iio/adc/Kconfig                       |  10 +
 drivers/iio/adc/Makefile                      |   1 +
 drivers/iio/adc/max14001.c                    | 355 ++++++++++++++++++
 5 files changed, 454 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml
 create mode 100644 drivers/iio/adc/max14001.c


base-commit: d1487b0b78720b86ec2a2ac7acc683ec90627e5b
-- 
2.34.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ