linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: Add lltc ltc4286 driver bindings

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: <c734e26a-6fad-bc23-ec58-10c6a440ec83@roeck-us.net>
Date:   Thu, 26 Oct 2023 09:48:33 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Conor Dooley <conor@...nel.org>
Cc:     Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>, patrick@...cx.xyz,
        Jean Delvare <jdelvare@...e.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jonathan Corbet <corbet@....net>, linux-i2c@...r.kernel.org,
        linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: Add lltc ltc4286 driver
 bindings

On 10/26/23 08:26, Conor Dooley wrote:
> On Thu, Oct 26, 2023 at 08:09:52AM -0700, Guenter Roeck wrote:
>> On 10/26/23 07:25, Conor Dooley wrote:
>>> Hey,
>>>
>>> On Thu, Oct 26, 2023 at 04:15:11PM +0800, Delphine CC Chiu wrote:
>>>> Add a device tree bindings for ltc4286 driver.
>>>
>>> Bindings are for devices, not for drivers.
>>>
>>>>
>>>> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>
>>>>
>>>> Changelog:
>>>>     v2 - Revise vrange_select_25p6 to adi,vrange-select-25p6
>>>>        - Add type for adi,vrange-select-25p6
>>>>        - Revise rsense-micro-ohms to shunt-resistor-micro-ohms
>>>> ---
>>>>    .../bindings/hwmon/lltc,ltc4286.yaml          | 50 +++++++++++++++++++
>>>>    MAINTAINERS                                   | 10 ++++
>>>>    2 files changed, 60 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml
>>>> new file mode 100644
>>>> index 000000000000..17022de657bb
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml
>>>> @@ -0,0 +1,50 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/hwmon/lltc,ltc4286.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: LTC4286 power monitors
>>>> +
>>>> +maintainers:
>>>> +  - Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - lltc,ltc4286
>>>> +      - lltc,ltc4287
>>>
>>> I don't recall seeing an answer to Guenter about this ltc4287 device:
>>> https://lore.kernel.org/all/22f6364c-611c-ffb6-451c-9ddc20418d0a@roeck-us.net/
>>>
>>
>> At least the chip does officially exist now, and a datasheet is available.
>>
>> https://www.analog.com/en/products/ltc4287.html
>>
>> It shows that coefficients for the telemetry commands are different,
>> meaning that indeed both chips need to be explicitly referenced
>> in the properties description (and handled in the driver, which proves
>> my point of needing a datasheet before accepting such a driver).
> 
> Oh neat, would've been good if that'd been mentioned!
> 

Actually, turns out there is some contradiction in the LTC4286 datasheet.
It mentions different coefficients in different places. It is all but
impossible to determine if the datasheet is wrong or if the chip uses
a variety of coefficients unless one has a real chip available. Sigh :-(.

>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  adi,vrange-select-25p6:
>>>> +    description:
>>>> +      This property is a bool parameter to represent the
>>>> +      voltage range is 25.6 or not for this chip.
>>>
>>> 25.6 what? Volts? microvolts?
>>> What about Guenter's suggestion to name this so that it better matches
>>> the other, similar properties?
>>>
>>
>> I still would prefer one of the more common properties.
>> I still prefer adi,vrange-high-enable.
> 
> I think, from reading the previous version, that this is actually the
> lower voltage range, as there is a 102.x $unit range too that is the
> default in the hardware. Obviously, the use of the property could be
> inverted to match that naming however.
> 

It needs to be programmed either way because it is unknown how the chip
has been programmed before. That means some action is needed no matter
if the property is provided or not.

Sure, we could add something like adi,vrange-low-enable. Not sure if
that would be any better.

Actually, after looking at the datasheets, I'd be more interested
in the impact of other configuration buts such as VPWR_SELECT
which selects the voltage used for power calculations, or
all the settings in MFR_ADC_CONFIG. The datasheet doesn't really
explain (or I can't figure out how it does) how the different
configurations affect the reported telemetry values. But that is
a question for the driver, not for the property description.

Guenter