Hello maintainers,

This patch series adds basic support for the Analog Devices 
MAX14001/MAX14002, configurable, isolated 10-bit ADCs for multi-range 
binary inputs. Besides the implemented ADC readings, these devices have 
more features, like a binary comparator; a filtered reading that can 
provide the average of the last 2, 4, or 8 ADC readings; and an inrush 
comparator that triggers the inrush current. There is also a fault feature 
that can diagnose seven possible fault conditions. 

To keep the commits simple and organized, these initial driver support 
patches aim to upstream only the features related to reading two registers, 
one that contains the latest ADC reading, and another one that contains 
the latest filtered ADC readings. Though, _raw and _mean_raw are providing 
the same results in this initial version since the data averaging config 
interface is not implemented yet. For this, IIO_CHAN_INFO_AVERAGE_RAW was 
used to return the filtered average of ADC readings. An additional patch 
documenting the in_voltageY_mean_raw interface can be added on v2 if that 
would be desirable. The idea is to use in_voltageY_mean_raw to return the 
filtered average value, and also to set how many ADC readings (0, 2, 4, 
or 8) are included in the mean calculation. I would also like to know if 
you have any feedback on using IIO_CHAN_INFO_AVERAGE_RAW in this way.

The changes were tested using the Raspberry Pi modified kernel version 
rpi-6.6 on Raspberry Pi 5 hardware. For testing, the MAX14001PMB evaluation 
board was used, which contains two MAX14001 devices. According to the 
board’s circuit configuration, one device measures current and the other 
measures voltage. Due to the evaluation board’s circuitry, the devices 
also receive an offset that allows them to measure negative values. None 
of these evaluation board-specific characteristics were included in the 
driver code (neither the offset nor the current channel capability). 
However, 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 file?

The code was developed during the GSoC program as part of the Analog 
Devices Mentorship. Many thanks to my mentors Marcelo Schmitt,  Ceclan 
Dumitru, Jonathan Santos and Dragos Bogdan for their guidance, reviews, 
and explanations about the IIO subsystem code.

I intend to keep sending patches to cover all the features of the device.

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


Marilene Andrade Garcia (2):
  dt-bindings: iio: adc: Add MAX14001
  iio: adc: Add basic support for MAX14001

 .../bindings/iio/adc/adi,max14001.yaml        |  78 +++++++
 MAINTAINERS                                   |   8 +
 drivers/iio/adc/Kconfig                       |  10 +
 drivers/iio/adc/Makefile                      |   1 +
 drivers/iio/adc/max14001.c                    | 213 ++++++++++++++++++
 5 files changed, 310 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml
 create mode 100644 drivers/iio/adc/max14001.c


base-commit: 7c680c4dbbb5365ad78ce661886ce1668ff40f9c
-- 
2.34.1

On Thu, Aug 21, 2025 at 10:36:06AM -0300, Marilene Andrade Garcia wrote:
> Hello maintainers,
> 
> This patch series adds basic support for the Analog Devices 
> MAX14001/MAX14002, configurable, isolated 10-bit ADCs for multi-range 
> binary inputs. Besides the implemented ADC readings, these devices have 
> more features, like a binary comparator; a filtered reading that can 
> provide the average of the last 2, 4, or 8 ADC readings; and an inrush 
> comparator that triggers the inrush current. There is also a fault feature 
> that can diagnose seven possible fault conditions. 
> 
> To keep the commits simple and organized, these initial driver support 
> patches aim to upstream only the features related to reading two registers, 
> one that contains the latest ADC reading, and another one that contains 
> the latest filtered ADC readings. Though, _raw and _mean_raw are providing 
> the same results in this initial version since the data averaging config 
> interface is not implemented yet. For this, IIO_CHAN_INFO_AVERAGE_RAW was 
> used to return the filtered average of ADC readings. An additional patch 
> documenting the in_voltageY_mean_raw interface can be added on v2 if that 
> would be desirable. The idea is to use in_voltageY_mean_raw to return the 
> filtered average value, and also to set how many ADC readings (0, 2, 4, 
> or 8) are included in the mean calculation. I would also like to know if 
> you have any feedback on using IIO_CHAN_INFO_AVERAGE_RAW in this way.
> 
> The changes were tested using the Raspberry Pi modified kernel version 
> rpi-6.6 on Raspberry Pi 5 hardware. For testing, the MAX14001PMB evaluation 
> board was used, which contains two MAX14001 devices. According to the 
> board’s circuit configuration, one device measures current and the other 
> measures voltage. Due to the evaluation board’s circuitry, the devices 
> also receive an offset that allows them to measure negative values. None 
> of these evaluation board-specific characteristics were included in the 
> driver code (neither the offset nor the current channel capability). 
> However, 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 file?
> 
> The code was developed during the GSoC program as part of the Analog 
> Devices Mentorship. Many thanks to my mentors Marcelo Schmitt,  Ceclan 
> Dumitru, Jonathan Santos and Dragos Bogdan for their guidance, reviews, 
> and explanations about the IIO subsystem code.
> 
> I intend to keep sending patches to cover all the features of the device.

Something gone wrong here? There's already a v9 from another ADI
employee on the list:
https://lore.kernel.org/all/20230710042723.46084-2-kimseer.paller@analog.com/

On 08/21, Conor Dooley wrote:
> On Thu, Aug 21, 2025 at 10:36:06AM -0300, Marilene Andrade Garcia wrote:
> > Hello maintainers,
> > 
> > This patch series adds basic support for the Analog Devices 
> > MAX14001/MAX14002, configurable, isolated 10-bit ADCs for multi-range 
...
> 
> Something gone wrong here? There's already a v9 from another ADI
> employee on the list:
> https://lore.kernel.org/all/20230710042723.46084-2-kimseer.paller@analog.com/

Yes, my procedure for finding parts for GSoC projects failed to find that set.
From quick read of v9 thread, the reason for that not being applied was lack
of detailed comments about device data transfer handling?
Anyway, I guess the only thing left to do now is see what can be taken from
Marilene's set and applied on top of Kim's one.

I'm sorry for this unfortunate situation.

On Thu, Aug 21, 2025 at 04:24:11PM -0300, Marcelo Schmitt wrote:
> On 08/21, Conor Dooley wrote:
> > On Thu, Aug 21, 2025 at 10:36:06AM -0300, Marilene Andrade Garcia wrote:
> > > Hello maintainers,
> > > 
> > > This patch series adds basic support for the Analog Devices 
> > > MAX14001/MAX14002, configurable, isolated 10-bit ADCs for multi-range 
> ...
> > 
> > Something gone wrong here? There's already a v9 from another ADI
> > employee on the list:
> > https://lore.kernel.org/all/20230710042723.46084-2-kimseer.paller@analog.com/
> 
> Yes, my procedure for finding parts for GSoC projects failed to find that set.
> From quick read of v9 thread, the reason for that not being applied was lack
> of detailed comments about device data transfer handling?
> Anyway, I guess the only thing left to do now is see what can be taken from
> Marilene's set and applied on top of Kim's one.
> 
> I'm sorry for this unfortunate situation.

Eek, saving grace I suppose is that the experience of writing the driver
is the most important thing to get out of GSoC?