linux-kernel - Re: [PATCH 3/3] hwmon: (ina2xx) Add support for ina260

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: <616f7b6e-0e11-7c76-3baa-5b90a0967a91@roeck-us.net>
Date:   Tue, 19 May 2020 07:14:21 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Michal Simek <michal.simek@...inx.com>,
        Franz Forstmayr <forstmayr.franz@...il.com>
Cc:     Jean Delvare <jdelvare@...e.com>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Jonathan Corbet <corbet@....net>, linux-hwmon@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH 3/3] hwmon: (ina2xx) Add support for ina260

On 5/18/20 10:21 PM, Michal Simek wrote:
> On 26. 02. 20 3:16, Guenter Roeck wrote:
>> On 2/24/20 3:26 PM, Franz Forstmayr wrote:
>>> Add initial support for INA260 power monitor with integrated shunt.
>>> Registers are different from other INA2xx devices, that's why a small
>>> translation table is used.
>>>
>>> Signed-off-by: Franz Forstmayr <forstmayr.franz@...il.com>
>>
>> I think the chip is sufficiently different to other chips that a separate
>> driver would make much more sense than adding support to the existing
>> driver.
>> There is no calibration, registers are different, the retry logic is
>> not needed. A new driver could use the with_info API and would be much
>> simpler while at the same time not messing up the existing driver.
> 
> Isn't it also better to switch to IIO framework?
> As we discussed in past there are two ina226 drivers. One in hwmon and
> second based on IIO framework (more advance one?) and would be good to
> deprecate hwmon one.

"More advanced" is relative. The ina2xx driver in iio doesn't support
alert limits (which is queued in the hwmon driver for 5.8), and the
iio->hwmon bridge doesn't support it either. On top of that, there are
existing users of the hwmon driver, which would have to be converted
first. As for ina260, it would be up to the implementer to determine
if alert limit support is needed or not, and which API would be
appropriate for the intended use case.

Guenter