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

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: <BYAPR05MB4424A16007E7FA7A00A1F00BA9A9A@BYAPR05MB4424.namprd05.prod.outlook.com>
Date:   Tue, 7 Nov 2023 15:39:33 +0000
From:   Robin Getz <rgetz@...hworks.com>
To:     "Marius.Cristea@...rochip.com" <Marius.Cristea@...rochip.com>,
        "jic23@...nel.org" <jic23@...nel.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/2] iio: adc: adding support for pac193x

Hi Marius:

Thanks for describing the use cases - that helps.

On Tuesday, November 7, 2023 7:56 AM
Marius.Cristea@...rochip.com 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