linux-kernel - Re: [PATCH v2 1/5] regulator: dt-bindings: Add Linear Technology LTM8054 regulator

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251001-glacial-synthetic-6faa84d6d047@spud>
Date: Wed, 1 Oct 2025 19:40:21 +0100
From: Conor Dooley <conor@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Romain Gantois <romain.gantois@...tlin.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>, Hans de Goede <hansg@...nel.org>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 1/5] regulator: dt-bindings: Add Linear Technology
 LTM8054 regulator

On Wed, Oct 01, 2025 at 01:18:51PM +0200, David Lechner wrote:
> On Wed, Oct 1, 2025 at 9:12 AM Romain Gantois
> <romain.gantois@...tlin.com> wrote:
> >
> > On Sunday, 28 September 2025 00:31:05 CEST Conor Dooley wrote:
> > ...
> > > > >
> > > > > > +  lltc,fb-voltage-divider:
> > > > > Why does this property have a ?linear? vendor prefix?
> > > > > Shouldn't it be adi to match the other property and compatible?
> > > >
> > > > This component was originally from Linear Technology, before it was
> > > > acquired by Analog Devices. The new properties and compatibles have the
> > > > Analog Devices prefix, but the "fb-voltage-divider" property is already
> > > > used by the LTC3676 and LTC3589 regulators, so I left the Linear
> > > > Technology prefix for this one to avoid introducing a new property just
> > > > to specify a vendor prefix change.
> > > >
> > > > I don't have a strong opinion about this though.
> > >
> > > Do they share the same driver?
> >
> > They do not. However, they use it in the exact same way, and I would've
> > liked to factor out the handling of this property in a future patch. This
> > would also make it easier to handle other types of feedback pin circuits
> > and have a generic binding for "regulators using a feedback pin connected
> > to some kind of analog circuit".
> >
> > For example:
> >
> > Vout----+
> >         |
> >         |
> >        +++
> >        | |
> >        | | Rtop
> >        | |
> >        +++
> >         |
> >         |
> >  FB ----+
> >         |
> >      +--+--+
> >      |  |  |
> >      |  |  |CCS
> >      +--v--+
> >         |
> >         |
> >        -+-
> >         -
> >
> > This is all speculation at this point though, so I don't mind changing the
> > property to "adi,fb-voltage-divider" and handling the different compatibles
> > when it comes to it.
> >
> 
> Could we just make it `fb-voltage-divider-ohms`? The -ohms suffix
> makes it match the standard property-units suffix which already has
> the uint32-array type. There are a couple of bindings that have
> `vout-voltage-divider` without a vendor prefix, so it sounds like this
> pattern is considered somewhat of a standard property already. But I
> think it would be better with the -ohms suffix. For example, there is
> already `gw,voltage-divider-ohms` as well. But there are so many
> similar properties without the suffix, it is kind of the defacto
> standard already, so might be better to stick with that rather than
> making it even more different variants than there already are.

Ye, by all means standardise it. I suppose that means insertion into
regulator.yaml, which usually also means a regulator- prefix - unless
you're eyeing something wider than that?

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)