Message-Id: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com>
Date: Mon, 24 Nov 2025 17:19:45 +0100
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Romain Gantois <romain.gantois@...tlin.com>
Cc: 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>,
 David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>,
 Guenter Roeck <linux@...ck-us.net>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org,
 linux-iio@...r.kernel.org,
 Conor Dooley <conor.dooley@...rochip.com>,
 MyungJoo Ham <myungjoo.ham@...sung.com>,
 Chanwoo Choi <cw00.choi@...sung.com>,
 Peter Rosin <peda@...ntia.se>,
 Mariel Tinaco <Mariel.Tinaco@...log.com>,
 Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Kevin Tsai <ktsai@...ellamicro.com>,
 Linus Walleij <linus.walleij@...aro.org>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Eugen Hristev <eugen.hristev@...aro.org>,
 Vinod Koul <vkoul@...nel.org>,
 Kishon Vijay Abraham I <kishon@...nel.org>,
 Sebastian Reichel <sre@...nel.org>,
 Chen-Yu Tsai <wens@...e.org>,
 Support Opensource <support.opensource@...semi.com>,
 Paul Cercueil <paul@...pouillou.net>,
 Iskren Chernev <me@...ren.info>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Matheus Castello <matheus@...tello.eng.br>,
 Saravanan Sekar <sravanhome@...il.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Casey Connolly <casey.connolly@...aro.org>,
 Pali Rohár <pali@...nel.org>,
 Orson Zhai <orsonzhai@...il.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Chunyan Zhang <zhang.lyra@...il.com>,
 Amit Kucheria <amitk@...nel.org>,
 Thara Gopinath <thara.gopinath@...il.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
 Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>,
 Sylwester Nawrocki <s.nawrocki@...sung.com>,
 Olivier Moysan <olivier.moysan@...s.st.com>,
 Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Dixit Parmar <dixitparmar19@...il.com>,
 linux-hwmon@...r.kernel.org,
 linux-input@...r.kernel.org,
 linux-phy@...ts.infradead.org,
 linux-pm@...r.kernel.org,
 linux-mips@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org,
 linux-arm-msm@...r.kernel.org,
 linux-sound@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 Andy Shevchenko <andriy.shevchenko@...el.com>
Subject: Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator

Hi,

> Am 24.11.2025 um 16:57 schrieb Romain Gantois <romain.gantois@...tlin.com>:
> 
> Hi Nikolaus,
> 
> On Monday, 24 November 2025 16:35:28 CET H. Nikolaus Schaller wrote:
> ...
> > > Sorry, I don't quite understand your remark. To integrate this voltage
> > > regulator component into the Linux regulator abstraction, I'm providing a
> > > current limit control function. To provide such a function, the voltage
> > > level on a pin has to be controlled. AFAIK, the kernel abstraction used
> > > to set precise voltages on lines is an IO channel.
> > 
> > I was curious to learn about this topic and looked into the data sheet:
> > 
> > https://www.analog.com/media/en/technical-documentation/data-sheets/8054fa.p
> > df
> > 
> > As far as I see the LTM8054 does not even have a programming interface.
> > So is it reasonable to provide a dedicated driver at all?
> > 
> > The figure on page 20 seems to suggest that there is an external DAC
> > which drives the regulator. And the regulator drives for example a fan.
> > 
> > So I would think of a driver for the specific DAC and ignore the specific
> > LTM chip at all.
> > 
> 
> In my use case, the LTM8054 feeds a DC output port on which various devices 
> may be plugged. Dynamic output current limitation and output voltage level 
> control for these devices is a requirement, as well as stepped voltage 
> transitions, thus the need for a proper regulator device.
> 
> The LTM8054's feedback pin can be driven by a different DAC, which allows for 
> dynamic output voltage control. This is a more complex upstreaming topic 
> however, so I've left it out of this initial series. There are other component 
> functions which fit in squarely into the regulator framework, such as 
> input current limit control and soft-start. But I understand that the current 
> driver might look a bit "bare".

So you just want to have some user-space mechanism to control voltage
and current limits? Can't this be done by directly controlling them through
the iio API?

Is this for a device that is already in kernel or planned to be supported?
Or is it "application support" for some SBC?

Are you looking for a virtual "glue" driver to logically combine several low
level functions?

> 
> > What could be necessary is if you really want to be able to "regulate"
> > the current going to Vout, some bridge between regulator API and some
> > IIO DAC.
> > 
> > And enabling/disabling the regulator by some GPIO can be described in
> > the DT already through a "regulator-fixed".
> > 
> 
> This is a possibility, but when you bring in all of these other hardware 
> functions that I mentionned e.g. output voltage control and stepping, you'll 
> end up with several different devices which look unrelated from userspace, but 
> actually control the same chip.

That is quite usual... I have often heard: user space must fix this as kernel
just provides basic functions in a harmonized way and integration has to
be tailored to the device anyways :)

> Userspace will also have to know about some hardware details to properly 
> control the DACs, such as the values of the sense and feedback resistors. In 
> my opinion, this bypasses the kernel's abstraction of hardware.

I came up with this argument several times in the part and got a lot of contrary :)

What I still wonder: does your hardware warrant an upstream driver for a
non-programable chip if a different solution (with help of user-space) already
exist?

Another question: is your scheme generic enough so that it can be expected
that other devices are using it in the same way?

Or could the power controller framework (/sys/class/power_supply) fit better?

There is an API to ask chargers etc. for battery voltage and current limits or
even write them.

There is also "generic-adc-battery" which allows to hook up with arbitrary
iio-adcs for measurements - although you need a DAC in your setup. Maybe an
extension here is a better strategy than a dedicated ltm8054 driver?

BR,
Nikolaus

Powered by blists - more mailing lists