Message-ID: <da5457ea-c1ed-4c90-8743-fc982a02ed88@roeck-us.net>
Date: Mon, 24 Nov 2025 07:40:37 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Romain Gantois <romain.gantois@...tlin.com>,
 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>
Cc: 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 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

Powered by blists - more mailing lists