RE: [PATCH v2 2/2] iio: adc: adding support for pac193x

[Robin Getz]

Hi Marius:

Thanks for describing the use cases - that helps.

On Tuesday, November 7, 2023 7:56 AM
Marius.Cristea@xxxxxxxxxxxxx wrote:
>Here there are two kinds of customers (that were asking for this
>functionality) for some particular use cases.
>
>The first category of customers was asking to change the resistor value
>from the userspace to use a lower cost resistor, with lower precision,
>(the nominal value will still be used into the device tree) but to
>leave the possibility to calibrate the system and update the resistor
>value at runtime. Calibrated value will be kept into an eeprom. 

The use case make sense - but that can be done inside U-Boot, patching device tree. This is the way that most people do this sort of thing.

U-Boot supports " fdt get" and " fdt set" commands to manipulate device tree. What most people do is set up a value/pair in u-boot env, and if it exists, replace the value in device tree. For example

This sets a clock, to whatever you measure it (for the same reason - cheap oscillators have terrible offsets).

		"if test -n ${ad936x_ext_refclk} && test ! -n ${ad936x_skip_ext_refclk}; then " \
			"fdt set /clocks/clock@0 clock-frequency ${ad936x_ext_refclk}; " \
		"fi; " \

>The second type of customers are using a modular design (the
>exchangeable module will contain also the PAC chip). The module design
>was made to support different currents (different order of magnitude)
>like battery banks. At runtime/boot time you need to identify the
>module used/inserted in the field and set the shunt resistor
>accordingly.

You could also use device tree overlays for this sort of thing in userspace. 
That is how most people would handle hot plug (or replaceable) hardware...

>The "in_shunt_resistor" property is also used by:
>drivers/iio/adc/ina2xx-adc.c
>drivers/iio/adc/rtq6056.c

IMHO - Just because people did it bad once, doesn't mean you should repeat it...

-Robin