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
