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: <710b749db585689eb959ccc00a0230a5059b424f.camel@microchip.com>
Date:   Tue, 7 Nov 2023 12:55:48 +0000
From:   <Marius.Cristea@...rochip.com>
To:     <rgetz@...hworks.com>, <jic23@...nel.org>
CC:     <devicetree@...r.kernel.org>, <conor+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <lars@...afoo.de>,
        <linux-iio@...r.kernel.org>, <robh+dt@...nel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] iio: adc: adding support for pac193x

Hi Robin,


On Thu, 2023-11-02 at 14:28 +0000, Robin Getz wrote:
> [You don't often get email from rgetz@...hworks.com. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On Friday, October 27, 2023 11:18 AM
> Jonathan Cameron <jic23@...nel.org> wrote:
> 
> > On Wed, 25 Oct 2023 16:44:04 +0300
> > <mailto:marius.cristea@...rochip.com> wrote:
> > 
> > > From: Marius Cristea <mailto:marius.cristea@...rochip.com>
> > > 
> > > This is the iio driver for Microchip
> > > PAC193X series of Power Monitor with Accumulator chip family.
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
> > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
> > > new file mode 100644
> > > index 000000000000..ea43df292b9c
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
> > > @@ -0,0 +1,15 @@
> > > +What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor_X
> > > +KernelVersion: 6.6
> > > +Contact: mailto:linux-iio@...r.kernel.org
> > > +Description:
> > > + The value of the shunt resistor may be known only at runtime
> > > and set
> > > + by a client application.
> 
> What? End users (people with access to userspace) don't whip out
> their soldering iron to add/change shunt resistors.
> 


Yes, end users will not change the hardware (most of the time).



> OEMs do this during PCB design. This is fixed per board in the wild
> (apart from device evaluation boards)
> and is typically managed via device tree. (Allowing it to be changed
> by OEMs, but not end users).
> 
> > > This attribute allows to set its value
> > > + in micro-ohms. X is the IIO index of the device. The value is
> > > + used to calculate current, power and accumulated energy.
> > 
> > How common is it that this isn't known?
> 
> I would say zero.

Also, in the case of computer boards the resistor is known, and it
could be set from the device tree.

> 
> The ADM1177 (which is different, but also requires a shunt resistor),
> hwmon driver:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwmon/adm1177.c
> iio driver:
> https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/adm1177.c
> 
> uses device tree to manage the value of the shunt resistor.
> 
> > I'm not sure we've found it necessary to
> > support userspace control of this for any other device and there
> > are quite a few
> > where this could in theory be known only at runtime...
> 
> Not run time, but at PCB manufacturing time, when the device tree is
> compiled by the OEM.
> The assumption is - who ever controls the BOM - controls the device
> tree. This has been pretty true in my history.
> 
> It allows OEMs (who manage the hardware) to change it as they want,
> but keeps the complexity away from end users.
> 


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 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.

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




> - Robin
> 


Thanks,
Marius