From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FDF32DAFB5; Tue, 25 Nov 2025 08:42:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764060126; cv=none; b=RTtyjybJNed1TAYTyGQDYgxBZ1wfqGZwLDUKGVQqDyDAQzOZvTrCd3uLrm8ctZZz2/9z4S3TQeShRfR97dowJW8xEbAs0rwOsbzEMfI+hOzaQoAHsUWDTCWCjvuO4FYAZDB5QakMsMw4dhke3slB5NDegzBRsdVbr2/4GApaF/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764060126; c=relaxed/simple; bh=n7wfBFTS1kGLsWICsHYKAhBOKvlSac+am2uGBQZ1i2E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VKsou0PMP3K5gI2vhT25nWyMwL9MaDDs7dMCOUHEmRwamdIpzlKxl75gNjPCGctD5CvhmhfuG2V1gj+Jp+dpLMzxG5iQykqvEBJu//eUl6HTa92yJpi9xZr1fQBIW32lObHD2m0jaJ7NHDfoMlSyovJ8EC71Orx27FSHJQO6NZs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=np8FqZdy; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="np8FqZdy" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id A8EC21A1D30; Tue, 25 Nov 2025 08:42:01 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 76F1D60705; Tue, 25 Nov 2025 08:42:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 937281037160A; Tue, 25 Nov 2025 09:41:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1764060118; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=2o0olBqqiCnYMdbfemBfUTVqO9jEfeuMqW3Jkn2wJC0=; b=np8FqZdym2Wty0W93O7w7shgzDAPxvx7OSrXs0VRuETOjjAW8+HA50+CFTcDPlJ1zO4C7W e6PURzgtrculx7tTu8rN97eJwG2WPlJhw8q6DJTImD2KkbiUG+rt8S7g6YHZd4v6vlZzWI 4KV0igv0n6z6xtyafwxwCTcHE8Eb5vgS9NMtbd+09MDsbnWaraeS/SLEzkokIKtYa2tQnA LE7CCJQabojoGkiALiJgmhfnKLC74eVKEj0pyAvSQmlvHtLFegfXUAYwlMTCjo3Xo8WnoB XKSt0lq2XmLzPCn6oWlE9BzvoJHvLN1w/658oqxZrLUwOEMDLD4Oop8egVF3iw== From: Romain Gantois To: "H. Nikolaus Schaller" Cc: Liam Girdwood , Mark Brown , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonathan Cameron , David Lechner , Nuno =?UTF-8?B?U8Oh?= , Andy Shevchenko , Guenter Roeck , Thomas Petazzoni , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-iio@vger.kernel.org, Conor Dooley , MyungJoo Ham , Chanwoo Choi , Peter Rosin , Mariel Tinaco , Lars-Peter Clausen , Michael Hennerich , Kevin Tsai , Linus Walleij , Dmitry Torokhov , Eugen Hristev , Vinod Koul , Kishon Vijay Abraham I , Sebastian Reichel , Chen-Yu Tsai , Support Opensource , Paul Cercueil , Iskren Chernev , Marek Szyprowski , Matheus Castello , Saravanan Sekar , Matthias Brugger , AngeloGioacchino Del Regno , Casey Connolly , Pali =?UTF-8?B?Um9ow6Fy?= , Orson Zhai , Baolin Wang , Chunyan Zhang , Amit Kucheria , Thara Gopinath , "Rafael J. Wysocki" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Claudiu Beznea , Jaroslav Kysela , Takashi Iwai , Sylwester Nawrocki , Olivier Moysan , Arnaud Pouliquen , Maxime Coquelin , Alexandre Torgue , Dixit Parmar , linux-hwmon@vger.kernel.org, linux-input@vger.kernel.org, linux-phy@lists.infradead.org, linux-pm@vger.kernel.org, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-sound@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Andy Shevchenko Subject: Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator Date: Tue, 25 Nov 2025 09:41:34 +0100 Message-ID: <3021060.e9J7NaK4W3@fw-rgant> In-Reply-To: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com> References: <20251124-ltm8054-driver-v4-0-107a8a814abe@bootlin.com> <4053840.MHq7AAxBmi@fw-rgant> <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com> Precedence: bulk X-Mailing-List: linux-input@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3391484.44csPzL39Z"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Last-TLS-Session-Version: TLSv1.3 --nextPart3391484.44csPzL39Z Content-Type: multipart/alternative; boundary="nextPart3384998.aeNJFYEL58"; protected-headers="v1" Content-Transfer-Encoding: 7Bit From: Romain Gantois To: "H. Nikolaus Schaller" Date: Tue, 25 Nov 2025 09:41:34 +0100 Message-ID: <3021060.e9J7NaK4W3@fw-rgant> In-Reply-To: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com> MIME-Version: 1.0 This is a multi-part message in MIME format. --nextPart3384998.aeNJFYEL58 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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? > --nextPart3384998.aeNJFYEL58 Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

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


--nextPart3384998.aeNJFYEL58-- --nextPart3391484.44csPzL39Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEIcCsAScRrtr7W0x0KCYAIARzeA4FAmkla74ACgkQKCYAIARz eA4uoA/9H25d5rofXv5yC5jGvCQOKojoS9wGic9EKNLG3RhZlGrCXhEf2dFw9w9I KdlTjGKLaXynf0oBz5SfeSL1juql9WOfV2px4AeCeEALikbdQs1ce1O7K126uo4q A1zlxkZMPa6Xj3pQ1IIri7WVCjRDiHVFs1hrFJz8XoMbIC0XDycQD+8DEe84cHbk aqo/wiWTxLVusXDihmVD2JfaZhDKMKTW6rQ2HW+MJUOGcNtTYNKlQ6PjRQtaAvbq 0GaffUh2vHyQ0qR1mmhgJibiSX+opzhVeHFua3cA5lfVPZPudubmORMAUnDXeT3j coFe7wkMqx34bQG2vf1EUrfl5tM0SLF9yPo3W2Y0rWRpSJhRcnDDqtMBY4LGtU4P KzMYczGkdSXG7xA+fT9kR0ANunjMz3ub2kFnR5fJB+B07C1DNAQFA7zA8WRt4iL/ cNPYb5BX7VDxw33Xripatp9u8hE2Z3CGBKYW7gudC9Jd2U5GoIukMdxn4TJlZHAA 2TL8/ZJDKBTcUEsca+UU5BUa3tm8gk0jfJpThZwOhB2G+eOuKVbcLejZqAfNN1rG quNoBZmTQ51CzAoHiDbTGrnK5oz84q2KWOmHXLAn8O20dlJWEUgb/ghFR79r3EW4 AuNuKXwXClIOnvF5B9NLbFCwZzFK9L5mIQ69ZwaVN+0kDzg3CAg= =LLKl -----END PGP SIGNATURE----- --nextPart3391484.44csPzL39Z--