[PATCH v4 0/6] Add support for the LTM8054 voltage regulator

[H. Nikolaus Schaller]

Hi,

> Am 24.11.2025 um 16:57 schrieb Romain Gantois <romain.gantois at bootlin.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