Hello everyone,

This is version four of my series which adds initial support of the Linear
Technology LTM8054 voltage regulator. The driver supports a fixed voltage
and a tunable output current limit using a DAC-controlled pin.

I'd say that the most unusual part of this series is the usage of the IIO
consumer API in a regulator driver. I think this makes sense here, since
the regulator driver has to access a DAC to read/set the output current
limit.

Since the regulator driver writes microvolts and the IIO consumer API takes
millivolts, the reads and writes to the CTL DAC have to be scaled by a
factor of 1000. Scaled reads are already supported in IIO, but scaled
writes are not, which is why I've implemented them in patch 2/4.

Moreover, the IIO read/write operations are done in quite a roundabout way
in the driver's regulator callbacks. This is due to a unsafe locking
interaction: the regulator callbacks are called under regulator lock, which
means they have an active ww_mutex reservation ID. Or, some IIO drivers
will perform regulator operations when read/written to, thus taking a new
ww_mutex reservation ID.  Taking two consecutive reservation IDs for the
same ww_mutex context without freeing the first ID is forbidden (and
lockdep will complain about this). The most straightforward solution I've
found is to move the actual IIO read/write operations to a different
thread, and to wait for them to complete with a timeout from the main
callback thread.

Please let me know what you think.

Thanks,

Romain

Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
Changes in v4:
- Various style improvements.
- Used namespaced exports for the IIO consumer API.
- Mitigated bug caused by abs() corner case.
- Link to v3: https://lore.kernel.org/r/20251106-ltm8054-driver-v3-0-fd1feae0f65a@bootlin.com

Changes in v3:
- Made IIO operations to an asynchronous context to avoid locking issue.
- Made CTL DAC control optional.
- Make various style adjustments to the LTM8054 driver.
- Link to v2: https://lore.kernel.org/r/20250925-ltm8054-driver-v2-0-bb61a401a0dc@bootlin.com

Changes in v2:
- Refactored iio_convert_processed_to_raw() to match what was done in Hans'
  series.
- Added unit tests for IIO division.
- Fixed coding style issues and removed unnecessary casts.
- Link to v1: https://lore.kernel.org/r/20250916-ltm8054-driver-v1-0-fd4e781d33b9@bootlin.com

---
Romain Gantois (6):
      regulator: dt-bindings: Add Linear Technology LTM8054 regulator
      iio: inkern: Use namespaced exports
      iio: add processed write API
      iio: test: Add kunit tests for iio_divide_by_value()
      regulator: Support the LTM8054 voltage regulator
      regulator: ltm8054: Support output current limit control

 .../devicetree/bindings/regulator/adi,ltm8054.yaml |  71 ++++
 MAINTAINERS                                        |   6 +
 drivers/extcon/extcon-adc-jack.c                   |   1 +
 drivers/hwmon/iio_hwmon.c                          |   1 +
 drivers/hwmon/ntc_thermistor.c                     |   1 +
 drivers/iio/adc/envelope-detector.c                |   1 +
 drivers/iio/afe/iio-rescale.c                      |   1 +
 drivers/iio/buffer/industrialio-buffer-cb.c        |   1 +
 drivers/iio/buffer/industrialio-hw-consumer.c      |   1 +
 drivers/iio/dac/ad8460.c                           |   1 +
 drivers/iio/dac/dpot-dac.c                         |   1 +
 drivers/iio/dac/ds4424.c                           |   1 +
 drivers/iio/inkern.c                               | 187 ++++++++--
 drivers/iio/light/cm3605.c                         |   1 +
 drivers/iio/light/gp2ap002.c                       |   1 +
 drivers/iio/multiplexer/iio-mux.c                  |   1 +
 drivers/iio/potentiostat/lmp91000.c                |   1 +
 drivers/iio/test/Kconfig                           |  12 +
 drivers/iio/test/Makefile                          |   1 +
 drivers/iio/test/iio-test-divide.c                 | 247 ++++++++++++++
 drivers/iio/test/iio-test-multiply.c               |   1 +
 drivers/input/joystick/adc-joystick.c              |   1 +
 drivers/input/keyboard/adc-keys.c                  |   1 +
 drivers/input/touchscreen/colibri-vf50-ts.c        |   1 +
 drivers/input/touchscreen/resistive-adc-touch.c    |   1 +
 drivers/phy/motorola/phy-cpcap-usb.c               |   1 +
 drivers/power/supply/ab8500_btemp.c                |   1 +
 drivers/power/supply/ab8500_charger.c              |   1 +
 drivers/power/supply/ab8500_fg.c                   |   1 +
 drivers/power/supply/axp20x_ac_power.c             |   1 +
 drivers/power/supply/axp20x_battery.c              |   1 +
 drivers/power/supply/axp20x_usb_power.c            |   1 +
 drivers/power/supply/axp288_fuel_gauge.c           |   1 +
 drivers/power/supply/cpcap-battery.c               |   1 +
 drivers/power/supply/cpcap-charger.c               |   1 +
 drivers/power/supply/da9150-charger.c              |   1 +
 drivers/power/supply/generic-adc-battery.c         |   1 +
 drivers/power/supply/ingenic-battery.c             |   1 +
 drivers/power/supply/intel_dc_ti_battery.c         |   1 +
 drivers/power/supply/lego_ev3_battery.c            |   1 +
 drivers/power/supply/lp8788-charger.c              |   1 +
 drivers/power/supply/max17040_battery.c            |   1 +
 drivers/power/supply/mp2629_charger.c              |   1 +
 drivers/power/supply/mt6370-charger.c              |   1 +
 drivers/power/supply/qcom_smbx.c                   |   1 +
 drivers/power/supply/rn5t618_power.c               |   1 +
 drivers/power/supply/rx51_battery.c                |   1 +
 drivers/power/supply/sc27xx_fuel_gauge.c           |   1 +
 drivers/power/supply/twl4030_charger.c             |   1 +
 drivers/power/supply/twl4030_madc_battery.c        |   1 +
 drivers/power/supply/twl6030_charger.c             |   1 +
 drivers/regulator/Kconfig                          |   9 +
 drivers/regulator/Makefile                         |   1 +
 drivers/regulator/ltm8054-regulator.c              | 379 +++++++++++++++++++++
 drivers/thermal/qcom/qcom-spmi-adc-tm5.c           |   1 +
 drivers/thermal/qcom/qcom-spmi-temp-alarm.c        |   1 +
 drivers/thermal/renesas/rzg3s_thermal.c            |   1 +
 drivers/thermal/thermal-generic-adc.c              |   1 +
 include/linux/iio/consumer.h                       |  36 ++
 sound/soc/codecs/audio-iio-aux.c                   |   1 +
 sound/soc/samsung/aries_wm8994.c                   |   1 +
 sound/soc/samsung/midas_wm1811.c                   |   1 +
 sound/soc/stm/stm32_adfsdm.c                       |   1 +
 63 files changed, 972 insertions(+), 30 deletions(-)
---
base-commit: cda7b38e04b41bf0e19deed2999d725f440a5abd
change-id: 20250728-ltm8054-driver-11cfa4741065

Best regards,
-- 
Romain Gantois <romain.gantois@bootlin.com>

On 11/24/25 06:48, Romain Gantois wrote:
> Hello everyone,
> 
> This is version four of my series which adds initial support of the Linear
> Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> and a tunable output current limit using a DAC-controlled pin.
> 
> I'd say that the most unusual part of this series is the usage of the IIO
> consumer API in a regulator driver. I think this makes sense here, since
> the regulator driver has to access a DAC to read/set the output current
> limit.
> 

I don't think that is a valid reason. Literally every driver measuring voltages
or current uses a DAC to do it. How else would one convert an analog value
into a digital value ?

Guenter

Hello Guenter,

On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
> On 11/24/25 06:48, Romain Gantois wrote:
> > Hello everyone,
> > 
> > This is version four of my series which adds initial support of the Linear
> > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > and a tunable output current limit using a DAC-controlled pin.
> > 
> > I'd say that the most unusual part of this series is the usage of the IIO
> > consumer API in a regulator driver. I think this makes sense here, since
> > the regulator driver has to access a DAC to read/set the output current
> > limit.
> 
> I don't think that is a valid reason. Literally every driver measuring
> voltages or current uses a DAC to do it. How else would one convert an
> analog value into a digital value ?

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.

Do you think that using the IIO consumer API is not correct here? What other 
method do you think I should use?

Thanks,

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

Hi

> Am 24.11.2025 um 16:13 schrieb Romain Gantois <romain.gantois@bootlin.com>:
> 
> Hello Guenter,
> 
> On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
> > On 11/24/25 06:48, Romain Gantois wrote:
> > > Hello everyone,
> > > 
> > > This is version four of my series which adds initial support of the Linear
> > > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > > and a tunable output current limit using a DAC-controlled pin.
> > > 
> > > I'd say that the most unusual part of this series is the usage of the IIO
> > > consumer API in a regulator driver. I think this makes sense here, since
> > > the regulator driver has to access a DAC to read/set the output current
> > > limit.
> > 
> > I don't think that is a valid reason. Literally every driver measuring
> > voltages or current uses a DAC to do it. How else would one convert an
> > analog value into a digital value ?
> 
> 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.pdf

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.

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".

But this are just my first thoughts as I have not been following this
topic before. Hope it helps.

BR,
Nikolaus

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".

> 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.

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.

Thanks,

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

Hi,

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

Re-sending this because my mailer messed up the formatting on the first try...
Sorry if you're receiving this twice.

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

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?
> 

Hi,


> Am 25.11.2025 um 09:41 schrieb Romain Gantois <romain.gantois@bootlin.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.

> 
> > 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?

> > 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.

I agree, but that is a common discussion :) For example, years ago I had a long
discussion if there should be touchscreen pre-calibration in kernel, which is
desirable to get it almost right after boot, or if it is user-space... In the
end it was rejected.

> 
> > 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.

Yes, I know - but how is this related to the kernel or a driver? To my knowledge
feedback dividers are never relevant for kernel drivers for buck regulators,
especially if they are fixed and can not be programmed. They end up in a specification
of regulator-min-microvolt and regulator-max-microvolt.

So I still wonder why they must be made available to the kernel and user-space.

If you look for example into the schematics of a PocketBeagle 2 
(https://docs.beagleboard.org/pocketbeagle-2.pdf).

Figure 3.23 on page 26 shows a 3.3V step-down converter with enable and feedback
resistors (560k/124k).

Still, this regulator is represented not by a dedicated TLV62595 driver but:

https://elixir.bootlin.com/linux/v6.18-rc7/source/arch/arm64/boot/dts/ti/k3-am62-pocketbeagle2.dts#L91

Well, it does not have a controllable current limit, just a builtin one.
(And a gpio-control could be added by using a regulator-gpio driver).

> 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.

That are my questions:
- what is so different with an LTM8054 to other buck regulators that it needs a dedicated driver
- is the feature to control current limit by a DAC to the LTM8054 or is it the DAC (in software perspective)
- does it need a conversion factor from mA to binary value? Why is this needed in kernel?
- are there similar designs planned for this chip or already in use which run Linux?

> > 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.

By current limitation you also have power limitation. Yes, it does not
need to provide charge, capacity, temperature but IMHO they are not all mandatory.
It is just a suggestion to look around if there are different abstractions
that already exist and can be used.

> 
> > 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?

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-regulator.c#L97

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.

Best regards,
Nikolaus

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@bootlin.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

On 11/25/25 02:25, H. Nikolaus Schaller wrote:
...
> 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?
> 
The name is terrible ;-), but that is what I would have suggested as well.
I don't see anything chip specific in this code. If there is a need for
a regulator driver which uses gpio to enable it and a DAC for current limiting,
it should be made generic.

> 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-regulator.c#L97
> 
> 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.
> 
Same here.

Thanks,
Guenter

On 11/24/25 07:13, Romain Gantois wrote:
> Hello Guenter,
> 
> 
> On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
> 
>  > On 11/24/25 06:48, Romain Gantois wrote:
> 
>  > > Hello everyone,
> 
>  > >
> 
>  > > This is version four of my series which adds initial support of the Linear
> 
>  > > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> 
>  > > and a tunable output current limit using a DAC-controlled pin.
> 
>  > >
> 
>  > > I'd say that the most unusual part of this series is the usage of the IIO
> 
>  > > consumer API in a regulator driver. I think this makes sense here, since
> 
>  > > the regulator driver has to access a DAC to read/set the output current
> 
>  > > limit.
> 
>  >
> 
>  > I don't think that is a valid reason. Literally every driver measuring
> 
>  > voltages or current uses a DAC to do it. How else would one convert an
> 
>  > analog value into a digital value ?
> 
> 
> 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.
> 
> 
> Do you think that using the IIO consumer API is not correct here? What other
> 
> method do you think I should use?
> 

Ok, I had a look into the datasheet. Unless I am missing something, the chip doesn't
have a digital control or monitoring interface such as I2C or SPI.

At the same time, you copied the hardware monitoring mailing list on this summary and
on (at least) one of the patches, but apparently not on all of them. This lead to my
apparently wrong assumption that iio is used to monitor (not [just] control) something
on the chip. I wrongly assumed that IIO is used to report chip status (voltage, current,
temperature) using an internal DAC. Obviously that was a wrong assumption.
Sorry for that.

Apparently you copied the hwmon mailing list for the introduction of an IIO namespace
and its use in a couple of hwmon drivers in one of the patches. My personal opinion
is that this should not be part of this series but a series of its own. That is just
my personal opinion, though.

Guenter

On Monday, 24 November 2025 16:40:37 CET Guenter Roeck wrote:
...
> > 
> > Do you think that using the IIO consumer API is not correct here? What
> > other
> > 
> > method do you think I should use?
> 
> Ok, I had a look into the datasheet. Unless I am missing something, the chip
> doesn't have a digital control or monitoring interface such as I2C or SPI.
> 
> At the same time, you copied the hardware monitoring mailing list on this
> summary and on (at least) one of the patches, but apparently not on all of
> them. This lead to my apparently wrong assumption that iio is used to
> monitor (not [just] control) something on the chip. I wrongly assumed that
> IIO is used to report chip status (voltage, current, temperature) using an
> internal DAC. Obviously that was a wrong assumption. Sorry for that.
> 
> Apparently you copied the hwmon mailing list for the introduction of an IIO
> namespace and its use in a couple of hwmon drivers in one of the patches.
> My personal opinion is that this should not be part of this series but a
> series of its own. That is just my personal opinion, though.

I understand. I can split it out.

Thanks,

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

On Mon, Nov 24, 2025 at 06:57:41AM -0800, Guenter Roeck wrote:
> On 11/24/25 06:48, Romain Gantois wrote:
> > 
> > This is version four of my series which adds initial support of the Linear
> > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > and a tunable output current limit using a DAC-controlled pin.
> > 
> > I'd say that the most unusual part of this series is the usage of the IIO
> > consumer API in a regulator driver. I think this makes sense here, since
> > the regulator driver has to access a DAC to read/set the output current
> > limit.
> 
> I don't think that is a valid reason. Literally every driver measuring voltages
> or current uses a DAC to do it. How else would one convert an analog value
> into a digital value ?

While I'm not objecting your vision on this, the ADC is also possible to use to
"measure" the analog signal. DAC approach IIRC considered cheaper solution, but
require an analogue comparator.

-- 
With Best Regards,
Andy Shevchenko