On Monday, 24 November 2025 17:19:45 CET H. Nikolaus Schaller wrote:
...
> > 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?
>
This is planned support for a voltage regulator chip.
> 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.
> > > 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 :)
>
IMHO this is not integration, it's BSP work. As far as regulator functions are
concerned, the current status quo is that the kernel handles getting/setting
voltage levels, applying current and voltage constraints and other basic
regulator features.
> > 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?
>
A different solution does not currently exist (although a userspace-based
solution could be designed). I just think that a kernel-based solution is more
desirable here.
> Another question: is your scheme generic enough so that it can be expected
> that other devices are using it in the same way?
>
Yes, the LTM8054 has a fairly common design as far as buck-boost chips go.
Things like feedback dividers on the output voltage pin are standard practice.
And since the driver doesn't rely on a particular way of integrating the
LTM8054 with other components, it can be reused wherever the same regulator
chip is used.
> Or could the power controller framework (/sys/class/power_supply) fit
> better?
>
I don't think the power supply abstraction is relevant here. The LTM8054 is a
voltage regulator, it doesn't have charge, capacity, temperature monitoring,
power limitation, or other power supply class features.
> 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?
What if the LTM8054 is not used to supply a battery?
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Attachment:
signature.asc
Description: This is a digitally signed message part.