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: <20250227-sceptical-phenomenal-wolverine-56e3cf@krzk-bin>
Date: Thu, 27 Feb 2025 09:50:23 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Rob Herring <robh@...nel.org>, 
	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 Wed, Feb 26, 2025 at 11:17:48AM -0800, Guenter Roeck wrote:
> 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

Not exactly a problem but missing feature. pmbus code (at least one of
macros I looked at) expects regulator node and some sort of child of it
(vout), while such simple devices should be:

regulator {
	compatible = "adi,lt3074";
	regulator-name = "vout";
	regulator-min-microvolt = "100000";
	regulator-max-microvolt = "100000";
};

so without any of regulators and regulators/vout subnodes.

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

I did not investigate much into pmbus code, but this might be as simple
as accepting arguments for .of_match and .regulators_node and then
accepting NULLs as them as well. Or a new macro which assigns NULLs
there.

Regulator core handles .regulators_node=NULL already.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ