From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 CBEBD36D516; Tue, 25 Nov 2025 08:49:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764060567; cv=none; b=lIavUBFKIHtkPhXR1Z1TwbLmYJdhR9M1fFwsS3YLUbvsJvwiMgaWcxoCqO+fMivHTDZ/mbvYk6RNcf4Lol4OGz2wJI+CNTULqmRKhZfd1YicXIbaD2FDHD53lMN/tH+yWN5kJhcA0eKukX2XvNyZAl6nxp1sJiQkh/32r3ZKDf4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764060567; c=relaxed/simple; bh=HuMSYGIDhMghJy5e91DhSwAve9AYXs6y5j/c+i75skY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kGQA9HnUKj2eSKTgLEOhJEFDMQURaSlDLU4+cTxPIA700wk8Cm+zowUh7/E3P/3AI5VAKfpYv8KqgnYCE5dByeuGL02Wws6sX5+JR+ntSmi3tJEQRTLnKayrLs2/HLKjFbGQX0RLxX9XEHKsmAnRbKUfR6n4O47Ai6oExSWKWok= 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=W8ePq99o; arc=none smtp.client-ip=185.171.202.116 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="W8ePq99o" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 870E5C15D48; Tue, 25 Nov 2025 08:49:00 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 1AC6160706; Tue, 25 Nov 2025 08:49:23 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id AC3511037149D; Tue, 25 Nov 2025 09:49:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1764060560; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=HuMSYGIDhMghJy5e91DhSwAve9AYXs6y5j/c+i75skY=; b=W8ePq99oVgQ2uOhAUVduhMvpCSXIAoY+0yVa1mbwp1VdL8dko43eVADbIkwLEo/9T4klxf cOHZHbCYxkbFZKzwYcsAV0MplbMQBGfxqbi8NHWPE1hI/2RdGU1320tO0+n2I2vAPU7TRr zeqkiOKvhUSBhsjnyr8bW+E1eANm32KvV6h32TNOCwJHL37JfmE0NSohpsx8aXUMgwfLqf lx4OkrhMWjOOJFQ1gVMv//rYccFZ96Ub5IKcXq252JnvGotvhT4jzy3ydQOAA4+ytNAXQR HX0lQg+C3HV6XUvm89BY4fLtzKcSbLhkr3v6E7n0Cs3tAhGaoobXAOaL+QCrJQ== 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:49:03 +0100 Message-ID: <22915450.EfDdHjke4D@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="nextPart7880843.EvYhyI6sBW"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Last-TLS-Session-Version: TLSv1.3 --nextPart7880843.EvYhyI6sBW Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Romain Gantois To: "H. Nikolaus Schaller" Date: Tue, 25 Nov 2025 09:49:03 +0100 Message-ID: <22915450.EfDdHjke4D@fw-rgant> In-Reply-To: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com> MIME-Version: 1.0 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 --nextPart7880843.EvYhyI6sBW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEIcCsAScRrtr7W0x0KCYAIARzeA4FAmklbX8ACgkQKCYAIARz eA6Qag/+O307fHl9Wqb40t4WIdZsKqQP0PcYGNlhz4T+SyyyFetdu7Un665acsjg MdEMkudNxDehZTnsfTlNKsGzpu2OIAsiIlD9XKJFaAA1kAzdWA9xb8mT7lwnadD3 sa0EX7LtIT8x4BLkaCyTkCioE3FgLPhQCXC3fALmNojilfwl2Y5QXUuKUB230sPo 8ihY8Yj2rc5QmYZV9fSsC/HSQwVkXSU3T5Q7SjwfFSIRL2ZajuPycLU9QmHnOWGi R02esa/1vRdYlVGcCwKSDG5JHzsRCRfsbXZAkIyMc3hQ6LgizTUyKQ+FM2w/68/w 1pn2H5N0D8uR/+WxXWPMMZ9hpklLkDec5lOlf3ZA4DOa8m6nDKROBx/eV/aLlgHp imI2qqqmBqJjzO+x5ubkm/v5QP75ikGusNxuXcUACwQTNaif8z6YEekKvGd89taO jvhQnSOWtFfYZRgVzpjbjgm+OZy+f6bACCzGI/KZ/KhAb1vwCz6hBkmg0Zh2c/hP Wa3dcDp/pn5j3yP1E10jdA9G9AkxmSWN9VxNtRrGKynSiz3Z2ilWvze2SxlSN0vZ tdlEhNz1/r/fZWcDyFgDwaCs/R6+RHtQoYnG/A+5aatiGdnE9/tngpQXOkjpr/ft VMDXkLH4+MDGHExDw3PIBbSfWqmFssAmfriPh3xsAUUXcR/LvIU= =eMhj -----END PGP SIGNATURE----- --nextPart7880843.EvYhyI6sBW--