linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add lt3074

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] [day] [month] [year] [list]

Message-ID: <3f7b031d-7b83-4a00-996d-aabb26278b67@roeck-us.net>
Date: Wed, 26 Feb 2025 11:17:48 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>
Cc: Cedric Encarnacion <cedricjustine.encarnacion@...log.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jean Delvare <jdelvare@...e.com>,
 Jonathan Corbet <corbet@....net>,
 Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-i2c@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add lt3074

On 2/26/25 06:59, Rob Herring wrote:
> On Wed, Feb 26, 2025 at 09:20:40AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Feb 25, 2025 at 09:01:13PM +0800, Cedric Encarnacion wrote:
>>> Add Analog Devices LT3074 Ultralow Noise, High PSRR Dropout Linear
>>> Regulator.
>>>
>>> Signed-off-by: Cedric Encarnacion <cedricjustine.encarnacion@...log.com>
>>> ---
>>>   .../bindings/hwmon/pmbus/adi,lt3074.yaml           | 64 ++++++++++++++++++++++
>>>   MAINTAINERS                                        |  7 +++
>>>   2 files changed, 71 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..714426fd655a8daa96e15e1f789743f36001ac7a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml
>>> @@ -0,0 +1,64 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,lt3074.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Analog Devices LT3074 voltage regulator
>>> +
>>> +maintainers:
>>> +  - Cedric Encarnacion <cedricjustine.encarnacion@...log.com>
>>> +
>>> +description: |
>>> +  The LT3074 is a low voltage, ultra-low noise and ultra-fast transient
>>> +  response linear regulator. It allows telemetry for input/output voltage,
>>> +  output current and temperature through the PMBus serial interface.
>>> +
>>> +  Datasheet:
>>> +    https://www.analog.com/en/products/lt3074.html
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - adi,lt3074
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  regulators:
>>> +    type: object
>>> +    description: |
>>> +      list of regulators provided by this controller.
>>
>> You have only one regulator, so drop the "regulators". vout could be
>> here, but since you do not have any other resources, I doubt it stands
>> on its own either. This is even visible in your DTS - you named the
>> device as regulator, so logically this is the regulator. Regulator does
>> not have regulators (otherwise they could also have regulators... so
>> triple regulator).
>>
>> hwmon code might need some changes, but that's not really relevant for
>> proper hardware description.
> 
> Normally, I would agree, but it seems generic pmbus code expects this
> structure. This just came up with changing another binding maintained by
> 'Not Me' to follow this structure. We're stuck with the existing way, so
> I don't know that it is worth supporting 2 ways forever. OTOH, is it
> guaranteed that these devices will only ever be pmbus devices or that
> other regulator devices which are not handled as pmbus devices currently
> will be in the future. If so, more flexibility in the bindings will be
> needed.
> 

I would appreciate if someone would explain to me what the problems with
the current PMBus code actually are. I have seen several comments claiming
that the code should be changed, but I have no idea what the expected changes
actually are or, in other words, what the PMBus code should be doing
differently.

Thanks,
Guenter