Message-ID: <8695751.T7Z3S40VBb@fw-rgant>
Date: Thu, 27 Nov 2025 16:06:47 +0100
From: Romain Gantois <romain.gantois@...tlin.com>
To: "H. Nikolaus Schaller" <hns@...delico.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

On Tuesday, 25 November 2025 11:25:24 CET H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 25.11.2025 um 09:41 schrieb Romain Gantois
> > <romain.gantois@...tlin.com>:
> > 
> > 
> > This is planned support for a voltage regulator chip.
> 
> Well, but one which is not by itself programmable. So IMHO, it does not
> support that chip, but the circuit it is used in.
> 

The boundary is a bit blurry in this case, sure.

> > > Are you looking for a virtual "glue" driver to logically combine several
> > > low level functions?
> > 
> > I'm looking for a clean userspace abstraction for this component, the low-
> > level functions in this case are those of a voltage regulator.
> 
> As far as I understood it has
> - constant voltage
> - current can be limited
> - it can be turned on/off
> 
> That means it is a fixed-regulator (for constant voltage and turn on/off)
> and a mechanism to program the current limit (iio-dac). Both have clean
> userspace abstraction.
> 
> What am I missing?
> 

In my case, the regulator has a DAC tapping into the feedback divider with 
allows modifying the output voltage level. This isn't specific to the LTM8054 
though, you can theoretically do this with any regulator chip that has a 
feedback pin.

...
> The question remains if you want to solve something for a single board which
> happens to have an LTM8054 or if you are solving a more general design
> pattern.
> 
> In summary my view is that the LTM8054 is just a "fixed-regulator" which
> gets an additional current-limiter feature by adding a DAC chip (which needs
> a driver of course). So software control is required not by the LTM8054 but
> by adding a DAC chip.
> 
> Another suggestion: what extending the "regulator-fixed", "regulator-gpio",
> "regulator-fixed-clock" pattern by some
> "regulator-gpio-iio-dac-current-limiter" driver to make it independent of
> your specific chip?
> 
> By the way, are you aware of this feature of the regulator-gpio driver?
> 
> https://elixir.bootlin.com/linux/v6.18-rc7/source/drivers/regulator/gpio-reg
> ulator.c#L97
> 

That could be a preferable solution given that similar current limit and 
output voltage limit control methods could apply to other regulator chips... 
I'll have to think about it some more.

> Just to note: I am neither maintainer nor doing any decisions on this, just
> asking questions for curiosity and from experience and giving hints for
> alternative approaches, where I hope they help to find the really best
> solution.

Sure, I appreciate that.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Powered by blists - more mailing lists